On 2014-12-09, Mike Cook <michael.c...@sfr.fr> wrote: ><snip> >> >> >>> >>>> Three are fine, as long as only one dies or goes nuts. >>> >>> Again, define "goes nuts". You don't seem to like the term >>> "falseticker", so how do you define "goes nuts"? If one "goes nuts" or >>> even goes offline, if the remaining two do not agree then it is like >>> having no server at all. >> >> No, it is like having two, with one being out. >> falseticker is a term with a very specific internal definition. Thus a >> server whose time is right on UTC could be a falseticker, because the >> other two servers were both exactly 3 days out, with tiny jitter estimates. >> I would say then that you had two servers going nuts, and one good, even >> though ntpd would say there were two good and one false ticker. > > In fact this does not happen. I just tested the hypothesis. > What happens depends on how the two wayward get there exaggerated offset: > a) someone,something resets the date: > result: ntp on both those servers crashes due to the panic_stop limit. > > So in this case the client has only one reference and continues using that. > It is not flagged as a falsticker. > That is normal.
I gave an example. The server is set up with the localclock driver, and its gps puck goes down. It gaily keeps delivering the time which drifts off further and further. It goes nuts in other words. > > b) someone restarts ntp on the servers with the wrong date. Here the servers > ntpd has no way of knowing that it has bad time and so continues serving > normally. > On the client. The running ntp sees immediately a huge offset and huge > jitter. > > Tue Dec 9 13:15:04 CET 2014 > remote refid st t when poll reach delay offset jitter >============================================================================== > *192.168.1.15 .GPS1. 1 u 320 64 360 0.549 0.040 0.037 > +192.168.1.16 .GPS2. 1 u 37 64 377 0.606 0.006 0.028 > +192.168.1.17 .GPS1. 1 u 309 64 360 0.576 0.027 0.025 > Tue Dec 9 13:16:08 CET 2014 > remote refid st t when poll reach delay offset jitter >============================================================================== > 192.168.1.15 .GPS1. 1 u 55 64 341 0.565 0.042 9660780 > *192.168.1.16 .GPS2. 1 u 37 64 377 0.606 0.006 0.024 > 192.168.1.17 .GPS1. 1 u 42 64 341 0.579 0.041 9660773 > > After 5 mins the client is unable to resolve this and declares all clock > falsetickers and then panics. I did not have ntpd in debug mode here, but it > is reasonable to assume that it panics due to the selected clock being too > far out and hitting the panic limit. Ie, clockhopping. It cannot decide. But while the server clock slowly drifts away it gives a terrible time. If you want microsecond accuracy, 128ms is a HUGE distance off, without triggering a complete crisis in the client. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
