Serveur NTP / NTS

time.orlinum.fr est un serveur de temps public de strate 1 (stratum 1) : son horloge n'est pas réglée sur un autre serveur, mais directement sur les signaux des satellites GNSS (GPS, GALILEO, GLONASS) et sur leur impulsion de synchronisation PPS (Pulse Per Second, une impulsion électrique émise très exactement à chaque début de seconde). Il n'y a donc aucun intermédiaire entre l'échelle de temps UTC diffusée par les satellites et ce serveur. N'importe quel équipement compatible (serveur, routeur, équipement embarqué) peut y synchroniser son horloge via les protocoles standard NTP et NTS.

time.orlinum.fr is a public Stratum 1 time server: its clock is not set from another server, but directly from GNSS satellite signals (GPS, GALILEO, GLONASS) and their PPS synchronization pulse (Pulse Per Second, an electrical pulse emitted precisely at the start of every second). There is therefore no intermediary between the UTC time scale broadcast by the satellites and this server. Any compatible equipment (server, router, embedded device) can synchronize its clock through the standard NTP and NTS protocols.

Le service s'appuie sur NTPv4 (Network Time Protocol version 4), défini par la RFC 5905. L'idée du protocole est simple : comparer l'heure de deux machines en échangeant quatre horodatages par transaction, en supposant que le message met autant de temps à l'aller qu'au retour. Pour empêcher un tiers de falsifier ces échanges en cours de route, le serveur propose l'extension cryptographique NTS (Network Time Security), définie par la RFC 8915, qui authentifie chaque réponse.

The service relies on NTPv4 (Network Time Protocol version 4), defined by RFC 5905. The protocol's idea is simple: compare the time of two machines by exchanging four timestamps per transaction, assuming the message takes as long on the way out as on the way back. To prevent a third party from tampering with these exchanges in transit, the server offers the NTS (Network Time Security) cryptographic extension, defined by RFC 8915, which authenticates every response.

La construction complète de ce serveur (matériel, noyau temps réel, chrony, sécurité, télémétrie) est expliquée pas à pas, chapitre par chapitre, dans la documentation publique (FR/EN).

The complete build of this server (hardware, real-time kernel, chrony, security, telemetry) is explained step by step, chapter by chapter, in the public documentation (FR/EN).

L'utilisation du client Chrony est préconisée pour assurer une convergence rapide et supporter nativement le protocole NTS. L'option xleave (mode entrelacé) est suggérée pour accroître la précision de l'horodatage matériel. Pour garantir la tolérance aux pannes de la configuration, l'infrastructure pool.ntp.org est proposée dans ces exemples. Pour éviter tout conflit de configuration, une seule de ces trois méthodes doit être implémentée.

The use of the Chrony client is advocated to ensure rapid convergence and natively support the NTS protocol. The xleave option (interleaved mode) is suggested to increase hardware timestamping accuracy. To guarantee fault tolerance, the pool.ntp.org infrastructure is proposed in these examples. To prevent configuration conflicts, only one of these three methods must be implemented.

server time.orlinum.fr nts iburst xleave minpoll 6
pool pool.ntp.org iburst 

server time.orlinum.fr iburst xleave minpoll 6
pool pool.ntp.org iburst

# La clef 42 générée le 26/02/2026 sur time.orlinum.fr
42 SHA256 HEX:A4E57E0554C9860BD5E2C1384768FBA42E305E3617C83085FB655E480879A29F

server time.orlinum.fr key 42 iburst xleave minpoll 6
pool pool.ntp.org iburst 

Comparer deux horloges à travers un réseau, c'est un peu régler sa montre sur l'horloge parlante : entre le moment où l'heure est annoncée et celui où on l'entend, le message a voyagé. NTP mesure ce voyage avec quatre horodatages par transaction : T₁ (départ de la question chez le client), T₂ (arrivée au serveur), T₃ (départ de la réponse), T₄ (retour chez le client). Il en déduit l'écart entre les deux horloges, θ = ((T₂ − T₁) + (T₃ − T₄)) / 2, ainsi que le délai aller-retour δ = (T₄ − T₁) − (T₃ − T₂). Le calcul suppose un trajet symétrique : toute asymétrie réelle du réseau devient une erreur invisible sur l'offset estimé. La fluctuation de ces mesures d'un échantillon à l'autre constitue la gigue (jitter), que chrony atténue par filtrage statistique (moyennage, rejet des aberrants).

Comparing two clocks across a network is a bit like setting your watch by the speaking clock: between the moment the time is announced and the moment you hear it, the message has traveled. NTP measures that journey with four timestamps per transaction: T₁ (request departure at the client), T₂ (arrival at the server), T₃ (response departure), T₄ (return at the client). From these it derives the offset between the two clocks, θ = ((T₂ − T₁) + (T₃ − T₄)) / 2, along with the round-trip delay δ = (T₄ − T₁) − (T₃ − T₂). The computation assumes a symmetrical path: any actual network asymmetry becomes an invisible error on the estimated offset. The fluctuation of these measurements from sample to sample constitutes jitter, which chrony attenuates through statistical filtering (averaging, outlier rejection).

Trois mots reviennent dans les graphes ci-dessous, souvent confondus dans le langage courant : la justesse (à quel point suis-je proche de l'heure vraie, UTC ?), la stabilité (à quel point ma mesure varie-t-elle dans le temps ?) et la précision (quel est le plus petit écart que je sais résoudre ?). Une balance de cuisine peut afficher des décigrammes (précise) tout en pesant systématiquement 20 g de trop (peu juste) : une horloge, c'est pareil. Chaque graphe porte une étiquette indiquant laquelle de ces qualités il éclaire ; la documentation consacre un chapitre entier à cette distinction.

Three words come up in the graphs below, often conflated in everyday language: accuracy (how close am I to the true time, UTC?), stability (how much does my measurement vary over time?) and precision (what is the smallest increment I can resolve?). A kitchen scale can display tenths of a gram (precise) while systematically weighing 20 g too much (not accurate): a clock is no different. Each graph carries a tag indicating which of these qualities it sheds light on; the documentation devotes a full chapter to this distinction.

Le démon chronyd publie en continu l'état de son asservissement : le Stratum (distance à la source primaire), le Last offset et le RMS offset (justesse instantanée et justesse moyenne), la Frequency et le Residual freq (correction de fréquence appliquée au quartz, et son reliquat), le Skew (incertitude sur cette fréquence), et enfin le Root delay et la Root dispersion, transmis aux clients dans chaque paquet pour qu'ils bornent leur propre incertitude selon la relation erreur ≤ |offset| + root_dispersion + root_delay/2.

The chronyd daemon continuously publishes the state of its disciplining loop: the Stratum (distance to the primary source), the Last offset and RMS offset (instantaneous and average accuracy), the Frequency and Residual freq (frequency correction applied to the quartz, and its residual), the Skew (uncertainty on that frequency), and finally the Root delay and Root dispersion, transmitted to clients in every packet so they can bound their own uncertainty according to error ≤ |offset| + root_dispersion + root_delay/2.

Note : Cette compréhension architecturale doit beaucoup aux travaux fondateurs de David L. Mills, à l'analyse de la RFC 5905 par Stéphane Bortzmeyer, ainsi qu'à Kevin Sookocheff.

Note: This architectural understanding owes much to the foundational work of David L. Mills, the RFC 5905 analysis by Stéphane Bortzmeyer, as well as to Kevin Sookocheff.