¿El Raspberry Pi más estable? Precisión NTP mejorada en 81% con gestión térmica

• Presentación de los resultados de un experimento que combina fijación de núcleos de CPU y estabilización térmica para reducir la variación de frecuencia en un servidor NTP basado en Raspberry Pi
• Se observó que los cambios de temperatura de la CPU provocan deriva de frecuencia en el oscilador de cristal, y se logró estabilizarlo manteniéndolo a una temperatura constante
• Con un proceso “time burner” basado en control PID que mantiene la CPU a 54°C, se consiguió una reducción del 81% en la variación de frecuencia y del 77% en la desviación estándar
• Al reservar la CPU 0 exclusivamente para chronyd y mantener la carga térmica en los demás núcleos, se mejoró el offset NTP hasta un promedio de 38 ns
• Se plantea la posibilidad de implementar un servidor de temporización de alta precisión y bajo costo para entornos que requieren exactitud extrema, como sincronización horaria precisa o instrumentación científica

---

Problema: inestabilidad de temporización causada por cambios de temperatura

• La función de ajuste dinámico de frecuencia (DVFS) del Raspberry Pi es útil para la eficiencia energética, pero perjudica la sincronización horaria de precisión
  • Si la frecuencia del reloj cambia según la carga de CPU, también varía la velocidad de los ticks del reloj del sistema
• La frecuencia del oscilador de cristal es sensible a la temperatura y puede variar varios ppm según el calor generado por la CPU
  • Se produce deriva de frecuencia según los cambios de temperatura entre el día y la noche
• Según el monitoreo en Grafana, se observó un offset de frecuencia de aproximadamente ±1 ppm según los cambios de temperatura de la CPU
  • El promedio del offset RMS estaba en torno a 86 ns, por lo que había margen de mejora

Hallazgo: efecto de mantener una temperatura constante

• Se confirmó que mantener estable la temperatura de la CPU puede mejorar la estabilidad de frecuencia
• La solución se compone de dos partes
  1. Aislamiento de núcleos de CPU – asignar chronyd y las interrupciones PPS solo a la CPU 0
  2. Estabilización térmica – mantener activos continuamente los demás núcleos para sostener una temperatura constante
• Al activar el sistema de estabilización térmica el 17 de noviembre de 2025 a las 09:10, la oscilación de frecuencia disminuyó de inmediato

Solución 1: fijación de núcleos de CPU y prioridad en tiempo real

• CPU 0: dedicada exclusivamente a chronyd y a las interrupciones PPS
• CPU 1–3: tareas generales y mantenimiento de la carga térmica
• Se configuró un script de optimización que se ejecuta automáticamente al arrancar
  • Fija el modo de control de frecuencia de CPU en performance
  • Fija la PPS IRQ(200) a la CPU 0
  • Configura chronyd con prioridad en tiempo real (SCHED_FIFO 50)
  • Mejora la prioridad del proceso ksoftirqd/0
• El script puede registrarse en /etc/rc.local o como servicio de systemd

Solución 2: estabilización térmica basada en control PID

• Se usa un bucle de control PID para mantener constante la temperatura de la CPU
  • Temperatura objetivo: 54°C
  • Tres procesos worker en las CPU 1–3 generan carga mediante cálculos de hash MD5
  • Según el valor de salida del PID, se ajustan el tiempo de cómputo y el tiempo de espera
• Parámetros PID
  • Kp=0.05, Ki=0.02, Kd=0.0
  • Como el cambio de temperatura es lento, el término derivativo (Kd) es 0
• Como resultado, la temperatura de la CPU se mantuvo estable dentro de un rango de ±0.2°C

Resultados: mejora en la estabilidad de frecuencia

• 81% menos variación de frecuencia, 77% menos desviación estándar y 49% menos offset RMS
• Offset RMS promedio: 85.44 ns → 43.54 ns
• Offset RMS mediano: 80.13 ns → 37.93 ns
• Manteniendo la CPU a 54°C, se logró una estabilidad de frecuencia dentro de un rango de ±0.14 ppm
• La estabilidad se mantuvo pese a variaciones de temperatura ambiente en interiores (18.9~22.2°C)

Procedimiento de configuración

• Preparación previa: es necesario construir un servidor NTP basado en GPS PPS
• Instalación de paquetes obligatorios
  • linux-cpupower, python3, util-linux
• Crear el script de optimización de arranque /usr/local/bin/pps-optimize.sh y registrarlo en systemd
• Crear el script de control térmico /usr/local/bin/time_burner.py y registrar el servicio
  • ExecStart=/usr/bin/python3 /usr/local/bin/time_burner.py -t 54.0 -n 3
