[ntp:questions] why does asterisk still show after the ntp server is shutdown?

unruh unruh at invalid.ca
Sat Nov 17 18:19:23 UTC 2012


On 2012-11-17, Brian Utterback <brian.utterback at oracle.com> wrote:
> On 11/16/2012 6:03 PM, Rob wrote:
>> Harlan Stenn <stenn at ntp.org> wrote:
>>> I don't understand the problem.
>>>
>>> It doesn't matter why the destination machine is unreachable, or when it
>>> becomes unreachable.
>>>
>>> Time from that source is valid for "a while", and after a known number
>>> of unsuccessful attempts to reach that server it will be unselected.
>>>
>>> So what's the issue?
>> It is just another incarnation of a FAQ in this group.
>>
>> People apparently get tasked with evaluating and testing the performance
>> of NTP in the case of errors and failures.  When it does not perform
>> as well as they (or their bosses) hope, they come and ask here.
>> They like instant detection of server outage, predictable action in
>> case of failure of primary or secondary servers, and usable interfaces
>> for error reporting and handling.
>>
>> It is like the other FAQ: how can I achieve perfect time synchronization
>> on my lousy hardware.  Just when you think 10ms is pretty good, they
>> ask for 1ms.  And when 1ms seems reachable, they want 1us.  And not just
>> a best effort to be in that ballpark, but a "guarantee".
>> It is not like most people really need that accuracy, but they get
>> specifications that are written up by people who do not understand how
>> hard it is to achieve them on standard computer and network hardware.
>>
>> The problem is not that ntpd would not perform well in cases occuring
>> during day-to-day use, they want to write documents that tell the
>> client or user what will happen when there is a problem and how this
>> will be signaled and handled.
>
> Harlan's point is a good one. Whether or not it would be difficult to 
> receive ICMP's and match them up, it is not worth the trouble since 
> there is no action to take from the information. The mechanism for error 
> detection and recovery is the same regardless of whether you got 
> notification actively through ICMP or passively through a missing packet.

What the OP wanted is for ntpd to immediately drop the synchronized flag (*)
as soon as the remote machine was unreachable for any reason whatsoever
(bad network, host problems,...) As such it is not only "not worth
thetrouble" but against the design philosophy of ntpd for error
recovery, as I understand it. Ie, if a packet gets lost, either because
of network problems or server problems, ntpd will wait a while to see if
the remote server comes back up befor it gives up on it. 
That is just the nature of the beast. IF you really want to have a flag
that tells you that there is trouble, look at the reach and if it is not
377, yell. Ie, ntpq IS giving you all the information you need. Use it,
and do not complain because one of the flags is not behaving as you
might want it to behave. (Of course the OP question could simply have
been curiosity as to how ntpd works, and really have nothing to do with
a desire to see it work a specific way).

>
> I might see some value of reacting to a port unreachable ICMP, but not 
> to a host unreachable one.
>
> Brian.



More information about the questions mailing list