ntpd vs. systemd-timesyncd - Як досягти надійної синхронізації NTP?

Коли я запитую статус демона NTP за допомогою, ntpdc -c sysinfoя отримую такий вихід:

system peer:          0.0.0.0
system peer mode:     unspec
leap indicator:       11
stratum:              16
precision:            -20
root distance:        0.00000 s
root dispersion:      12.77106 s
reference ID:         [73.78.73.84]
reference time:       00000000.00000000  Thu, Feb  7 2036  7:28:16.000
system flags:         auth monitor ntp kernel stats
jitter:               0.000000 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s

Це вказує на те, що синхронізація NTP не вдалася. Однак системний час є точним в межах 1 секунди точності. Коли я запускав свою систему без підключення до мережі за той самий період, що я робив зараз, час системи відхилиться ~ 10 с.

Така поведінка говорить про те, що система має інший спосіб синхронізації часу. Я зрозумів, що існує також systemd-timesyncd.service(з файлом конфігурації в /etc/systemd/timesyncd.conf) і timedatectl statusдає мені правильний час:

      Local time: Thu 2016-08-25 10:55:23 CEST
  Universal time: Thu 2016-08-25 08:55:23 UTC
        RTC time: Thu 2016-08-25 08:55:22
       Time zone: Europe/Berlin (CEST, +0200)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2016-03-27 01:59:59 CET
                  Sun 2016-03-27 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2016-10-30 02:59:59 CEST
                  Sun 2016-10-30 02:00:00 CET

Тож моє запитання полягає в тому, яка різниця між двома механізмами? Чи одна із них застаріла? Чи можна їх використовувати паралельно? Кому слід довіряти, коли я хочу запитувати статус синхронізації NTP?

(Зверніть увагу, що у мене інша система (в іншій мережі), для якої обидва методи вказують на успіх і приносять правильний час.)

ntp ntpd

— a_guest
джерело

Я виявив, що Fedora насправді використовує chrony : Налаштування NTP за допомогою chrony Suite

— David Tonhofer

Відповіді:

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

Не слід використовувати обидві паралельно, оскільки теоретично вони можуть вибирати різні часові сервери, які мають невелику затримку між ними, що призводить до того, що ваш системний годинник періодично "стрибає".

Щоб отримати статус, вам, на жаль, потрібно скористатися, ntpdcякщо ви використовуєте ntpd, а timedatectlякщо ви використовуєте timesyncd, я не знаю жодної утиліти, яка могла б прочитати обидва.

— maxf
джерело

Як же тоді можливо, що в одній системі синхронізація ntpd виявляється невдалою, а на іншій - успішною (обидва запущені systemd-timesyncd паралельно). Я впевнений, що це не стосується проблеми з брандмауером, оскільки я перевірив відповідні налаштування. Зараз у мене залишаються два результати, і я спокушаюся довіряти успішному, проте я маю сумніви, оскільки обидва клієнти реалізують той же протокол NTP, але один не працює. Насправді я б очікував, що вони працюватимуть.

— a_guest

ntpd і timesyncd використовують різні налаштування. Ви встановили однаковий тимчасовий сервер для обох?

— maxf

чи можете ви використовувати timesyncd для синхронізації часу з GPS, як, наприклад, з ntp?

— bakalolo

Systemd-timesyncd - це клієнт SNTP, який менш точний, ніж NTP. Читачів не слід вводити в оману, щоб думати systemd-timesyncd - це невелика вага клієнта NTP.

— Філіп Кулінг

systemd-timesyncd не має дисципліни годинника: годинник не навчається і не компенсується, а внутрішній переміщення годин з часом не зменшується. Він має рудиментарну логіку для регулювання інтервалу опитування, але без дисципліни хост закінчується нерівномірним часом назавжди, оскільки systemd-timesyncd натискає або тягне на будь-який інтервал, на який він вважає, що потребує короткочасного дрейфу. Він також не може оцінити якість віддаленого джерела часу. Ви навряд чи отримаєте точність набагато більше 100 мс. Цього достатньо для простих пристроїв кінцевих користувачів, таких як ноутбуки, але це безумовно може спричинити проблеми для розподілених систем, які хочуть більшої точності в часі.

— Метаксис
джерело