• Comandos de verificación
  • Confirmar que el governor de CPU esté en performance
  • Verificar la fijación de CPU y la prioridad de chronyd
  • Medir el offset RMS con chronyc tracking (por ejemplo, alrededor de 35 ns)

Monitoreo y solución de problemas

• Monitoreo en tiempo real: watch -n 1 "chronyc tracking"
• Verificar estado del servicio: sudo systemctl status time-burner.service
• Ajuste del PID
  • Si la temperatura oscila, reducir Kp; si la estabilización tarda, aumentar Ki
  • La temperatura objetivo puede ajustarse dentro del rango de 50~60°C
• El alto uso de CPU (aprox. 90%) es un comportamiento intencional

Trade-offs

• Mayor consumo de energía: 3–4 W de consumo continuo (aprox. 15–25 kWh al año)
• Más generación de calor: se mantiene en 54°C, dentro de un rango seguro
• Uso de recursos de CPU: 3 de los 4 núcleos quedan ocupados
  • Adecuado para equipos dedicados a NTP, pero no para entornos con múltiples servicios

Posibles áreas de aplicación

• Sincronización horaria precisa, instrumentación científica, investigación en sistemas distribuidos, pruebas de red, etc.
• Es excesivo para uso general, pero útil para construir un entorno experimental de alta precisión y bajo costo

Próximas mejoras

• Ajuste PID adaptativo para responder a cambios estacionales de temperatura
• Control de enfriamiento basado en hardware (como ventiladores PWM) para mejorar la eficiencia energética
• Aplicar un OCXO (oscilador de cristal controlado por horno) podría eliminar la deriva térmica

Conclusión

• La combinación de fijación de núcleos de CPU y gestión térmica con control PID permite implementar un servidor NTP de ultraalta precisión
• Se logró una mejora del 81% en la estabilidad de frecuencia y un offset RMS de 38 ns
• El experimento demuestra la relación entre la gestión térmica y la planificación en tiempo real
• Es un proyecto orientado más a la exploración técnica y al aprendizaje que a la practicidad

[GN⁺]

Comentarios en Hacker News

• Si evitas CPU0 y configuras idle=poll en la línea de comandos del kernel, puedes obtener mejor precisión
  Como otras interrupciones se acumulan en CPU0, no es ideal para trabajos que requieren alta precisión de temporización
  • Pienso lo mismo. En nuestra distribución de SO basada en Debian también hacemos optimizaciones parecidas, como desactivar el escalado de frecuencia y fijar núcleos
    CPU0 tiene muchas tareas del sistema que no se pueden mover, así que es mucho mejor usar otro núcleo como una isla aislada (isolated core)
    La latencia del scheduler en nuestro núcleo aislado es muy estable: mínimo 1µs, promedio 5µs y máximo 59µs
  • Buen tip. Pienso probarlo yo mismo más tarde hoy
• En la estación transmisora WWVB aíslan el equipo con cientos de botellas de agua para evitar cambios de temperatura
  Artículo relacionado: Spare Time – JILA
  • Esa página vale la pena compartirla por sí sola. Es realmente impresionante que operen 4 relojes atómicos y que su UPS esté hecho de dos baterías de auto y dos faros
    La masa térmica hecha con botellas de agua también es interesante
  • Yo uso un método parecido. Guardo agua debajo del escritorio dentro de un cobertizo aislado para que no se congele durante la noche
    Es como poner una piedra caliente dentro de un saco de dormir
• Soy Austin (austinsnerdythings.com). Anoche publiqué el artículo, me fui a dormir y me sorprendió despertar y verlo en el puesto 1 de HN
  Mi LEA-M8T genera pulsos de tiempo a 16Hz, y en la configuración de chrony lo puse con dpoll=-4. Al recolectar 256 muestras en intervalos de 16 segundos, mejora la estabilidad
  También tengo un BH3SAP GPSDO al lado del escritorio. Claude modificó el firmware para agregar un modo flywheel que sigue generando pulsos incluso sin GPS PPS
  Además, lo actualizó para soportar salida TSIP (protocolo de Trimble). Planeo cubrir eso en una próxima publicación
  También responderé pronto a los comentarios; las preguntas siempre son bienvenidas
  • Gracias por el buen artículo. Yo también tengo una configuración parecida, así que me sirve bastante como referencia
    Me da curiosidad cuánto cambia realmente el pulso de 16Hz. Y también me gustaría saber cómo metes los datos en influxdb. Yo uso collectd, pero no hay mucha información
  • Buen proyecto. Me da curiosidad si pusiste la Raspberry Pi en una carcasa
    Incluso una carcasa metálica podría dar resultados más estables frente a cambios cíclicos de temperatura por calefacción o aire acondicionado
