[ntp:hackers] Does ntpd need to whine more ?
David L. Mills
mills at udel.edu
Mon Oct 3 14:18:30 UTC 2005
There is a fundamental misunderstanding here. The clock discipline is in
fact a flywheel which is nudged at each poll update to correct the time
and update the frequency estimate. If you stop nudging it for awhile it
may accumulate error, but not much. How long should you wait before
declaring unsynchronized? The fact the source becomes unreachable is not
relavent. Different clients may have different ideas about this based on
the statistics provided in the packet header, but the server can't make
a prior decision.
The clock discipline algorithm is very good at estimating the optimum
time constant. It does not in general improve performance to oversample
by reducing the poll interval. It does make sense after recovering from
an outage to fill up the clock register and that's what iburst is for.
Don't fight the discipline; work with it. You are invited to concoct
counterexamples, but I will believe them only if confirmed by actual
scenarios in vivo or better yet in simulation.
The local clock is a terrible idea, unless for the only purpose to
wrangle a herd to a common timescale in response to a loss of outside
synchronization. Usually, it is better to just coast each cow
separately, as that results in a residual error of less than a few
millisecons per day. To confirm that, see the behavior of the ACTS
driver with poll interval 36 hours. The residual error is seldom greater
than a few tens of milliseconds.
The so-called ghetto mode (renamed orphan mode) does a much better job
as herd wrangler, assuming broadcast capability is available. This
eliminates the need to engineer the subnet with a defined backup
I didn't know that some suppliers toss in the local clock driver in
default configurations. That is evil, misguided and dangerous, unless
the naive user understands what it does and the hazards involved.
Poul-Henning Kamp wrote:
> In message <200510022332.27677.Mark.Martinec at ijs.si>, Mark Martinec
>> =46rom Poul-Henning Kamp :
>>> I examined the client population of my public NTP server today and one
>>> of the things I noticed is that people don't seem to notice when their
>>> time sync stops working and falls back to localclock or bogusly
>>> configured refclocks:
>>> 18.104.22.168 123 no 4 3 11 7 -17 -861.909907751 [LOCALCLOCK#0]
>>> 22.214.171.124 123 no 4 3 11 10 -17 -656.351917002 [LOCALCLOCK#0]
>>> 126.96.36.199 123 no 4 3 11 10 -16 -552.525271231 [LOCALCLOCK#0]
>> I believe there are two main culprits which make people put the LOCAL
>> driver in their ntpd configuration:
> It's not LOCALCLOCK I'm after, it's the fact that ntpd doesn't tell
> the user that it has lost external sync.
> I'm also wondering the wisdom of not slamming the poll rate back
> to 64 seconds when the shift register runs empty. With a poll
> rate that has grown to 1024 it takes an hours after connectivity
> is back before it even pays attention to the timestamps and
> several hours before it is back in tolerance.
More information about the hackers