Unfortunately I don't know how to implement a real steady_clock on windows platform, and I was wondering if it shouldn't be removed. Of course if someone knows how to do it, patches are welcome. [snip] Unfortunately if it is not possible to switch to the old implementation of boost::thread(which doesn't depend on boost::chrono) we can't update to boost 1.54. That is a real blocker for us and I don't see a solution right now. Do I miss something? Are we the only ones who suffer from this problem on windows?
What is supposed to be the case (according to Microsoft) is that unsupported versions of Windows (pre-Vista) can experience QueryPerformanceCounter detachment across processor cores on some (older) AMD chips. Supposedly newer Windows have a list of those AMD chips, and will use HPET instead of TSC on those chips (with a consequent 20x overhead increase). In other words, QueryPerformanceCounter() should have no detachment between CPUs on newer Windows. Does this match your experience? Regarding implementing steady clock on Windows using TSC, it is possible: OS X generates gettimeofday() from TSC, and their implementation is a model implementation of how to do that correctly (keep a per CPU skew count). There is also the option of using HPET directly using a variety of Windows APIs such as timeBeginPeriod() et al (http://msdn.microsoft.com/en-us/library/dd743611(v=vs.85).aspx) . There's a very useful page on Microsecond timers on Windows at http://windowstimestamp.com/description. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.