Nuestro team de redactores ha estado largas horas investigando soluciones a tu duda, te dejamos la solución por eso nuestro deseo es serte de gran ayuda.
Solución:
El anuncio de systemd-timesyncd en el archivo de NEWS systemd hace un buen trabajo al explicar las diferencias de esta herramienta en comparación con Chrony y herramientas similares. (énfasis mío):
Un nuevo “systemd-timesyncd” Se ha agregado un demonio para sincronizar el reloj del sistema en la red. Implementa un Cliente SNTP. A diferencia de las implementaciones de NTP como cronicidad o el servidor de referencia NTP, esto solo implementa un lado del cliente y no se molesta con la complejidad completa de NTP, centrándose solo en consultar la hora desde un servidor remoto y sincronizar el reloj local con él. A menos que tenga la intención de servir NTP a clientes en red o desee conectarse a relojes de hardware locales, este simple cliente NTP debería ser más que apropiado para la mayoría de las instalaciones. […]
Esta configuración es un caso de uso común para la mayoría de los hosts en una flota de servidores. Por lo general, se sincronizarán desde servidores NTP locales, que a su vez se sincronizan desde múltiples fuentes, posiblemente incluido el hardware. systemd-timesyncd intenta proporcionar una solución fácil de usar para ese caso de uso común.
Tratando de abordar sus preguntas específicas:
¿Cuáles son las diferencias del mundo real entre los dos en términos de precisión?
Creo que puede obtener una mayor precisión al obtener datos de sincronización de múltiples fuentes, lo que específicamente no es un caso de uso compatible para systemd-timesyncd. Pero cuando lo usa para obtener datos de sincronización de servidores NTP centrales conectados a su red interna confiable, el uso de múltiples fuentes no es realmente tan relevante y obtiene una buena precisión de una sola fuente.
Si está sincronizando su servidor desde un servidor confiable en una red local y en el mismo centro de datos, la diferencia de precisión entre NTP y SNTP será prácticamente inexistente. NTP puede tener en cuenta RTT y medir el tiempo, pero eso no es tan beneficioso cuando su RTT es realmente pequeño, como es el caso de una red local rápida y una máquina cercana. Tampoco necesita varias fuentes si puede confiar en la que está utilizando.
¿Cuáles son las diferencias de eficiencia?
Obtener la sincronización de una sola fuente es mucho más simple que obtenerla de múltiples fuentes, ya que no tiene que tomar decisiones sobre qué fuentes son mejores que otras y posiblemente combinar información de múltiples fuentes. Los algoritmos son mucho más simples y requerirán menos carga de CPU para el caso simple.
¿Cuáles son las necesidades de sincronización de tiempo “no simples”, también conocidas como casos de uso de chrony como cliente NTP?
Eso se aborda en la cita anterior, pero en cualquier caso, estos son casos de uso para Chrony que no están cubiertos por systemd-timesyncd:
- ejecutar el servidor NTP (para que otros hosts puedan utilizar este host como fuente de sincronización);
- obtener información de sincronización NTP de múltiples fuentes (lo cual es importante para que los hosts obtengan esa información de servidores públicos en Internet); y
- obtener información de sincronización del reloj local, que generalmente implica hardware especializado, como dispositivos GPS, que pueden obtener información precisa de la hora de los satélites.
Estos casos de uso requieren Chrony o ntpd o similar.
Como dice correctamente la otra respuesta, chrony implementa NTP y systemd-timesyncd SNTP.
Desde el punto de vista de un cliente de servicio horario:
SNTP es un protocolo mucho más sencillo de implementar;
NTP permite incrementos / correcciones paso a paso a tiempo. Una gran ventaja de NTP es que también tiene en cuenta el RTT de la respuesta para obtener una hora más exacta.
De https://www.meinbergglobal.com/english/faq/faq_37.htm
Si bien un servidor o cliente NTP con todas las funciones alcanza un nivel muy alto de precisión y evita los pasos de tiempo abruptos tanto como sea posible mediante el uso de diferentes métodos matemáticos y estadísticos y ajustes suaves de la velocidad del reloj, SNTP solo se puede recomendar para aplicaciones simples, donde los requisitos de la precisión y la fiabilidad no son demasiado exigentes. Al ignorar los valores de deriva y utilizar formas simplificadas de métodos de ajuste del reloj del sistema (a menudo, pasos de tiempo simples), SNTP solo logra una sincronización de tiempo de baja calidad en comparación con una implementación de NTP completa.
SNTP adopta un enfoque mucho más simple. Se eliminan muchas de las complejidades del algoritmo NTP. En lugar de sesgar el tiempo, muchos clientes SNTP pasan el tiempo. Esto está bien para muchas aplicaciones donde se requiere un sello de tiempo simple. Además, SNTP carece de la capacidad de monitorear y filtrar múltiples servidores NTP. A menudo se usa un enfoque simple de operación por turnos, donde si un servidor falla, se usa el siguiente en una lista
De https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp
NTP es mucho más exacto y preciso que SNTP, y esto lo convierte en el ganador de facto en la mayoría de las aplicaciones empresariales. Por otro lado, la simplicidad de SNTP lo hace más apropiado para cosas como cámaras IP, DVR y algunos conmutadores de red. Estos tipos de hardware carecen de los recursos de procesamiento para manejar protocolos más complejos, pero a medida que los dispositivos conectados se vuelven cada vez más poderosos, eso puede cambiar.
Uno de los principales puntos débiles de SNTP es que no puede hacerlo más preciso recuperando el tiempo de varias fuentes, como lo hace Network Time Protocol de forma predeterminada.
Otro punto importante que puedo ver que las implementaciones SNTP dan más problemas que NTP es en la virtualización, cuando el hipervisor y el demonio NTP intentan cambiar la hora de la máquina virtual. Especialmente si no se ponen de acuerdo a tiempo con alguna mala configuración que hace que ambos estén activos, podría causar grandes problemas. (Si bien los administradores de sistemas competentes solo mantendrán activo un método para la sincronización con el tiempo, puede suceder que ambos estén activos por un error de configuración).
PD systemd-timesyncd no debe ser una alternativa recomendada cuando no se usa systemd.
chrony no es una forma de bifurcación ntpd pero se implementa desde cero. Implementa tanto cliente y servidor modos de protocolo NTPv4 completo (RFC5905). En los usuarios de nivel empresarial, estamos viendo una tendencia que cambia de los ntpd para chrony como Red Hat (RHEL 7 en adelante) y SuSE (desde SLES 15).
systemd-timesyncd solo implementar el protocolo SNTP (RFC4330) cliente modo. Por lo tanto, los casos de uso complejos no están cubiertos por systemd-timesyncd. Por ejemplo, SNTP no puede hacerlo más preciso recuperando la hora de varias fuentes como lo hace NTP de forma predeterminada. Como resultado systemd-timesyncd no puede proporcionar un tiempo de precisión tan alto como chrony.
Agradecemos que desees corroborar nuestra tarea escribiendo un comentario o dejando una puntuación te damos la bienvenida.