[ntp:questions] Vista NTP tamed, but with a blunt object

Martin Burnicki martin.burnicki at meinberg.de
Tue Jan 27 09:13:56 UTC 2009


Dave Hart wrote:
> On Jan 22, 3:41 am, Martin Burnicki <martin.burni... at meinberg.de>
> wrote:
>> Dave,
>>
>> Dave Hart wrote:
[...]
>> > I could use some help testing from anyone interested in source or .exe
>> > files.
>>
>> If you send me a copy of the modified sources I can also give it a try
>> here.
>>
>> Martin
> 
> http://davehart.net/ntp/testbin/ntp-4.2.4p6-DLH-QPC-20090121-src.zip
> 
> Beware I've pissed all over the place and haven't spent a lot of time
> cleaning up, thinking about what really should be debug or not, have
> made modifications outside the ports directory like switching from the
> event log to configured file logging sooner (though still after
> startup if using the configuration file to specify the logfile, from
> the start if you use the command-line -l switch.  This is just the
> latest snapshot of my ongoing work, taken to match binaries no one has
> asked for but are available at:
> 
> http://davehart.net/ntp/testbin/ntp-4.2.4p6-DLH-QPC-20090121-bin.zip
> http://davehart.net/ntp/testbin/ntp-4.2.4p6-DLH-QPC-20090121-debug-bin.zip

I have run the binary on a Vista 32 machine here, against a single NTP
server on a local net. Here's the loopstats graph over the weekend (about 3
days):
http://www.meinberg.de/download/ntp/graphs/loopstats-ntp-4.2.4p6-DLH-QPC-20090121-vista32.startup.pdf

The graph is pretty clean, without jitter, and it took only 3 days (!) to
eliminate a time offset of 25 milliseconds :-((
I don't think the slow response is due to Dave (Hart)'s changes, but due to
the slow NTP control loop. 

Haven't checked, but I'm sure there has been a driftfile available from
running the standard version of ntpd, and I'm sure the value in the
driftfile had not been correct, so Dave's patched version of ntpd started
with a wrong drift value, but even this is the case it should be possible
to determine the real drift and time offset in less than 3 days.

The test above was run without using ntpd's -M flag, so ntpd did not set the
MM timer to higher resolution. After the weekend I have started Apple's
Quicktime on that machine, kept it running with the startup screen (without
playing some video), then stopped Quicktime. See the complete results:
http://www.meinberg.de/download/ntp/graphs/loopstats-ntp-4.2.4p6-DLH-QPC-20090121-vista32.pdf

It's not Apple's Quicktime which must not be blamed for this, and also not
NTP. It just demonstrates the poor timekeeping under Windows where any
simple user space application can completely mess up the timekeeping of the
system clock.

The reason why I had added the MM timer stuff to the NTP code for Windows is
just to get around this deficiency of Windows.

Though Dave's approch for Vista is good, IMHO the final goal should be to
get this working properly even if the -M flag is being used.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list