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. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
