[ntp:questions] Re: NTP client on Windows platform provides less accurate results then on the UNIX or Linux. Why?

Ernie Mikulic (emikulic) emikulic at cisco.com
Wed Apr 12 19:48:21 UTC 2006


Dated but interesting paper from Audio Engineering Society Convention 2004
regarding An Internet Protocol (IP) Sound System. PP#5-6 [Microsoft]
discusses NTP use and possible modifications they would have made to make it
more accurate. [pdf attachement]

-----Original Message-----
From: questions-bounces at lists.ntp.isc.org
[mailto:questions-bounces at lists.ntp.isc.org] On Behalf Of Richard B. Gilbert
Sent: Monday, April 03, 2006 4:37 AM
To: questions at lists.ntp.isc.org
Subject: [ntp:questions] Re: NTP client on Windows platform provides less
accurate results then on the UNIX or Linux. Why?

Ry wrote:

> On 4/2/06, Danny Mayer <mayer at ntp.isc.org> wrote:
> 
>>That should have no more affect on NTP than anything else running on 
>>the box. We have seen no such affects. If you want to report a problem 
>>then you need to send much more detail.
> 
> 
> I'm not reporting a specific issue, I'm just pointing out potential 
> problem areas for the original poster to look at. Additional, 
> systemic, asymmetric latency on the Windows machines would certainly
<snip>
> 
> On both of my stratum-2 boxes on Windows 2003sp1, they converge to 
> withing a half-dozen milliseconds in about 8 hours. But after running 
> for several days, they seem to converge to within ~1 ms offset. I 
> don't know why that is, but NTP certainly does seem to get better on 
> my Windows machines over longer periods of time. When I frequently 
> restart a machine, I never get much better than 10ms accuracy. I don't 
> know why that is, other than NTP isn't disciplining the clock during 
> the actual shutdown and restart.
> 
> Of course drift would only be about 2 ms per minute of NTPd downtime 
> on a 30ppm machine. But it seems to me after NTPd is down it over 
> corrects a bit with the drift calculation and I get a few swings 
> before it settles in after 8 or so hours. I posted a chart of this 
> "restart over correction" on an XP box at:
<snip>

I have noticed similar overcorrections when starting my Sun Ultra 10/Solaris
8/ntpd 4.2.0.  This machine is equipped with a Motorola Oncore reference
clock.  It started up about ten milliseconds off, started correcting and
overshot by nearly ten milliseconds.  It then overshot in the other
direction. I didn't time the process but it took at least thirty minutes to
settle down.  I think I could have figured it out faster with pencil and
paper!

_______________________________________________
questions mailing list
questions at lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions


More information about the questions mailing list