Here are some updates based on overnight running of "ntpq -p" every 10
seconds.
win7 is running w/ minpoll=maxpoll=32, Linux is running as just
standard NTP install (fedora 12).
win7 NTP is version 4.2.7p98 overlayed on top of Meinberg install.
Linux NTP is version 4.2.4
Offset, delay and jitter values from ntpq -p are plotted below.
What is seen is that after flaying around wildly for some time win7
starts to settle down, though zooming in shows that it is still
swinging around quite a bit though in smaller steps.
http://www.atl.external.lmco.com/projects/QoS/documents/feb24_1.png
http://www.atl.external.lmco.com/projects/QoS/documents/feb24_1_zoom_1.png
http://www.atl.external.lmco.com/projects/QoS/documents/feb24_delay.png
http://www.atl.external.lmco.com/projects/QoS/documents/feb24_jitter_1.png
Gautam
Gautam,
I would have said those figures are broadly similar to what I see on the
LAN-synched, Win-7 64-bit PC Alta here, including the offset and jitter
values, except that when I rebooted Alta at 07:00 UTC yesterday there was
no transient at all. I wonder whether you've never let NTP run long
enough that a drift file was created (although I thought that was one
hour, and I recall you saying NTP had been running for some time).
So I think your problem may have changed from "why doesn't it sync?" to
"why doesn't it sync more quickly?". The tail in offset once the sync has
started is typical of the reference NTP - but the oscillation I have only
seen when the drift file has been way out, or NTP has two servers telling
it different times.
Cheers,
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
