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
"Aaron W. LaFramboise" <aaronrabiddog51@aaronwl.com> wrote in message news:40AAC274.1060707@aaronwl.com... 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