¿Cómo personalizo la tasa de sondeo NTP?

Estoy configurando Ubuntu en una máquina integrada que se ejecuta a través de una conexión celular, donde pagamos por byte. La máquina tampoco tiene batería RTC, por lo que se inicia desde un momento aleatorio en cada arranque.

Me gustaría asegurarme de que el tiempo se sincronice cuando la conexión celular esté disponible para que los mensajes de registro, etc. tengan tiempos reales, pero tampoco quiero pagar un brazo y una pierna por el tráfico NTP.

¿Puedo personalizar la velocidad a la que NTP actualiza la hora? Actualmente estoy usando openntpd, pero no estoy casado con él.

Internet no está necesariamente activo durante el arranque, por lo que ntupdate y relacionados al inicio no funcionarán. Y programar a través de cron significa esperar a que se inicie la tarea programada, mientras que quiero que un demonio de tiempo obtenga una sincronización de tiempo lo antes posible.

Algunas de estas respuestas podrían ganar el concurso de configuración ntp ofuscado.

Use la implementación de referencia ntp y use iburst para establecer el tiempo rápidamente al arrancar. Después de eso, puede usar la directiva minpoll para limitar la frecuencia con la que ntpd consulta servidores de hora remotos. Esto le permitirá aprovechar la disciplina del reloj de ntpd y reducir el ancho de banda.

minpoll minpoll
maxpoll maxpoll
    These options specify the minimum and maximum poll intervals for NTP 
    messages, in seconds as a power of two. The maximum poll interval 
    defaults to 10 (1024 s), but can be increased by the maxpoll option to 
    an upper limit of 17 (36 h). The minimum poll interval defaults to 6 (64 s), 
    but can be decreased by the minpoll option to a lower limit of 3 (8 s).

Chrony es una buena alternativa a la implementación de referencia ntp. Openntpd no lo es.

Mi experiencia es con ntp en lugar de openntpd.

Debe saber que el protocolo NTP generalmente comienza con el envío de paquetes cada minuto (64 segundos), pero generalmente se instala enviando y recibiendo un paquete cada 17 minutos por cada servidor que tenga en su archivo /etc/ntp.conf. Sin embargo, los cortes de red o un reloj inestable en su dispositivo pueden aumentar esto. Cada paquete tiene una carga útil de aproximadamente 68 bytes, por lo que probablemente sea un poco más de 100 bytes, por trayecto, por encuesta.

El rdate y el ntpdate en el tiempo de funcionamiento de la red son buenas ideas para configurar el tiempo. Y si eso es todo lo que necesita, debería funcionar bien para usted.

Sin embargo, si necesita mantener el tiempo sincronizado durante un tiempo prolongado, el protocolo ntp fue diseñado para hacerlo. El reloj en su dispositivo funcionará un poco más rápido o más lento dependiendo de qué tan cálido o frío se ponga, aunque probablemente tenga un reloj controlado por cristal, y el cronometraje continuo está destinado a ajustarse a eso.

Aquí hay algunas sugerencias si necesita un cronometraje continuo y desea reducir el ancho de banda utilizado. Se refieren a elementos en ntp.conf.

No uses iburst. (Pero llevará más tiempo establecer la hora inicialmente).

Aumenta el minpoll hacia arriba de 6 (2 ^ 6 segundos es 64 segundos). Esto reduce el tráfico cuando el protocolo se inicia después de que aparece la red.

