ntpd vs. systemd-timesyncd - Jak uzyskać niezawodną synchronizację NTP?

Gdy pytam o status demona NTP za pomocą ntpdc -c sysinfo, otrzymuję następujące dane wyjściowe:

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

Oznacza to, że synchronizacja NTP nie powiodła się. Jednak czas systemowy jest dokładny z dokładnością do 1 sekundy. Gdy uruchomiłem mój system bez połączenia sieciowego przez ten sam okres, co teraz, czas w systemie może się różnić od 10 do 10 sekund.

To zachowanie sugeruje, że system ma inny sposób synchronizacji czasu. Uświadomiłem sobie, że istnieje też systemd-timesyncd.service(z plikiem konfiguracyjnym w /etc/systemd/timesyncd.conf) i timedatectl statuspodałem prawidłowy czas:

      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

Więc moje pytanie brzmi, jaka jest różnica między tymi dwoma mechanizmami? Czy jeden z nich jest przestarzały? Czy można ich używać równolegle? Któremu zaufać, jeśli chcę sprawdzić status synchronizacji NTP?

(Zauważ, że mam inny system (w innej sieci), dla którego obie metody wskazują sukces i dają właściwy czas.)

ntp ntpd

— gość
źródło

Odkryłem, że Fedora faktycznie używa chrony : Konfigurowanie NTP przy użyciu chrony Suite

— David Tonhofer

Odpowiedzi:

systemd-timesyncd to w zasadzie niewielka implementacja NTP tylko dla klienta, mniej więcej w pakiecie z nowszymi wydaniami systemowymi. Jest bardziej lekki niż pełna ntpd, ale obsługuje tylko synchronizację czasu - tzn. Nie może działać jako serwer NTP dla innych komputerów. Jest przeznaczony do zastąpienia ntpd dla klientów.

Nie należy używać obu równolegle, ponieważ teoretycznie mogą wybierać różne serwery czasu, które mają między nimi niewielkie opóźnienie, co powoduje, że zegar systemowy jest okresowo „przeskakiwany”.

Aby uzyskać status, niestety musisz użyć, ntpdcjeśli używasz ntpd i timedatectljeśli używasz timesyncd, nie znam żadnego narzędzia, które mogłoby odczytać oba.

— maks
źródło

Jak to możliwe, że w jednym systemie synchronizacja ntpd kończy się niepowodzeniem, podczas gdy w drugim udaje się (oba równolegle uruchamiają systemd-timesyncd). Jestem pewien, że to nie dotyczy problemu zapory, ponieważ sprawdziłem odpowiednie ustawienia. W tej chwili mam dwa wyniki i kusi mnie, aby zaufać temu udanemu, jednak mam wątpliwości, ponieważ obaj klienci wdrażają ten sam protokół NTP, ale jeden zawodzi. Właściwie spodziewałbym się, że oba będą działać.

— a_guest

ntpd i timesyncd używają różnych ustawień. Czy ustawiłeś ten sam serwer czasu dla obu?

— maxf

czy możesz użyć timesyncd do synchronizacji czasu z GPS, jak w przypadku NTTP?

— bakalolo

Systemd-timesyncd to klient SNTP, który jest mniej dokładny niż NTP. Czytelników nie należy wprowadzać w błąd, myśląc, że systemd-timesyncd to lekki klient NTP.

— Philip Couling

systemd-timesyncd nie dyscyplinuje zegara: zegar nie jest trenowany ani kompensowany, a dryf zegara wewnętrznego w czasie nie ulega zmniejszeniu. Ma podstawową logikę, aby dostosować interwał odpytywania, ale bez dyscypliny gospodarz skończy z nierównomiernym czasem na zawsze, gdy systemd-timesyncd popycha lub ściąga w dowolnym interwale, jaki według niego wymaga krótkotrwałego dryfu. Nie może również ocenić jakości zdalnego źródła czasu. Jest mało prawdopodobne, aby uzyskać dokładność znacznie większą niż 100 ms. Jest to wystarczające w przypadku prostych urządzeń użytkowników końcowych, takich jak laptopy, ale może zdecydowanie powodować problemy w systemach rozproszonych, które wymagają większej precyzji czasu.

— Metaksja
źródło