kb...@n1k.org said: > I would strongly suggest that with NTP ???more is better???. Three reference > devices is about the minimum. Five is a good target to aim for.
I think it's more complicated than that. Quality over quantity. Using more servers does give you a better chance at getting a good one, but that's not the usual reason for discussing how many servers to use. If you are using 3 servers, 2 can outvote a bogus one. (Mills calls good servers truechimers and bogus one falsetickers.) If one of the 3 servers is down, that doesn't work any more. Add more servers and you can work out what happens if 2 are down or 2 are bogus. -------- After an exchange of NTP packets, the client has 4 time stamps: the time when the request left the client the time when it arrived at the server the time when the response left the server the time when it arrived back at the client 2 of those times are using the client's clock and 2 are using the server's clock. There are 3 unknowns: the transit time in each direction and the offset between client and server clocks. The 4 timestamps give you 2 equations. ntpd gets a 3rd equation by assuming that the transit times are equal - symmetric routing. That lets you solve for the clock offset. If you have a good local clock, you can assume the clock offset is 0 and solve for the transit times. ---------- > If you have a symmetric delay on your connection to the internet ( delay up > and delay down are the same) then indeed net based devices can do quite > well. It???s a rare basement lab that has this sort of connection. Yup. But lets look at some numbers. Assume the downlink is super fast so we can ignore that delay. So all the delay on the uplink turns into assymetry. Assume an NTP packet is 100 bytes. Assume a byte is 10 bits. That's 1000 bits. If your uplink is a megabit, that is 1 ms. Compare that to network routing delays. In general, the farther away (hops, not miles) a server is the more likely it is that the request and reply will take different physical routes. If the physical distance (miles) is long there is a good chance that different physical routes will have different lengths and hence different delays even if the hop counts each way are the same. I'm in Silicon Valley. NIST has servers in 3 locations in the Boulder CO area. The servers at NIST and WWV appear to be off by 6 or 7 ms. The servers at U of Colorado are off by 5 ms in the other direction. The other source of network asymmetry is queuing delays. This often gets ugly due to bufferbloat. That usually happens on the last mile link. My old slow DSL line could get delays over 3 seconds. ;) It was easy to spot long downloads by looking at the NTP data. You can make a wedge diagram. For each packet pair, plot the average transit time on the X axis and the clock offset assuming symmetry on the Y axis. You should get a wedge pointing to the left. The points along the edges of the wedge are routing delays in one direction when there were no delays in the other direction. Points in the middle of the wedge encountered routing delays in both directions. Note that routing delays change, both short term (hours) as links go up/down and long term (months, years) as people/companies move or change ISPs and anybody in the path adds/retires a link. Just because it looks good now doesn't mean it will be good in an hour, or tomorrow, or next year. ---------- That's all a longwinded way of saying that finding good local servers is likely to work better than just adding more servers. ---------- Geek note: If you are running a NTP server (without a local refclock) the asymmetry on your local link cancels out. Your clock will be off a bit due to the asymmetry on packets used by your NTP client. That will cancel out the asymmetry when your ntpd is acting as a server. -- These are my opinions. I hate spam.
_______________________________________________ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
