[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