mlichvar

PTP over Internet doesn't make much sense. PTP requires hardware support in all network devices on the path between the (grand)master and slave. Without this support it will generally perform worse than NTP. Of course, it depends also on the implementation.

PTP does support unicast messaging, but it is not meant to be used as a public service. There are two major problems: It's not stateless and it has a huge traffic amplification, which could be easily exploited for DoS attacks.

Another possibility to improve reliability with SD cards is to use a distro that is designed to not make any writes to the storage in normal operation. I have some NTP servers running on OpenWRT and they work great.

Good support for PTP in network switches is rare. If the users don't want to spend a lot of money on new switches with PTP support, they can synchronize clocks in the network with a protocol which doesn't require special support in switches.

I maintain an NTP implementation. That comparison doesn't seem fair to me. It looks like they are comparing the old reference NTP implementation and not really the protocol itself. An NTP implementation can certainly synchronize clocks with better accuracy than 1 millisecond, or even 1 microsecond with hardware timestamping and good network switches.

There are some interesting ideas in the Huygens paper, but I don't see anything that couldn't be done also with NTP.

> Just saying "Yes" here is highly misleading.

FWIW, the page also compares the number of reference clock drivers. chrony does not have any HW-specific drivers, but there is an interface which other programs can use to provide the timing data. The most commonly used reference clocks these days are GPS receivers, which are well supported by gpsd.

xterm is showing all data. That's why it's slower. For a fair comparison, you should set the fastScroll X resource, which will allow xterm to suppress screen refresh.

The problem with this solution is that it's very expensive. Imagine couple hundreds of millions of computers making a TLS connection every few minutes.

For NTP there is Autokey (RFC 5906), which allows authentication of the servers with public-key crypto. It has various problems, one of them is that it's insecure.

The NTP working group is currently preparing a Network Time Security specification and its implementation in NTP, which is supposed to replace Autokey.

https://datatracker.ietf.org/wg/ntp/documents/

Writing new implementations of the systemd interfaces for systems which don't use systemd seems reasonable, but I think it's interesting there was a need to reimplement the timedated interface on a system that does use systemd and supports no other init.

I wrote a replacement for the systemd-timedated service for Fedora. The reason was simple, it could no longer control other NTP clients than systemd-timesyncd (which technically is just an SNTP client). With timedatex, users can now enable and disable with the "NTP sync" checkbox in GNOME any NTP client as was originally supported by systemd-timedated.

https://github.com/mlichvar/timedatex

chrony maintainer here. If the initial sync is slow, it probably means the initial offset of the clock is large and chronyd is correcting it by slewing, which may take a long time. You can use the initstepslew or makestep directive to step the clock on start. A configuration optimized for a fast and tight sync with a local NTP server could be:

  server ntp.lan minpoll 2 maxpoll 4 iburst
  makestep 0.1 1