Re: [boost] date_time high resolution clock for Win32

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://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