Ry wrote:
On 4/2/06, Danny Mayer <[EMAIL PROTECTED]> 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
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
