Serveur NTP / NTS

time.orlinum.fr est un serveur NTP public de strate 1 (stratum 1). Il distribue une référence temporelle disciplinée localement par un récepteur GNSS multi-constellation (GPS, GALILEO, GLONASS) couplé à un signal PPS (Pulse Per Second). Cette architecture place la source de temps à un saut de l'échelle UTC, sans relais NTP intermédiaire. Le service permet la synchronisation des horloges de toute infrastructure compatible (serveurs, routeurs, équipements embarqués) via les protocoles NTP standard et NTS.

time.orlinum.fr is a public Stratum 1 NTP server. It distributes a time reference disciplined locally by a multi-constellation GNSS receiver (GPS, GALILEO, GLONASS) coupled with a PPS (Pulse Per Second) signal. This architecture places the time source one hop from the UTC scale, with no intermediate NTP relay. The service enables clock synchronization for any compatible infrastructure (servers, routers, embedded devices) through the standard NTP and NTS protocols.

Le service s'appuie sur le NTPv4 (Network Time Protocol version 4), défini par la RFC 5905. Le protocole estime le décalage entre l'horloge cliente et celle du serveur à partir de quatre estampilles temporelles échangées dans chaque transaction, sous l'hypothèse de symétrie des délais aller-retour. Pour garantir l'authenticité des paquets et prévenir toute manipulation par un tiers, le serveur implémente l'extension cryptographique NTS (Network Time Security), définie par la RFC 8915.

The service relies on NTPv4 (Network Time Protocol version 4), defined by RFC 5905. The protocol estimates the offset between the client and server clocks from four timestamps exchanged in each transaction, under the assumption of symmetrical round-trip delays. To guarantee packet authenticity and prevent third-party tampering, the server implements the NTS (Network Time Security) cryptographic extension, specified by RFC 8915.

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 votre 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.

La synchronisation de deux horloges via un réseau IP repose sur quelques grandeurs métrologiques fondamentales. À un instant donné, l'horloge locale présente un écart de phase (offset) par rapport au temps de référence (UTC) : si cet écart reste borné, l'horloge est dite exacte (accurate). Cet écart évolue dans le temps, car l'oscillateur à quartz qui rythme l'horloge tourne à une fréquence légèrement différente de sa valeur nominale. Ce décalage de fréquence (frequency offset), exprimé en parties par million (ppm), traduit la vitesse à laquelle la phase s'éloigne de la référence. La fréquence elle-même n'est pas constante : elle varie sous l'effet de la température, du vieillissement du quartz et des contraintes mécaniques, induisant une dérive lente (drift). Enfin, l'horloge est bornée par sa résolution (precision), le plus petit incrément temporel qu'elle peut représenter.

Pour mesurer ces grandeurs malgré un canal réseau dont le délai est variable, NTP procède par échange de quatre estampilles à chaque transaction : T₁ (départ de la requête côté client), T₂ (réception côté serveur), T₃ (émission de la réponse côté serveur), T₄ (réception de la réponse côté client). De ces quatre valeurs, l'algorithme déduit l'écart de phase θ = ((T₂ − T₁) + (T₃ − T₄)) / 2 et le délai aller-retour δ = (T₄ − T₁) − (T₃ − T₂). Le calcul postule la symétrie du chemin : toute asymétrie réelle se reporte intégralement sur l'estimation de l'offset. La fluctuation de ces mesures d'un échantillon à l'autre constitue la gigue (jitter), atténuée par les filtres statistiques de NTP (moyennage, rejet des aberrants).

Le démon chronyd expose en continu l'état de son asservissement à travers plusieurs registres mesurables. Le Stratum indique la distance topologique à la racine de la hiérarchie temporelle (la valeur 1 atteste un asservissement direct à une source matérielle, sans relais NTP). L'écart de phase est rapporté par le Last offset (estimation de l'offset entre horloge locale et référence à la dernière mise à jour) et par le RMS offset (moyenne quadratique long terme des offsets, indicateur agrégé de stabilité). Le décalage de fréquence est quantifié par la Frequency (vitesse à laquelle l'horloge système s'écarterait sans correction logicielle, en ppm) et par le Residual freq (différence entre la fréquence indiquée par les dernières mesures et celle effectivement appliquée ; tend vers zéro lorsque la source est consistante). Le Skew chiffre la borne d'erreur estimée sur la Frequency. Le Root delay mesure la somme des délais réseau aller-retour jusqu'au stratum-1, et la Root dispersion agrège l'erreur maximale cumulée (résolution d'horloge, variations statistiques) ; ces deux grandeurs sont diffusées aux clients pour borner l'incertitude absolue selon la relation erreur ≤ |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.

Synchronizing two clocks over an IP network relies on a few fundamental metrological quantities. At any instant, the local clock exhibits a phase offset with respect to the reference time (UTC); if this offset stays bounded, the clock is said to be accurate. The offset evolves over time because the quartz oscillator that drives the clock runs at a frequency slightly different from its nominal value. This frequency offset, expressed in parts per million (ppm), is the rate at which the phase departs from the reference. The frequency itself is not constant: it varies with temperature, oscillator ageing and mechanical stress, producing a slow drift. Finally, the clock is bounded by its precision, that is, the smallest time increment it can represent.

To measure these quantities despite a network channel with variable delay, NTP exchanges four timestamps per transaction: T₁ (request departure on the client), T₂ (reception on the server), T₃ (response transmission on the server), T₄ (reception on the client). From these four values, the algorithm derives the phase offset θ = ((T₂ − T₁) + (T₃ − T₄)) / 2 and the round-trip delay δ = (T₄ − T₁) − (T₃ − T₂). This computation assumes path symmetry: any actual asymmetry projects directly onto the offset estimate. The fluctuation of these measurements between samples constitutes jitter, attenuated by NTP's statistical filters (averaging, outlier rejection).

The chronyd daemon continuously exposes the state of its disciplining loop through several observable registers. The Stratum indicates the topological distance to the root of the time hierarchy (a value of 1 attests direct locking to a hardware reference, with no NTP relay). The phase offset is reported by the Last offset (estimate of the offset between local clock and reference at the last update) and by the RMS offset (long-term root-mean-square average of offsets, an aggregate stability indicator). The frequency offset is quantified by Frequency (the rate at which the system clock would drift without software correction, in ppm) and by Residual freq (the difference between the frequency indicated by the latest measurements and the one currently applied; it tends to zero when the source is consistent). Skew gives the estimated error bound on Frequency. Root delay measures the sum of round-trip network delays to the stratum-1 source, and Root dispersion aggregates the maximum accumulated error (clock resolution, statistical variations); both quantities are propagated to clients to bound the absolute uncertainty according to error ≤ |offset| + root_dispersion + root_delay/2.

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.