Le Raspberry Pi le plus stable ? Une précision NTP améliorée de 81 % grâce à la gestion thermique

• Présentation des résultats d’une expérimentation combinant l’affectation fixe des cœurs CPU et la stabilisation thermique pour réduire les variations de fréquence d’un serveur NTP basé sur Raspberry Pi
• Observation du fait que les variations de température du CPU provoquent une dérive de fréquence de l’oscillateur à quartz, puis stabilisation en maintenant une température constante
• Grâce à un processus « time burner » basé sur une régulation PID maintenant le CPU à 54°C, obtention d’une réduction de 81 % des variations de fréquence et de 77 % de l’écart-type
• En réservant le CPU 0 à chronyd et en maintenant la charge thermique sur les autres cœurs, amélioration de l’offset NTP jusqu’à un niveau moyen d’environ 38 ns
• Mise en évidence de la possibilité de réaliser un serveur de timing haute précision à faible coût pour des environnements exigeant une exactitude extrême, comme la synchronisation temporelle de précision ou les équipements scientifiques

---

Problème : instabilité temporelle due aux variations de température

• La fonction de mise à l’échelle dynamique de la fréquence (DVFS) du Raspberry Pi est avantageuse pour l’efficacité énergétique, mais défavorable à la synchronisation temporelle de précision
  • Lorsque la fréquence d’horloge varie selon la charge CPU, la cadence des ticks de l’horloge système varie elle aussi
• La fréquence de l’oscillateur à quartz est sensible à la température et varie de plusieurs ppm selon l’échauffement du CPU
  • Les variations de température entre le jour et la nuit entraînent une dérive de fréquence
• Les résultats de surveillance dans Grafana montrent un offset de fréquence d’environ ±1 ppm selon les variations de température du CPU
  • L’offset RMS moyen se situe autour de 86 ns, ce qui laisse une marge d’amélioration

Constat : l’effet bénéfique d’une température constante

• Il a été confirmé qu’en maintenant une température CPU constante, il est possible d’améliorer la stabilité de fréquence
• La solution se compose de deux volets
  1. Isolation des cœurs CPU – affecter chronyd et les interruptions PPS uniquement au CPU 0
  2. Stabilisation thermique – maintenir les autres cœurs en activité continue pour conserver une température constante
• Lorsque le système de stabilisation thermique a été activé le 17 novembre 2025 à 09:10, les oscillations de fréquence ont immédiatement diminué

Solution 1 : affectation fixe des cœurs CPU et priorité temps réel

• CPU 0 : réservé à chronyd et aux interruptions PPS
• CPU 1–3 : tâches générales et maintien de la charge thermique
• Mise en place d’un script d’optimisation exécuté automatiquement au démarrage
  • Forcer le mode de gouvernance de fréquence CPU sur performance
  • Épingler PPS IRQ(200) sur le CPU 0
  • Définir chronyd en priorité temps réel (SCHED_FIFO 50)
  • Augmenter la priorité du processus ksoftirqd/0
• Le script peut être enregistré dans /etc/rc.local ou comme service systemd

Solution 2 : stabilisation thermique basée sur une régulation PID

• Pour maintenir une température CPU constante, utilisation d’une boucle de contrôle PID
  • Température cible : 54°C
  • Trois processus workers sur CPU 1–3 génèrent de la charge via des calculs de hash MD5
  • Le temps de calcul et le temps d’attente sont ajustés selon la valeur de sortie du PID
• Paramètres PID
  • Kp=0.05, Ki=0.02, Kd=0.0
  • Comme les variations de température sont lentes, le terme dérivé (Kd) est fixé à 0
• Au final, la température CPU reste stable dans une plage de ±0.2°C

Résultats : amélioration de la stabilité de fréquence

• Réduction de 81 % de la variabilité de fréquence, 77 % de réduction de l’écart-type et 49 % de réduction de l’offset RMS
• Offset RMS moyen : 85.44ns → 43.54ns
• Offset RMS médian : 80.13ns → 37.93ns
• Avec le CPU maintenu à 54°C, obtention d’une stabilité de fréquence dans une plage de ±0.14 ppm
• La stabilité est maintenue malgré les variations de température ambiante (18.9~22.2°C)

Procédure de configuration

• Préparation préalable : mise en place nécessaire d’un serveur NTP basé sur GPS PPS
• Installation des paquets requis
  • linux-cpupower, python3, util-linux
• Création du script d’optimisation au démarrage /usr/local/bin/pps-optimize.sh et enregistrement dans systemd
• Création du script de contrôle thermique /usr/local/bin/time_burner.py et enregistrement comme service
  • ExecStart=/usr/bin/python3 /usr/local/bin/time_burner.py -t 54.0 -n 3
