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

Richard B. Gilbert rgilbert88 at comcast.net
Mon Apr 3 11:37:08 UTC 2006

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
> 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:

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!

More information about the questions mailing list