From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-05-18 04:18:09
[sort-of-a-shameless-plug but on-topic]:
Questions are welcome.
"Jeff Garland" <jeff_at_[hidden]> wrote in message
> 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
> 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
> 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
> > 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
> and/or hardware. Basically, windows isn't a real-time OS so when it gets
> it doesn't get around handling the clock correctly. I suppose hardware
> be involved as well, but it is suspicious that things only go wrong when
> 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...
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk