On Sat, 08 May 2004 19:45:34 -0500, Aaron W. LaFramboise wrote
(This is a followup to this question of mine on boost-users http://lists.boost.org/MailArchives/boost-users/msg06618.php . Jeff Garland suggested comments on that thread should be posted here. I'm new to this list, and not entirely sure if messages with this sort of platform-specific detail are welcome here; if they aren't, let me know.)
Well, given that it is regarding a specific extension to a boost library it is quite welcome. A higher resolution clock is already available for Posix systems in date_time, so you are addressing a platform that isn't well supported by the library now. Finally, the entire issue of timers and timing has been a hot topic lately...
I've been examining possibilities for a high resolution clock in date_time for Win32 over the past few days.
In particular, Windows, like many other platforms, has a system clock with only fair precision (usually about 10ms), but excellent 'counter' clocks with very high precision. It seemed reasonable to me that it should be possible to combine the accuracy of the system clock with the precision of a high-resolution counters, to create a Boost date_time clock that had both the system's maximum accuracy and maximum precision.
So, after a few days of casual research and brainstorming, I came up with this simple, incomplete prototype clock. The idea is that it queries both the system clock and the high resolution counter, saves them in static memory. Future calls only use the high resolution counter, using the saved correspondence between the two clocks to calculate the real time. This sort of timer, if it can be implemented reasonably, might be useful on many platforms, including when only time() and clock() are availible.
Overall, sounds like a good idea.
This implementation has these characteristics:
THEORY (Wishful thinking) - -Should be the best general-purpose clock and timer on Win32, that would be very difficult to exceed in useful precision or accuracy in a reimplementation. - -Should gracefully handle user changes of system clock.
PRACTICE - -It does in fact have the promised ten millisecond accuracy and sub-microsecond resolution. - -The Windows system clock is a lot more "jittery" than I had noticed before. This is a huge problem.
The clock routine checks every call to ensure that the two clocks are not further apart than twice the reported precision of the system clock. If they are, the saved times are re-initialized, and the clock starts over from the system time. There is a small problem in my implementation that causes the clock to return subsequent decreasing times for only very small drifts, which should not happen. I have not yet decided how to fix this, but this is not the big problem.
The big problem is that while the system clock and counter stay very well in synch under 'normal conditions,' the system clock jitters a whole lot when a lot of system resources are being used in the background, causing the clock to reset itself when it really should not. This in turn causes some strange precision characteristics which might be unacceptable for some applications.
This isn't good. What it says to me is that this is a limitation of the OS and/or hardware. Basically, windows isn't a real-time OS so when it gets busy it doesn't get around handling the clock correctly. I suppose hardware could be involved as well, but it is suspicious that things only go wrong when the os is busy.
I'm going to let this sit for a few days while I think about it. I'd be very interested in hearing any comments in the meantime.
I'll have a look at your code in more detail later... Jeff