Hello.
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
(10-15%).
Any suggestions?
Thank you in advance.

At 1:24 PM -0800 2005-01-26, Greg555 wrote:

>  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
>  (10-15%).

	I don't know anything about "multimedia timers", but Windows is 
known to be seriously broken when it comes to dropping interrupts, 
etc....  You will find that ntpd does what it can in the face of such 
serious problems, but there's only so much it can do.

	If "multimedia timers" cause such problems for you, is there a 
particular reason you use them?

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

Greg555 wrote:
> Hello.
> 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
> (10-15%).
> Any suggestions?
> Thank you in advance.

As already mentioned several times in this news group, Windows is a lousy
timekeeper.

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. 


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin,
Does NTP service really relies on multimedia timers ? I'm surprised,
because QueryPerformanceCounter should give a much more stable and
precise results.

Vadim  Zlotnik wrote:

> Martin,
> Does NTP service really relies on multimedia timers ? I'm surprised,
> because QueryPerformanceCounter should give a much more stable and
> precise results.

NTP does not use the Windows multimedia timers. 

In fact, NTP uses the PerformanceCounter to interpolate the Windows system
time between the 10 or 15 millisecond timer tick intervals, in order to
increase the resolution of the Windows system clock.

This is achieved by an extra thread which is being run as close as possible
to each timer tick. The thread reads the standard system time which has
just been updated due to the timer tick event, and the PerformanceCounter
at the tick time. The high resolution time is then the standard system time
at the last recent tick plus an estimate of the fractions of the current
tick interval based on the difference of the PervormanceCounter values.

Unfortunately, it seems that either the system time value which is read at
each tick is wrong, or the thread is being delayed whenever the multimedia
timer resolution is changed from default to the highest resolution. I
haven't found that out, yet.

So NTP is affected by the multimedia timer even though it doesn't use them.

BTW, I've seen this with several multimedia applications, I just used
Quicktime as an examle. If one application has changed the multimedia timer
resolution then running additional multimedia applications doesn't have
additional effect.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany