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

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-05-19 02:09:01

"Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]> wrote in message
news:40AAC274.1060707_at_aaronwl.com...
> Reid Sweatman wrote:
>
> >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).
> >

Interesting stuff, thanks!

> >Reid Sweatman
> >
> >
> I found the thread at
> http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/boost/1137286 .
> It is very informative; thank you for the information.
>
> I also found an interesting URL by someone who has done some similar
> research on timing in Windows,
> http://www.wideman-one.com/gw/tech/dataacq/wintiming.htm.
> Unfortunately, most of this is largely inapplicable in Boost.
>
> It still seems to me that, despite its flaws, Intel's RDTSC combined
> with a time source assumed to be relatively reliable, such as the system
> clock, could yield a hybrid clock no worse than the primary system
> clock  The improvement in accuracy might benefit some applications, and
> probably wouldn't hurt.

I tend to think the same way. But, the user must be aware that there _is_ a
background thread in the application _and_ that it could possibly preempt
other threads in current or other applications in the system - thus
interfering with the 'real' work (this is applicable for my implementation
only though, which raises the priority of the synchronization thread
autonomously if if is preempted all the time during synchronization - which
could be solved by some better end-user control of the synch policy).

>
> In any case, there should be no illusions that any timer setup on
> Windows will meet hard real-time constraints.  In fact, even if there
> were some other timer available that did not share these problems, it is
> quite likely it would not offer realistically improved performance
> anyway due to Windows scheduling.  With whatever might be implemented
> for Boost, this needs to be documented.

I'd just like to extend on that - no application-level timer on any of the
more common *nix platforms would work better than on Windows (speaking NT
flavour). Talking about scheduling - NT scheduling is in fact more
real-time'ish than at least the Linux/BSD ones due to the more preemptive
kernel and driver architecture (yes, I know that Linux 2.6 and FreeBSD 5.x
supposedly have a finer granularity on the kernel locks than their
predecessors - haven't tried them out yet though). IIRC the linux kernel
used to grab the TSC (or perhaps the MB timer) at each clock interrupt to be
able to provide the end user with microsecond time resolution. Writing a NT
device driver to provide basically the same stuff should be possible, but I
doubt it's recommendable.

Implementing a user-mode time provider that always works no matter what the
underlying hardware platform is seems virtually impossible, even if we would
limit ourselves to NT/2000/XP/(Longhorn) only (most unices I know of have a
working gettimeofday so they really don't need it). Question is - would this
be acceptable for a general-purpose cross-platform library such as boost?
The implementation that's downloadable with the article is not the exact way
I would implement the time provider - that one evolved more like an
experiment so see what you can get. Still I find my results have been almost
surprisingly good using the time provider under both single CPU and SMP
NT/2k/XP systems - the only problems I've noticed is when the you start a
VMware virtual machine on the host - which adds a delay to the time it is
possible to detect the system clock change (it seems to work fine _within_
the VM though).

Despite this I wouldn't hand it out in it's current incarnation without more
widespread testing and, if that works out fine, not without some serious
warnings to the end users: "Don't rely on the time to perform
mission-critical tasks. Don't use on systems that change their clock rate
dynamically (even though some of the information in the referenced thread
might contradict that concern). etc etc".

// Johan