[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 
> writes:
>> =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:
>>> ...
>>> 123 no 4 3 11 7 -17 -861.909907751 [LOCALCLOCK#0]
>>> 123 no 4 3 11 10 -17 -656.351917002 [LOCALCLOCK#0]
>>> 123 no 4 3 11 10 -16 -552.525271231 [LOCALCLOCK#0]
>> I believe there are two main culprits which make people put the LOCAL 
>> clock
>> 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 mailing list