• Commandes de validation
  • Vérifier que le governor CPU est sur performance
  • Vérifier l’affinité CPU et la priorité de chronyd
  • Mesurer l’offset RMS avec chronyc tracking (par exemple autour de 35ns)

Supervision et résolution de problèmes

• Surveillance en temps réel : watch -n 1 "chronyc tracking"
• Vérification de l’état du service : sudo systemctl status time-burner.service
• Réglage PID
  • En cas d’oscillations de température, diminuer Kp ; si la stabilisation est trop lente, augmenter Ki
  • La température cible peut être ajustée dans une plage de 50 à 60°C
• Une utilisation CPU élevée (environ 90 %) est un comportement intentionnel

Compromis

• Consommation électrique en hausse : 3–4W consommés en continu (environ 15–25kWh par an)
• Échauffement accru : maintien à 54°C, dans une plage sûre
• Occupation des ressources CPU : 3 cœurs utilisés sur 4
  • Adapté à un équipement dédié au NTP, inadapté à un environnement multi-services

Domaines d’application possibles

• Synchronisation temporelle de précision, équipements scientifiques, recherche sur les systèmes distribués, tests réseau, etc.
• Excessif pour un usage général, mais utile pour mettre en place un environnement expérimental haute précision à faible coût

Pistes d’amélioration futures

• Réglage PID adaptatif pour s’adapter aux variations saisonnières de température
• Contrôle de refroidissement matériel (ventilateur PWM, etc.) pour améliorer l’efficacité énergétique
• L’utilisation d’un OCXO (oscillateur à quartz thermostabilisé) pourrait éliminer la dérive thermique

Conclusion

• Combiner l’affectation fixe des cœurs CPU et la gestion thermique par PID permet de réaliser un serveur NTP ultra-précis
• Amélioration de 81 % de la stabilité de fréquence, avec un offset RMS atteignant 38 ns
• L’expérimentation démontre la corrélation entre gestion thermique et ordonnancement temps réel
• Il s’agit d’un projet davantage centré sur l’exploration technique et la valeur pédagogique que sur la praticité

[GN⁺]

Avis Hacker News

• Éviter CPU0 et définir idle=poll sur la ligne de commande du noyau peut permettre d’obtenir une meilleure précision
  CPU0 concentre d’autres interruptions, donc il n’est pas adapté aux tâches qui exigent une haute précision temporelle
  • Je pense pareil. Dans notre distribution d’OS basée sur Debian, nous appliquons aussi des optimisations similaires, comme la désactivation du frequency scaling et l’affinité des cœurs
    CPU0 a beaucoup de tâches système qui ne peuvent pas être déplacées, donc il est bien préférable d’utiliser un autre cœur comme îlot isolé (isolated core)
    La latence de l’ordonnanceur sur notre cœur isolé est très stable, avec un minimum de 1µs, une moyenne de 5µs et un maximum d’environ 59µs
  • Bon conseil. Je compte essayer moi-même plus tard aujourd’hui
• À la station émettrice WWVB, ils isolent les équipements avec des centaines de bouteilles d’eau pour éviter les variations de température
  Article connexe : Spare Time – JILA
  • Cette page mérite d’être partagée à elle seule. Le fait qu’ils exploitent quatre horloges atomiques avec un onduleur composé de deux batteries de voiture et de deux phares est vraiment impressionnant
    La masse thermique faite de bouteilles d’eau est aussi fascinante
  • J’utilise une méthode similaire. Je stocke de l’eau sous un bureau dans un local isolé pour éviter qu’il gèle pendant la nuit
    C’est un peu comme mettre une pierre chaude dans un sac de couchage
• C’est Austin (austinsnerdythings.com). J’ai publié le billet hier soir, je suis allé dormir, et j’ai été surpris de me réveiller en voyant qu’il était n°1 sur HN
  Mon LEA-M8T génère une impulsion temporelle à 16Hz, et j’ai défini dpoll=-4 dans la configuration de chrony. Cela améliore la stabilité en collectant 256 échantillons sur 16 secondes
  J’ai aussi un BH3SAP GPSDO à côté du bureau. Claude a modifié le firmware pour ajouter un mode flywheel qui continue à générer des impulsions GPS même sans PPS GPS
  Il a aussi été mis à jour pour prendre en charge la sortie TSIP (protocole Trimble). J’en parlerai dans un prochain billet
  Je répondrai bientôt aussi aux commentaires, et les questions sont toujours les bienvenues
  • Merci pour ce bon billet. J’ai moi aussi une configuration similaire, donc c’est très utile
    Je me demande combien la pulsation à 16Hz change réellement les choses. Et j’aimerais aussi savoir comment vous injectez les données dans influxdb. J’utilise collectd, mais il y a peu d’informations
  • Super projet. Je me demande si vous avez mis le Raspberry Pi dans un boîtier
    Même un boîtier métallique pourrait donner des résultats plus stables face aux variations cycliques de température dues au chauffage ou à la climatisation
