On 11/16/2012 6:03 PM, Rob wrote:
Harlan Stenn <[email protected]> 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.
I might see some value of reacting to a port unreachable ICMP, but not
to a host unreachable one.
Brian.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
