Unlike ntpd and chrony, systemd-timesyncd is an SNTP cllient, which means it does not keep track of the relative accuracy of multiple NTP servers in order to get the best measure of time that it can, nor does it keep track of and compensate for the local clock’s drift. If you are using NTP pool servers (the default on Debian), which are far away across the public Internet, you will get much better results with a full NTP client; if your NTP server is local, SNTP is sufficient.
Sure, there are differences. But here in the context of a desktop system, why is SNTP actually a bad choice? I’ve only ever seen one case where this is relevant - sync for amateur radio in digital modes. Otherwise… we’ve got every windows machine out there using effectively this kind of system for time sync. That’s almost every desktop in the world successfully using it.
That’s certainly an opinion… I feel like the author could link to something here. Otherwise, that’s how “I heard that” opinions become more common.
Unlike
ntpdandchrony,systemd-timesyncdis an SNTP cllient, which means it does not keep track of the relative accuracy of multiple NTP servers in order to get the best measure of time that it can, nor does it keep track of and compensate for the local clock’s drift. If you are using NTP pool servers (the default on Debian), which are far away across the public Internet, you will get much better results with a full NTP client; if your NTP server is local, SNTP is sufficient.Sure, there are differences. But here in the context of a desktop system, why is SNTP actually a bad choice? I’ve only ever seen one case where this is relevant - sync for amateur radio in digital modes. Otherwise… we’ve got every windows machine out there using effectively this kind of system for time sync. That’s almost every desktop in the world successfully using it.