Aumente maxpoll hacia arriba de 10 (2 ^ 10 segundos es 1024 segundos o aproximadamente cada 17 minutos. Puede llegar hasta 17 para sondear cada 36 horas. No lo he intentado yo mismo.

Utilice solo un número mínimo de servidores, si tuviera uno al que se pueda acceder de manera confiable desde sus dispositivos integrados, eso hubiera sido excelente. Cuantos más servidores, más confiable puede ser el cronometraje, pero el tráfico aumenta, por lo que es una compensación.

Podría hacer algún hacker que implique ejecutar ntpdate cuando aparezca la interfaz de la celda. Pero si puede, instalar chrony sería una mejor alternativa, ya que se creó teniendo en cuenta el acceso intermitente a la red .

En una instalación predeterminada de Ubuntu, el demonio NTP no se ejecuta. En cambio, el tiempo se establece cada vez que el /etc/network/if-up.d/ntpdategancho abre una interfaz de red .

Si busca una sincronización horaria única en lugar de una sincronización constante, entonces esto podría ser suficiente para usted.

Puede controlar qué servidores se consultan para establecer la hora a través del /etc/ntp.confarchivo estándar o la NTPSERVERSvariable en /etc/default/ntpdate.

¿Necesita la sincronización exacta y precisa que proporciona ntp? De lo contrario, es posible que pueda salirse con la suya usando rdateo ntpdateen el arranque y luego periódicamente a través de cron.

Probablemente ya haya leído la página de manual de openntpd.

http://www.openbsd.org/cgi-bin/man.cgi?query=ntpd.conf

Probablemente ya haya notado la falta de una opción de votación por tiempo.

Tengo estos posibles hacks para proponer:

1. No use ningún ntpd, solo llame a ntpdate a través de cron.

2. Use cron y / o sus scripts de conexión celular para alternar las reglas de iptables para descartar o permitir el tráfico del puerto 123 cuando lo desee. Esto podría ser tan simple como

   0 12 * * * iptables -D OUTPUT -j DROP -p udp --dport 123 # at noon start allowing ntp

   0 13 * * * iptables -A OUTPUT -j DROP -p udp --dport 123 # at 1pm stop allowing ntp

3. Incruste un receptor de radio reloj en su máquina integrada. No sé casi nada de esto, pero productos como este:

   • http://www.galsys.co.uk/time-receivers/ac-500-msf-time-receiver.html y esto

   • http://www.giangrandi.ch/electronics/dcf77/dcf77.shtml y las personas que hablan así

   • http://www.blu.org/cgi-bin/calendar/2010-oct

hazme pensar que no es difícil si puedes recibir la señal de radio.

Si no recuerdo mal, el intervalo de encuesta ntp se puede establecer en un máximo de 1024 segundos. Quizás la solución más simple sería ejecutar ntpdate en cada arranque y luego de vez en cuando desde crontab.

Si su reloj comienza con un tiempo aleatorio en cada arranque, entonces probablemente no podrá ejecutar ntpd de todos modos y tendrá que usar ntpdate primero. Ntpd se niega a sincronizar la hora si la diferencia es demasiado grande entre su reloj y el reloj de los servidores.

NTP, como TCP, tiene algo de teoría profunda y experiencia práctica integrada en el protocolo; Si modifica sus parámetros fundamentales, deja de tener las propiedades de sincronización para las que fue diseñado.

Si su dispositivo está conectado esporádicamente, quizás el buen RDATE antiguo le sirva mejor. No maneja la rotación del reloj, ni el promedio de pares, ni puede protegerse contra varios hacks sutiles que un hombre en el medio podría jugar si valiera la pena. Simplemente obtiene una fecha de referencia de un servidor remoto y golpea el reloj local con un martillo. Pero, lo hace cuando lo desea, y su comportamiento es determinista.

La precisión de RDATE es mucho peor de lo que permite NTP, no confiaría en ella por más de ± 1 segundo, pero si solo está conectado esporádicamente, un momento más preciso no es relevante; de hecho, según la relatividad , puede que ni siquiera tenga sentido.

Para que el minpool/ maxpoolsea ​​tenido en cuenta, debe agregarlo por servidor en su ntp.conf.

No es muy recomendable meterse con el demonio NTP (tiene un método incorporado para optimizar la frecuencia), pero deberá agregar estas opciones de esta manera:

server time.google.com iburst minpoll 12 maxppol 17
server ntp.ubuntu.com iburst minpoll 12 maxppol 17
server europe.pool.ntp.org iburst minpoll 12 maxppol 17

Aquí, si establece la frecuencia mínima en 2 ^ 12 segundos, y la máxima en 2 ^ 17 segundos.

Por defecto, descubrí que el NTP haría una solicitud cada minuto más o menos. Eso es demasiado Aquí reduje la frecuencia de una vez por hora a una vez al día (bruscamente).