[ntp:hackers] Does ntpd need to whine more ?
Poul-Henning Kamp
phk at phk.freebsd.dk
Mon Oct 3 17:33:27 UTC 2005
In message <43415774.5000808 at udel.edu>, "David L. Mills" writes:
>We are talking past each other. The issue of poll interval is related to
>time constant; indeed, that is the fundamental scaling assumption.
Do you recall my proposal to change the shift register to take not
the median, but the newest measurement that survives the selection ?
That does wonders for the timeconstant.
>The design intent is that the best recovery after an outage is using
>iburst mode, so it takes no more than 16 s to refresh the clock filter
>in that case, once the first response from the server arrives.
I may be seeing bugs in the implementation, but it looks to me like
the polling interval stays at 1024 even in case of iburst.
>It does not seem prudent to get more agressive than this; othewise
>something like the Wisconsin incident might happen again.
As long as we stay firmly at 64s or above Wisconsin should be safe.
>Your comment about rapid temperature excursions leading to steps is very
>relavent. I don't see that here in room temperature controlled
>environments, but laptops could be another story.
It depends wildly on the kind of hardware, with some correlation to
price, but also a lot on the A/C at the installation.
As I see it, the NTP clock is tuned for the good boys and makes
a really rough ride for the regular boys because of it. Most of
the hosts that poll my NTP server with > 256second poll rate
do not send me timestamps back that justify it.
>I don't understand your scenarios with cold rock behavior after a
>lengthy outage. My experience here with typical systems is within 50 ms
>after 36 h between ACTS updates and 10 ms after several hours of WWV
>signal loss, and this with cold rock frequency compensation up to a
>couple hundred PPM. I've run the ACTS and WWV drivers for several months
>without ever stepping.
Thanks to the refid="STEP" and ="INIT" it is possible to monitor this
in the client population. Steps correlate with poll interval which
to me indicates that the increase in poll interval was unwarranted.
>As for outage notification, the daemon does log reachability events now.
Yes, although the message could be improved.
>It could be that it should do this every hour or something like that; I
>have no problem with that.
I think we should do that as a first step. When I contact servers in
my client population and tell them that their NTPD isn't doing anything
the response is invariably: "Why didn't it tell me?!!"
>The NIST folks use the filegen facility and
>call the helpdesk beeper if something goes wrong in any of their servers.
As soon as you get into that level of operational service, custom
methods are called for.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the hackers
mailing list