[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
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
>>> 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