chrony vs. systemd-timesyncd - Каковы различия и варианты использования в качестве клиентов NTP?

Как правильно указано в другом ответе, chronyреализует NTP и systemd-timesyncdSNTP.

С точки зрения клиента службы времени:

SNTP — гораздо более простой в реализации протокол;
NTP допускает шаг -с шагом -приращения/коррекции по времени. Одним из основных преимуществ NTP является то, что он также учитывает RTT ответа для получения более точного времени.

Изhttps://www.meinbergglobal.com/english/faq/faq_37.htm

While a full featured NTP server or client reaches a very high level of accuracy and avoids abrupt time steps as much as possible by using different mathematical and statistical methods and smooth clock speed adjustments, SNTP can only be recommended for simple applications, where the requirements for accuracy and reliability are not too demanding. By disregarding drift values and using simplified ways of system clock adjustment methods (often simple time stepping), SNTP achieves only a low quality time synchronisation when compared with a full NTP implementation.

SNTP adopts a much simpler approach. Many of the complexities of the NTP algorithm are removed. Rather than skewing time, many SNTP clients step time. This is fine for many applications where a simple time-stamp is required. Additionally, SNTP lacks the ability to monitor and filter multiple NTP servers. Often a simple round-robin approach is used, where if one server fails, the next one in a list is used

Изhttps://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

NTP is far more accurate and precise than SNTP, and this makes it the de facto winner in most enterprise applications. On the other hand, the simplicity of SNTP makes it more appropriate for things like IP cameras, DVRs and some network switches. These types of hardware lack the processing resources to handle more complex protocols, but as connected devices become increasingly powerful, that may change.

One major weak point of SNTP is that you can't make it more accurate by retrieving time from multiple sources like Network Time Protocol does by default.

Еще один важный момент: я вижу, что реализации SNTP создают больше проблем, чем NTP в виртуализации, когда у вас есть и гипервизор, и демон NTP, пытающиеся изменить время виртуальной машины. Особенно, когда они не согласовывают время с некоторой неправильной конфигурацией, из-за которой они оба становятся активными, это может вызвать большие проблемы. (В то время как компетентные системные администраторы оставляют активным только один метод синхронизации со временем, может случиться так, что они оба активны из-за ошибки конфигурации ).

П.С. systemd-timesyncdне следует рекомендовать в качестве альтернативы, если не используется systemd.

Объявление systemd -timesyncd в файле НОВОСТЕЙ systemd хорошо объясняет отличия этого инструмента от Chrony и ему подобных. (упор шахтный):

A new "systemd-timesyncd" daemon has been added for synchronizing the system clock across the network. It implements an SNTP client. In contrast to NTP implementations such as chrony or the NTP reference server this only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it. Unless you intend to serve NTP to networked clients or want to connect to local hardware clocks this simple NTP client should be more than appropriate for most installations. [...]

Эта настройка является распространенным вариантом использования для большинства хостов в парке серверов. Обычно они синхронизируются с локальными серверами NTP, которые сами синхронизируются из нескольких источников, возможно, включая оборудование. systemd -timesyncd пытается предоставить простое ---решение для этого общего случая использования.

Попытка ответить на ваши конкретные вопросы:

What are the real world differences between the two in terms of accuracy?

Я считаю, что вы можете добиться большей точности, получая данные синхронизации из нескольких источников, что, в частности, не поддерживается для systemd -timesyncd. Но когда вы используете его для получения данных синхронизации с центральных NTP-серверов, подключенных к вашей надежной внутренней сети, использование нескольких источников на самом деле не так важно, и вы получаете хорошую точность из одного источника.

Если вы синхронизируете свой сервер с доверенным сервером в локальной сети и в том же центре обработки данных , разница в точности между NTP и SNTP -будет практически нулевой. NTP может учитывать RTT и проводить анализ времени, но это не так выгодно, когда ваш RTT действительно мал, как в случае с быстрой локальной сетью и соседним компьютером. Вам также не нужны несколько источников, если вы можете доверять тому, который используете.

What are the differences in efficiency?

Синхронизация из одного источника намного проще, чем из нескольких, поскольку вам не нужно принимать решения о том, какие источники лучше других, и, возможно, объединять информацию из нескольких источников. Алгоритмы намного проще и в простом случае потребуют меньше нагрузки на ЦП.

What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?

Об этом говорится в приведенной выше цитате.но в любом случае это варианты использования Chrony, которые не охватываются systemd -timesyncd:

• запуск NTP-сервера (, чтобы другие хосты могли использовать этот хост в качестве источника для синхронизации );
• получение информации о синхронизации NTP из нескольких источников (, что важно для хостов, получающих эту информацию с общедоступных серверов в Интернете ); и
• получение информации о синхронизации от местных часов, для чего обычно используется специализированное оборудование, такое как устройства GPS, которые могут получать точную информацию о времени со спутников.

Для этих вариантов использования требуется Chrony или ntpd или что-то подобное.

chronyне является форком ntpd, а реализован с нуля. Он реализует режимы клиента и сервера полного протокола NTPv4(RFC5905). У пользователей корпоративного уровня мы наблюдаем тенденцию переключения с традиционного ntpdна chrony, например Red Hat (RHEL 7 и далее )и SuSE (с SLES 15 ).

systemd-timesyncdреализует только протокол SNTP(RFC4330)режим клиента . Следовательно, сложные варианты использования не охватываются systemd-timesyncd. Например,SNTP не может сделать его более точным, получая время из нескольких источников, как это делает NTP по умолчанию. В результате systemd-timesyncdне может обеспечить такое же точное время, как chrony.