On 2020-10-21, Miroslav Lichvar <mlich...@redhat.com> wrote: > On 2020-10-21, William Unruh <un...@invalid.ca> wrote: >> On 2020-10-21, CRasch Net <cra...@crasch.net> wrote: >>> Facebook is now using Chrony, you can read about their implementation: >>> >>> Building a more accurate time service at Facebook scale >>> https://engineering.fb.com/production-engineering/ntp-service/ >> >> Interesting. While I agree that chrony is more precise, I think that >> their results for ntpd are worse than they should be. ntpd can >> certainly do better than 1ms scatter/accuracy (and chrony can do better >> than 100us.There is something weird about their network paths.) About 10 >> years I ran a number of tests of chrony vs ntpd. and got about a fctor >> of 3-10 better, not 100. Interrupt latency/clock reading for chrony gave >> about 1us fluctuations. > > It's not clear how ntpd and chrony were configured in their tests. The > ntpq/chronyc outputs show a poll of 6, which is too long for a highly > stable synchronization in a local network. If they were using the > default minpoll 6 and maxpoll 10, a factor of 100 would not surprise me. > ntpd doesn't adjusts its polling very well when it has stable > measurements, so it would be effectively comparing ntpd polling at 10 vs > chrony polling at 6. > >> I find this whole thing about leap second smoothing to be a real farce. >> Just let the step occur instead of delivering the wrong time for hours. >> Or if you want, run your clocks on TIA not UTC and make the leapsecond >> conversion in the interpretation as is done for timezones. Would anyone >> advise leap day smoothing every 4 years so that we do not have trouble >> with our calenders? > > Well, yes. The trouble is that there are applications that break on > backward step, they need synchronized clocks, and not all NTP clients > can be configured to make a consistent slew on the leap second. So, the > easiest way to fix this is to make a slew on the server and hide the > leap second from the clients. When you internally do this everywhere and > you want to provide a public NTP service, it's easier to just serve your > internal leap-smeared time.
Easier. It is probably even easier to forget about ntp and just free run your server. "Easy" is not the purpose of serving ntp time. > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
