Spoon wrote: > Richard B. Gilbert wrote: > >> Spoon wrote: >> >>> ntpd kicked my clock forward one second on January 1 at 00:19:38 UTC. >>> >>> (My ntp.conf lists 12 servers. Delays range from 28 to 48 ms.) >> >> >> Unless you have a custom version of ntpd, > > > I didn't modify the source in any way. > >> I believe that ten servers is the absolute maximum! >> I believe that ntpd will ignore the extras. > > > The documentation for ntpq does state: > ( http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html ) > > . excess > > The peer is discarded as not among the first ten peers sorted by > synchronization distance and so is probably a poor candidate for further > consideration. > > But I've tested a configuration with 225 servers, and none were > considered excess. (While 16 were considered candidate.) > > for TALLY in '*' '+' '-' '#' '.' ' ' 'x' ; do > N=$(grep -c "^\\$TALLY" DUMP) > echo "$TALLY : $N" > done > > * : 1 > + : 16 > - : 33 > # : 114 > . : 0 > : 57 > x : 4 > >> Four, Five, and Seven are the magic numbers to protect against the >> failure of one, two, and three servers. Note that "failure" can mean >> either a server failing to respond to queries or a server with a >> blatantly incorrect time. I have not tested this but I believe that >> ntpd will always select both the server with the "one true time" and >> an "advisory committee" of three servers if there are sufficient >> servers available to do so. >> >> I'd suggest trimming your server list to the five or seven servers >> closest to you in net space; e.g. the ones with the lowest value of >> delay. > > > I had never considered I could set up /too many/ servers. I had always > thought ntpd would just pick the N best. > >> FWIW it's rare to be able to FIND ten servers that are close to you! >> Ten GOOD servers ranks close to miraculous. Again, FWIW, even most of >> the "bad" servers know what time it is but the network between you and >> the server has enough jitter to mangle the time. > > > I can "see" 40 servers for which the delay is less than 60 ms. > The jitter is less than 2 for most (90%) of them. > (I suppose there are other metrics to consider before calling > a server good or bad?) > > Regards.
The error in transmitting the time from server to client is limited to one half the round trip time. It's usually far less than that but cannot be greater. So servers close to you (low delay) should generally provide better time. A good way to learn what's good and bad is to use a hardware reference clock such as a GPS receiver. A timing receiver with PPS output will generally keep the leading edge of the PPS within 50 microseconds of the "top of the second". The very best internet servers will agree with the GPS within two or three milliseconds. A very poorly chosen server might be out by 100 milliseconds or more. By very poorly chosen, I mean something like someone in New York City configuring ntpd to use a server in Tokyo! A server with a GPS reference will open your eyes to the atrocities committed by typical internet connections! _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions