Me doy cuenta de que, dado que Raspberry Pi no tiene un reloj de hardware en tiempo real incorporado, pueden presentarse algunos problemas con el cronometraje preciso, incluso cuando la persistencia entre reinicios no es un requisito .
Esto puede mitigarse en gran medida ejecutando un demonio NTP que corrige continuamente la hora local, pero NTP no es una opción si Raspberry Pi no está conectado a una red.
Entonces, si dejo una Raspberry Pi encendida con una hora precisa al principio, ¿cuánto debería esperar que la hora informada se desvíe de la hora local real?
¿Y qué hay entre reinicios?
raspbian
timekeeping
system-clock
SDsolar
fuente
fuente
Respuestas:
Realmente hay dos problemas:
1) La precisión del oscilador en sí mismo, que tiene variables tales como singularidad, edad, temperatura, etc.
2) Si hay algo que pueda causar errores de cronometraje en relación con el oscilador de cristal. Eso sería cosas como interrupciones perdidas o problemas de transición si el reloj utilizado es posterior a un multiplicador PLL, o afectado por la aceleración del reloj (si se utiliza).
Por cierto, el NTP, a menos que esté muy bien implementado, puede empeorar el tiempo auto-relativo preciso a corto plazo, ya que significa que el reloj local se puede cambiar para que sea coherente con una autoridad externa, en lugar de permanecer coherente consigo mismo.
fuente
Dependerá del cristal que usaron, tal vez 10 ppm aproximadamente. Realmente no puedes contar con él a menos que se especifique en algún lugar. Es posible que pueda usar el GPS si no está conectado a una red. De lo contrario, se puede agregar un chip RTC.
Necesitará algo mejor que solo tiempo de software si existe la posibilidad de que el RPi pueda perder potencia o bloquearse.
Espero conectar un RTC al GPIO en algún momento pronto
fuente
Interpretando la pregunta que se debe hacer sobre un Raspberry Pi con Raspbian.
El sistema operativo es la influencia dominante en cómo Rapberry Pi mantiene el tiempo.
Respuesta: Sin una fuente externa, el reloj interno es altamente impredecible en términos de mantener el tiempo por sí mismo.
Estudios de casos recientes:
Esta es una trama de un registrador de datos Raspberry Pi 3 B que de repente perdió energía de la red pública durante aproximadamente una hora:
Puede ver claramente que cuando se volvió a encender, se inició y reinició el registro de datos.
Pero el reloj Raspbian retrocede en el tiempo.
Luego puede verlo avanzar a la hora correcta tan pronto como reciba una actualización de time.nist.gov
¿Cómo configuro Raspbian para usar el servidor horario primario time.nist.gov?
Aquí hay una nueva trama del mismo sistema nuevamente.
Desde que se interrumpió ayer (vea el diagrama anterior), solía
sudo init 0apagarlo correctamente para crear una imagen de la tarjeta SD con Win32DiskImager en una PC.Lleva un tiempo, como se puede ver aquí.
En este se puede ver que Raspbian inicialmente reinició su reloj justo donde lo dejó. Parece que había registrado buenos datos (saltos) en un minuto.
Luego muestra lo que sucede cuando recibe la actualización de tiempo. Salta hacia la derecha.
La cantidad que salta hacia adelante (un par de horas) es el tiempo que Raspbian perdió durante la captura de la tarjeta SD.
Aquí hay un giro sorprendente.
El sistema simplemente se congeló. Luces rojas y verdes encendidas, sin parpadeos.
Anunciado (usando
espeak) en cuestión de minutos por el trabajo cron basado en ping del servidor principal que monitorea los registradores de datos para tal ocurrencia. Así que no fue más de unos minutos.Potencia extraída por unos segundos. Lo reinicié: los LED parecen normales.
Así es como esta falla afectó el registro de datos:
El reloj Raspbian se adelantó 2 horas cuando se reinició el sistema.
Luego, la actualización de tiempo de time.nist.gov lo retrasa.
Respuesta: Sin una fuente externa, el reloj interno es impredecible en términos de mantener el tiempo real por sí solo.
¿Cómo configuro Raspbian para usar el servidor horario primario time.nist.gov?
fuente