• Remplacer le cristal d’oscillateur d’un Pi d’entrée de gamme par un TCXO peut donner une fréquence bien plus stable
  Documentation connexe : Raspberry Pi StackExchange – remplacement de l’oscillateur
  Rien qu’avec cette méthode, la dérive diminue de 4 à 5 fois. C’est encore mieux en la combinant avec d’autres techniques
  • J’ai lu ce billet plusieurs fois. Il existe aussi des HAT audiophiles avec OCXO pour Pi4
    Mais je ne suis pas assez sûr de mes compétences en soudure pour faire le remplacement moi-même
  • Le prix des TCXO est étonnamment bas. Certains modèles d’Abracon étaient à moins de 2 dollars
• C’est un OCXO à l’échelle SBC. Je me demande si ajouter un dissipateur plus grand ou de la masse thermique autour de l’oscillateur pourrait aider
  Même le simple fait de configurer un serveur NTP permet d’apprendre beaucoup de choses
  • Je recommande le boîtier métallique Flirc. Le CPU est en contact direct avec le corps du boîtier, ce qui crée une grande masse thermique
    Cela permet un excellent refroidissement passif sans ventilateur
  • Je pense un peu la même chose. Poser un bloc métallique sur le CPU et l’oscillateur pour augmenter l’inertie thermique pourrait être une bonne idée
    Si la température change lentement, la dérive de l’horloge changera elle aussi plus lentement, ce qui facilite la correction
    En revanche, un petit dissipateur peut au contraire devenir plus sensible aux variations de température ambiante
  • J’envisage aussi d’ajouter un isolant au boîtier du Pi
    Cela pourrait atténuer les variations brusques de température de la pièce (ouvrir une fenêtre, humidité après une douche, etc.) et éviter que le CPU ne chauffe inutilement
    Au final, le but est de maintenir la température aussi constante que possible
  • Mais évacuer trop de chaleur peut au contraire être contre-productif
    Les autres cœurs fonctionnent déjà près de leur température maximale et ajustent automatiquement leur fréquence en fonction de la température
    Un refroidissement excessif peut perturber ce mécanisme interne d’autorégulation thermique
• Il est aussi possible de chauffer directement le cristal en y fixant une résistance et de la mousse isolante
  On peut ajouter un transistor pilotable par GPIO pour maintenir la température avec une régulation PID
  • C’est une méthode utilisée depuis presque 100 ans. Dans les années 1950, les fours à cristal étaient maintenus autour de 75°C dans une petite boîte métallique
    Ils étaient stables parce qu’on utilisait des cristaux taillés pour avoir un coefficient de température proche de 0
    Les équipements récents utilisent encore ce type d’architecture, et il faut environ 5 minutes pour une stabilisation complète
  • J’ai moi aussi fait autrefois une expérience en posant un Pi sur de la mousse d’emballage
    Cela réduisait les variations de température ambiante, mais au final la solution la plus sûre reste de le placer dans une chambre à température contrôlée
• Plutôt que de faire chauffer le CPU pour maintenir la température, je me demande s’il ne vaudrait pas mieux utiliser un microcontrôleur et un oscillateur de précision
  Par exemple, une carte STM32 avec Ethernet utilisée comme serveur NTP semblerait plus stable
  • J’ai aussi ça. Un BH3SAP GPSDO acheté 70 dollars sur eBay, qui prend en charge le mode flywheel avec un firmware modifié
    Il peut fournir un signal NTP au Pi, et aussi à un STM32, mais il n’a pas de fonction Ethernet intégrée à l’origine
  • En général, NTP est un processus sensible au temps, donc un MCU est bien plus stable qu’un SoC
    RTLinux a même une fonction pour synchroniser l’ordonnanceur avec l’état de broches externes
    Mais quand le nombre de processeurs augmente, des problèmes de métastabilité (metastability) apparaissent
    Le Pi n’offre pas de garanties temps réel comme un FPGA (Zynq)
• Je n’avais jamais pensé à appliquer délibérément de la charge pour maintenir la température du SoC constante
  Mais comme la consommation électrique est faible, il est logique de résoudre le problème en gaspillant un peu d’énergie plutôt qu’avec un système de refroidissement complexe
• Il y avait un article scientifique lié à cela en 2022 : USENIX NSDI22 – Najafi
  • C’était un article intéressant. Il résout le problème de manière plus élégante en modélisant la courbe de réponse thermique plutôt qu’en faisant chauffer le CPU
  • Mais cet article se contente surtout d’observer la diversité des capteurs de température dans un serveur
    La méthode de détection du jitter avec deux signaux PPS est une vieille technique, et le tempco learning existe depuis des décennies
    Il manque une validation montrant à quel point ce tempco appris est réellement précis