In a message dated 2/13/04 7:07:06 AM Eastern Standard Time,
[email protected] writes:
Up to now, the only way I found to synchronise the software and the hardware
clocks is to switch the computer off and on again.
Any Windows guru on this mailing list ?
I used to write applications for Windows 3.x and 9x that displayed time more
precisely than most thought possible with Windows, but I'm not enough of a
guru to have figured out a good solution for NT-based versions yet. With
programs no longer having direct access to the hardware, the time is whatever Windows
says it is. I expect there are still ways to trigger reading of the system
clock, but there will always be slippage of an unknown number of "ticks",
depending on what processes are running and what priority they have.
You can never know for certain how long the time is between issuance of a
request via software and its execution, because your software's request and all
other messages in the queue affect the outcome--not unlike trying to
simultaneously measure the position and velocity of subatomic particles.
The additive effects of such "virtual clock jitter" at both the sending and
receiving ends can be accomodated by inherently tolerant visual modes at
extremely slow data rates, but I fear that to achieve the breakthroughs we'd all
like to see, we'll need more precision.
Synchronizing a GUI-based operating system to a timeserver over the Net
involves a lot of variables, each of which changes somewhat over time. That's why
VE2IQ's GPS-synched AFRICAM only runs in DOS, and goes as directly to the
source as possible for its timing information. Thus far, the results seem to be
worth the slight extra effort.
73
John
|
