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).
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. 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. Aaron W. LaFramboise