ntpd vs. systemd-timesyncd: ¿cómo lograr una sincronización NTP confiable?

Cuando consulto el estado del demonio NTP con ntpdc -c sysinfo, obtengo el siguiente resultado:

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

Esto indica que la sincronización NTP falló. Sin embargo, el tiempo del sistema es preciso con una precisión de 1 segundo. Cuando ejecuté mi sistema sin conexión de red durante el mismo período que lo hice ahora, la hora del sistema se desviaría ~ 10 segundos.

Este comportamiento sugiere que el sistema tiene otra forma de sincronizar la hora. Me di cuenta de que también existe systemd-timesyncd.service(con el archivo de configuración en /etc/systemd/timesyncd.conf) y timedatectl statusme da la hora correcta:

      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

Entonces mi pregunta es ¿cuál es la diferencia entre los dos mecanismos? ¿Uno de ellos está en desuso? ¿Se pueden usar en paralelo? ¿En cuál debo confiar cuando quiero consultar el estado de sincronización NTP?

(Tenga en cuenta que tengo un sistema diferente (en una red diferente) para el que ambos métodos indican éxito y producen el tiempo correcto).

ntp ntpd un invitado
fuente

He descubierto que Fedora en realidad usa chrony : Configuración de NTP usando la suite

chrony

Respuestas:

systemd-timesyncd es básicamente una pequeña implementación NTP solo para clientes, más o menos incluida con las nuevas versiones de systemd. Es más liviano que un ntpd completo, pero solo admite sincronización de tiempo, es decir, no puede actuar como un servidor NTP para otras máquinas. Está destinado a reemplazar ntpd para clientes.

No debe usar ambos en paralelo, ya que en teoría podrían elegir diferentes servidores de tiempo que tienen un ligero retraso entre ellos, lo que hace que el reloj de su sistema esté periódicamente "nervioso".

Para obtener el estado, desafortunadamente necesita usarlo ntpdcsi usa ntpd y timedatectlsi usa timesyncd, no conozco ninguna utilidad que pueda leer ambos.

maxf
fuente

¿Cómo es posible que en un sistema la sincronización de ntpd falle mientras que en el otro sea exitosa (ambos ejecutan systemd-timesyncd en paralelo)? Estoy bastante seguro de que esto no se relaciona con un problema de firewall ya que he verificado la configuración correspondiente. En este momento me quedan dos resultados y estoy tentado a confiar en el exitoso, sin embargo, tengo dudas ya que ambos clientes implementan el mismo protocolo NTP pero uno falla. En realidad, esperaría que ambos trabajen.

a_guest

ntpd y timesyncd usan diferentes configuraciones. ¿Estableciste el mismo servidor de tiempo para ambos?

maxf

¿puedes usar timesyncd para sincronizar la hora con un GPS como con ntp?

bakalolo

Systemd-timesyncd es un cliente SNTP que es menos preciso que NTP. Los lectores no deben ser engañados al pensar que systemd-timesyncd es un cliente NTP ligero.

Philip Couling

systemd-timesyncd no disciplina el reloj: el reloj no está entrenado o compensado, y la deriva del reloj interno con el tiempo no se reduce. Tiene una lógica rudimentaria para ajustar el intervalo de sondeo, pero sin disciplinar al host terminará con un tiempo desigual para siempre, ya que systemd-timesyncd empuja o tira en cualquier intervalo que considere que requiere la deriva a corto plazo. Tampoco puede evaluar la calidad de la fuente de tiempo remota. Es poco probable que obtenga una precisión mucho mayor de 100 ms. Esto es suficiente para dispositivos de usuario final simples como computadoras portátiles, pero definitivamente podría causar problemas para los sistemas distribuidos que desean una mayor precisión de tiempo.

Metaxis
fuente