[ntp:hackers] Does ntpd need to whine more ?

David L. Mills mills at udel.edu
Mon Oct 3 14:41:55 UTC 2005


I'm confused about the quoting here. I think my comments go to Tim, not you.

The message shows a clear misunderstanding of the physics involved. The 
ntpd clock discipine results from twenty years of devolopment, 
simulation and refined implementation. It has been verified by analysis, 
experiment and simulation. From experience, there have been 
implementation bugs since corrected over the years and there may be more.

If you want to roll your own, I would be delighted to compare 
performance, but only if you have hard data. The best way to do this is 
rip out the clock discipline in ntpd, replace with your own and run 
simulations. It really isn't very hard and does reveal performance in a 
dramatic way, especially when adapting to changing network jitter and 
frequency wander.

Be advised the NTP WG will likely include the ntpd clock discipline as a 
required component of a conforming intermediate server that synchronizes 
to an upstram server and provides synchronization to a downstream 
client. This is necessary for stability in a distributed, multi-stratum 
subnet. If you have other agendae, whou should particiapte in the 
discussions and make your opinions known.


Poul-Henning Kamp wrote:

> In message <43410902.nailKAX17KIJN at mini-me.trailing-edge.com>, Tim 
> Shoppa write
> s:
>>> I'm also wondering the wisdom of not slamming the poll rate back
>>> to 64 seconds when the shift register runs empty.
>> Slamming back to minpoll when a host becomes unreachable is a fairly
>> evil behavior (and also one that OpenNTPD has). What good does
>> polling a sick host (either broken, or nonresponsive due to network
>> difficulties) more often do?
> First: you don't have to slam it back down until it replies first time.
> Second: do the math and you can see your argument is bogus:
> 10000 hosts at 1/64 seconds = 156 packets/second. (< 100kbit/sec).
> If you host cannot deal with that, it has no business being A NTP
> server (any more ?).
>> If you implicitly do not trust the PLL behavior of tuning local drift,
> I _explicitly_ do not trust NTPDs PLL, and have therefore written my
> own But that is an entirely different matter.
> This is about how long time a client spends after reachability is
> restored before the clock is locked again (and wether it should
> have told you more loudly that it had lost reachability).
> Several hours is waayy too long IMO.

More information about the hackers mailing list