[ntp:questions] Re: ntpd and multimedia timers, Win2K, XP
martin.burnicki at meinberg.de
Thu Jan 27 13:18:57 UTC 2005
> We are running our application on quad (8 due to HT) Proliant server
> and it uses Windows multimedia timers in order to handle several
> timeouts in it. And this usage of timers freaks out the ntpd service.
> When the application works - the windows time goes forward with average
> of +0.5 sec offset in a minute. That is we have a 30 sec offset after
> one hour after ntpd restart. Needless to say, that without ntpd, the
> original computer clock performs much better.
> When the application doesn't use multimedia timers - the clock is +-4
> ms from GPS clock. The system is running on very low CPU usage
> Any suggestions?
> Thank you in advance.
As already mentioned several times in this news group, Windows is a lousy
I've also observed a strange behaviour with the time adjustment service I've
written, both under Win2k and WinXP. The service reads the time from a GPS
PCI board manufactured by our company and adjusts the Windows system time.
In the normal case Windows timer callbacks are called at constant intervals
depending on the Windows timer tick rate, i.e. 10 or 15 milliseconds.
However, as soon as any application is started which uses the Windows
multimedia timer and sets it to the highest resolution, i.e. 1 millisecond,
the normal timer callbacks are constantly delayed by several milliseconds
as long as the other application is running. After the the other
application has been terminated, the delay disappears.
I've just tested this with the recent NTP version from the BK repository on
a WinXP machine.
After the NTP service has synchronized the system time to a stratum-1 server
(i.e. "ntpq -p" has reported an offset less than 1 millisecond), I've
started Quicktime on that machine. I've just loaded Quicktime, without
playing any movie.
After the next pollling interval you can see the delay I've mentioned above
in the NTP filter using ntpq's rv command:
filtoffset= -12.07 -0.09 -0.07 0.01 -0.06 -0.07 -0.04 -0.04,
The first value in the line is the time offset which has been determined
from the last recent poll, which is about 12 milliseconds here after
Quicktime has been started. The other values are the offsets computed at
previous polling cycles, which are all well below 1 millisecond, when
Quicktime was not running.
After a few NTP polling intervals I've terminated Quicktime, and again after
the next polling cycle the NTP filter reports a much lower offset:
filtoffset= 3.59 -12.07 -12.16 -12.07 -0.09 -0.07 0.01 -0.06,
Of course the offset is not as small as it has been initially since the NTP
service has already started to compensate the 12 millisecond delay.
A workaround would be to make sure the multimedia timers are always being
set to highest resolution. In this case the NTP service would initially
compensate the additional delay. The NTP service could indeed set the
multimedia time to the highest resolution by itself.
Unfortunately I've also observed the timer callback interval is jittering by
+/- 1 millisecond if the multimedia timer is being used. I.e. if the
nominal interval is 10 milliseconds, the callback seems to be called after
9, 10, or 11 milliseconds.
We'd have to see whether this jitter is more acceptable for the NTP daemon
than the constant offset.
More information about the questions