[ntp:questions] How is the BIG guys (Google. FB etc) DNS and NTP architecture

William Unruh unruh at invalid.ca
Wed Oct 21 15:59:51 UTC 2020

On 2020-10-21, Miroslav Lichvar <mlichvar at redhat.com> wrote:
> On 2020-10-21, William Unruh <unruh at invalid.ca> wrote:
>> On 2020-10-21, CRasch Net <crasch at 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. 

More information about the questions mailing list