RE: [boost] Re: date_time high resolution clock for Win32

From: Reid Sweatman (drunkardswalk_at_[hidden])
Date: 2004-05-18 18:50:44

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Johan Nilsson
> Sent: Tuesday, May 18, 2004 3:18 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: date_time high resolution clock for Win32
> 
> 
> [sort-of-a-shameless-plug but on-topic]:
> 
> http://msdn.microsoft.com/msdnmag/issues/04/03/HighResolutionT
> imer/default.aspx
> 
> Questions are welcome.
> 
> // Johan
> 
> "Jeff Garland" <jeff_at_[hidden]> wrote in message
> news:20040509141926.M57409_at_crystalclearsoftware.com...
> > 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

Hardware is definitely involved, and it makes any method based on the Time
Stamp Counter not nearly as accurate as you might think.  It's all been
hashed out here before, so rather than repeat it all, I'll just give you the
reference.  Look back through the Boost Archives for 1999 for a thread
called "timer classes" with my name and that of Andy Glew associated with
it, and you'll find some very interesting information (mainly from Andy, who
was involved with the silicon design).  

Reid Sweatman