Martin Burnicki wrote:
David Lord wrote:
I had maxpoll set at 10 when I first setup my network but sometimes
at that poll rate combined with daily temperature variations offsets
would gradually increase both in +ve and -ve directions. This could
clearly be seen in mrtg graphs. Solution was to reduce maxpoll to 7
or 8. I never thought of this as a bug. There was a daily variation
depending on season and a variation due to system load.
This has been with NetBSD 1997 to date and a period of a few years
when running FreeBSD. Currently NetBSD-6, ntp-dev-4.2.7p401, four
of the servers are in the pool.
I think we need to distinguish if there's a computational problem in the
code due to a rounding error, range overflow, or similar, or a
systematic problem, where ntpd is in general unable to apply adjustments
fast enough to compensate frequency drifts varying fast with temperature
changes.
Which the former can be fixed in the code once the wrong code has been
detected, the latter can only be changed by redesigning ntpd's behavior.
As far as I know long polling intervals are used preferably to increase
the accuracy of the drift measurement. For example, if you want to see
if your wrist watch goes fast or slow, you can't see this properly if
you check it once per minute. However, if you check it after one day you
see how many seconds the wrist watch has gained or lost.
However, as I understand this, this only yields proper results if the
frequency doesn't vary too much over the measurement interval.
So if ntpd only compares the time once every 1024 s the frequency may
have increased and decreased again during this interval, e.g. due to
varying CPU load, without this being noticed by ntpd. So the correction
computed in such case is probably not optimal.
From my understanding it would be better if ntpd polled in shorter
intervals to detect if the frequency drift is constant, or not. If it is
not it could decrease the polling interval to react faster on frequency
changes.
However, changing the latter would need some reengineering of the
control loop.
My server with Sure gps/pps has offset below 3 us other than when
nightly cron jobs give a couple of 35 us spikes. From loop_summary
over 7 days, typical range for rms offset is 3.9-6.1.
Over 7 days my four pool servers have following rms offset ranges
ntp0=784-1646, ntp1=405-837, ntp2=310-434, ntp3=586-1270 but there
were numerous reboots and ntpd restarts over that period.
I want to try using a stable external system clock source, TCXO,
OCXO or rubidium laser.
David
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