• Si reemplazas el cristal oscilador barato de la Pi por un TCXO, puedes obtener una frecuencia mucho más estable
  Documento relacionado: Raspberry Pi StackExchange – reemplazo del oscillator
  Solo con eso, la deriva se reduce entre 4 y 5 veces. Mejor aún si se combina con otras técnicas
  • He leído ese post varias veces. También venden un HAT audiófilo con OCXO para Pi4
    Pero no confío en mis habilidades de soldadura para hacer el reemplazo yo mismo
  • El precio de los TCXO es sorprendentemente bajo. Algunos productos de Abracon costaban menos de 2 dólares
• Esto es un OCXO a escala SBC. Me pregunto si ayudaría ponerle un disipador más grande o agregar masa térmica alrededor del oscilador
  Incluso al simplemente montar un servidor NTP, hay mucho por aprender
  • Recomiendo la carcasa metálica Flirc. El CPU queda en contacto estrecho con el cuerpo de la carcasa, formando una gran masa térmica
    Permite una excelente refrigeración pasiva sin ventilador
  • Yo pienso algo parecido. Poner un bloque metálico sobre el CPU y el oscilador para aumentar la inercia térmica podría ayudar
    Si la temperatura cambia lentamente, la deriva del reloj también cambia más despacio, así que es más fácil corregirla
    Pero un disipador pequeño podría, al contrario, volverlo más sensible a los cambios de temperatura ambiente
  • También estoy considerando agregar aislamiento a la carcasa de la Pi
    Podría amortiguar cambios bruscos de la temperatura del cuarto (abrir una ventana, humedad después de bañarse, etc.) y reducir que el CPU disipe calor innecesariamente
    Al final, el objetivo es mantener el calor lo más constante posible
  • Pero disipar demasiado calor podría resultar contraproducente
    Los otros núcleos ya operan cerca de la temperatura máxima y ajustan automáticamente la velocidad del reloj según la temperatura
    Un enfriamiento excesivo podría interferir con ese mecanismo interno de control térmico
• También se puede calentar directamente el cristal pegándole una resistencia y aislante de espuma
  Incluso podrías agregar un transistor controlable por GPIO para mantener la temperatura con control PID
  • Eso se usa desde hace casi 100 años. En la década de 1950, los hornos de cristal se mantenían a unos 75°C dentro de una pequeña caja metálica
    Eran estables porque usaban cristales cortados para que el coeficiente de temperatura fuera cercano a 0
    Los equipos modernos todavía usan esa estructura, y tardan unos 5 minutos en estabilizarse por completo
  • Yo también hice antes el experimento de poner la Pi sobre espuma de embalaje
    Redujo los cambios de temperatura ambiente, pero al final la solución más segura es meterla en una cámara de control térmico
• En vez de calentar el CPU a propósito para mantener la temperatura, creo que sería mejor usar un microcontrolador y un oscilador de precisión
  Por ejemplo, conectar Ethernet a una placa STM32 y usarla como servidor NTP probablemente sería más estable
  • Yo también tengo uno. Es un BH3SAP GPSDO que compré en eBay por 70 dólares, y con firmware modificado soporta modo flywheel
    Puede suministrar la señal NTP a la Pi, y también a un STM32, pero por defecto no tiene función Ethernet
  • En general, NTP es un proceso sensible al tiempo, así que un MCU es mucho más estable que un SoC
    RTLinux incluso tiene funciones para sincronizar el scheduler con el estado de pines externos
    Pero cuando aumenta la cantidad de procesadores, aparecen problemas de metastabilidad
    La Pi no ofrece garantías en tiempo real como una FPGA (Zynq)
• No se me había ocurrido la idea de aplicar carga intencionalmente para mantener constante la temperatura del SoC
  Pero como el consumo de energía es bajo, parece razonable resolverlo desperdiciando un poco de energía en vez de usar un sistema de enfriamiento complejo
• En 2022 hubo un paper relacionado: USENIX NSDI22 – Najafi
  • Fue un paper interesante. Resuelve el problema de forma más elegante modelando la curva de respuesta térmica en vez de poner a trabajar el CPU
  • Pero ese paper solo observó la diversidad de sensores térmicos dentro del servidor
    El método de detectar jitter con dos señales PPS es una técnica antigua, y el aprendizaje de tempco también existe desde hace décadas
    Falta validar qué tan preciso es realmente ese tempco aprendido