From: Jeff Garland (jeff_at_[hidden])
Date: 2004-05-09 09:19:26
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://listarchives.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