Vue d’ensemble : pourquoi un Stratum 1 maison#

Pourquoi#

Quand un ordinateur demande l’heure à Internet, il interroge en général un serveur NTP public, souvent un pool de serveurs “Stratum 2” ou “Stratum 3”, eux-mêmes synchronisés sur d’autres serveurs, synchronisés sur d’autres serveurs… jusqu’à remonter, quelque part, à une horloge “de référence” (horloge atomique ou un récepteur GPS, DCF77 …). Chaque niveau de cette chaîne s’appelle une strate (stratum) : plus on est proche de la source physique et plus la précision est grande.

   Stratum 0        Stratum 1       Stratum 2       Stratum 3
    (horloge      (relié à un      (sync. sur      (sync. sur
   physique)       Stratum 0)     un Stratum 1)   un Stratum 2)

       ▼                ▼               ▼               ▼
     [GPS] ─────────► [S1] ─────────► [S2] ─────────► [S3]
    ns à µs          < 1 µs          < 1 ms         < 10 ms

Un serveur Stratum 1 est donc directement relié à une référence physique, ici, un récepteur GNSS (GPS/Galileo/GLONASS/Beidou). C’est le niveau le plus précis qu’on puisse atteindre sans horloge atomique dédiée (qui coûte des dizaines de milliers d’euros). Avec du matériel grand public (~250 €) et une configuration soignée, on peut atteindre une précision autour de la microseconde, largement suffisante pour la quasi-totalité des usages courants (synchronisation de serveurs, journalisation, réseaux domestiques ou de laboratoire). Ce serveur reste une base de temps de proximité, sans vocation à servir de source certifiée pour des infrastructures critiques, des transactions financières ou des systèmes de sécurité (cf. l’avertissement légal du site).

Pourquoi le construire soi-même plutôt qu’utiliser un pool NTP public ? Parce que c’est un excellent projet pour comprendre en profondeur le temps-réel Linux, la métrologie, et le durcissement sécurité d’un service exposé sur Internet, et parce qu’un récepteur GPS direct élimine toute incertitude réseau entre l’utilisateur et la référence de temps, et pour offrir ce service à l’ensemble d’Internet via le projet pool NTP.

Comment : la chaîne complète, en un coup d’œil#

              ┌───────────────────────────────────────────────────────┐
              │  Constellations GNSS (GPS, Galileo, GLONASS, Beidou)  │
              └───────────────────────────────────────────────────────┘
                                          │
                                          ▼ ondes radio
                   ┌─────────────────────────────────────────────┐
                   │  Antenne + récepteur GNSS (u-blox NEO-M9N)  │
                   └─────────────────────────────────────────────┘
                                          │
              ┌───────────────────────────┴───────────────────────────┐
              │ UART                                              PPS │
              │ (position + heure approx.)      (top de seconde, ~ns) │
              ▼                                                       ▼
   ┌─────────────────────┐                                     ┌─────────────┐
   │        gpsd         │                                     │    noyau    │
   │  (lève l'ambiguïté  │                                     │  (IRQ PPS,  │
   │     de seconde)     │                                     │  FIFO 99)   │
   └─────────────────────┘                                     └─────────────┘
              │                                                       │
              └───────────────────────────┬───────────────────────────┘
                                          ▼
                                    ┌───────────┐
                                    │  chronyd  │  ← discipline l'horloge système
                                    └───────────┘    à partir du PPS, filtre le bruit
                                          │
                      ┌───────────────────┴───────────────────┐
                      │                                       │
                      ▼                                       ▼
               horloge système                             NTP/NTS
              (CLOCK_REALTIME)                       (UDP 123, TCP 4460)
                                                          → clients

Le PPS (Pulse Per Second) est la pièce maîtresse : c’est une impulsion électrique physique, générée par le récepteur GNSS à chaque seconde exacte, avec une précision de l’ordre de la dizaine de nanosecondes. C’est elle qui permet une précision autour de la microseconde ; le flux de données issu du récepteur GPS en mode NMEA (position, date) sert uniquement à lever l’ambiguïté de quelle seconde vient de ’tiker’, pas à mesurer l’instant exact lui-même.

Résultats mesurés en production#

Métrique	Valeur observée
RMS offset	~0,07 à 1,7 µs (pire cas)
Dérive (skew)	0,007 à 0,05 ppm

Ces chiffres ne sont pas un plafond théorique inatteignable : ils sont issus d’un Raspberry Pi 5 avec une antenne GNSS intérieure posée sur un rebord de fenêtre, sans blindage ni local technique dédié.

Erreurs à éviter (au niveau architecture)#

Confondre précision et exactitude. Un serveur peut être très stable (faible dérive) mais décalé d’une valeur constante, ou l’inverse. Les chapitres suivants montrent comment vérifier les deux.
Négliger la stabilité thermique. Le composant qui cadence l’horloge (un oscillateur à quartz ordinaire, non compensé) dérive avec la température, d’environ 0,1 ppm/°C. Un boîtier mal ventilé peut dégrader la précision de manière invisible sans mesure dédiée (cf. chapitres Stabilisation thermique et Du quartz nu au pseudo-TCXO).
Négliger la sécurité parce que “ce n’est qu’un serveur NTP”. Un service exposé sur Internet, quel qu’il soit, est une cible. Ce guide intègre une phase de durcissement dès le départ.

Vérifier#

Une seule chose à vérifier à ce stade, et c’est la plus importante : la motivation. Ce guide est long, minutieux, parfois laborieux : des dizaines de chapitres, des vérifications à chaque étape, des reboots à répétition et quelques nuits à regarder évoluer un RMS offset. Si l’envie est intacte après cette page, la condition la plus critique du projet est remplie, aucun des chapitres suivants ne la testera aussi honnêtement. Le chapitre suivant pose le vocabulaire de la métrologie (précision, justesse, stabilité) sur lequel repose tout le reste du guide.

📚 Pour aller plus loin
La hiérarchie des strates NTP est définie dans la RFC 5905 (Network Time Protocol Version 4: Protocol and Algorithms Specification, D. Mills et al., 2010), § 3.1.
Le protocole on-wire (calcul d’offset à partir de 4 timestamps) et l’algorithme de sélection des sources (dérivé de l’algorithme de Marzullo, 1984, adapté par Mills pour NTP) sont couverts au chapitre Chrony.

Sources et remerciements#

Au-delà des RFC citées tout au long de ce guide, trois ressources ont servi de repère constant pendant sa rédaction, et méritent d’être créditées explicitement :

David L. Mills, NTP homepage, le site de l’auteur original du protocole NTP et de ses algorithmes de discipline d’horloge, la source primaire sur la conception même de NTP.
Stéphane Bortzmeyer, « RFC 5905: Network Time Protocol Version 4 Protocol And Algorithms Specification », une lecture commentée en français de la RFC qui définit NTPv4, précise et accessible.
sookocheff.com, « How Does NTP Work? », une introduction en anglais qui explique clairement le calcul d’offset et de délai à partir des quatre timestamps.

Le chapitre Anatomie du paquet NTP doit directement son existence à ces trois lectures.