Qu'est-ce que le délai aller-retour (RTD) NTP ?

Le RTD est l'intervalle entre l'émission d'une requête NTP et la réception de la réponse, mesuré côté client. NTP utilise le RTD pour estimer la latence aller simple (RTD/2) et borner l'incertitude du calcul d'offset. RTD faible = offset précis ; RTD élevé = borne lâche.

Comment le RTD affecte-t-il la précision NTP ?

Le calcul d'offset suppose une latence aller simple symétrique. En pratique, l'incertitude sur l'offset est approximativement RTD/2. Un RTD de 10 ms donne une erreur d'offset maximale ±5 ms ; un RTD de 300 ms donne ±150 ms. Pour un temps précis, choisissez des sources avec RTD faible ET stable — pas seulement faible.

Quel RTD est acceptable pour une source NTP ?

Même région (< 500 km) : < 10 ms. Même continent : 10–50 ms. Intercontinental : 100–250 ms. Au-delà de 300 ms, la source est mal choisie ou le chemin dégradé. Préférez 3–5 sources régionales à une seule continentale.

Comment benchmarker la latence NTP sur plusieurs serveurs ?

CLI Linux : 'chronyc sourcestats -v' affiche offset, fréquence, skew et écart-type par source configurée. Pour une sonde ponctuelle : 'ntpdate -q <serveur>' ou 'sntp <serveur>' fournissent un RTD et offset unique. Pour les serveurs EU, RTD typiques depuis Paris : 1–3 ms (ntp.rdem-systems.com), 4–10 ms (Cloudflare), 15–30 ms (NIST via Atlantique).

La latence basse est-elle plus importante que le jitter bas ?

Le jitter est plus important que la latence brute, car les algorithmes NTP compensent une latence fixe mais amplifient une latence variable. Un lien stable à 50 ms surpasse un lien jittery à 5 ms pour la précision NTP. Optimisez pour faible ET stable — pas juste faible.

Benchmark de Latence NTP | Délai Aller-Retour & Comparatif de Serveurs

Q: Quel RTD est acceptable pour une source NTP ?

Même région (< 500 km) : < 10 ms. Même continent : 10–50 ms. Intercontinental : 100–250 ms. Au-delà de 300 ms, la source est mal choisie ou le chemin dégradé. Préférez 3–5 sources régionales à une seule continentale.

Q: Comment benchmarker la latence NTP sur plusieurs serveurs ?

CLI Linux : 'chronyc sourcestats -v' affiche offset, fréquence, skew et écart-type par source configurée. Pour une sonde ponctuelle : 'ntpdate -q <serveur>' ou 'sntp <serveur>' fournissent un RTD et offset unique. Pour les serveurs EU, RTD typiques depuis Paris : 1–3 ms (ntp.rdem-systems.com), 4–10 ms (Cloudflare), 15–30 ms (NIST via Atlantique).

Sommaire

1. Délai aller-retour (RTD) — ce qu'il borne
2. RTD acceptable selon la distance géographique
3. Méthodologie de benchmark
4. Comparatif des sources NTP européennes courantes
5. Latence vs jitter vs stratum — le compromis
6. Mesure de latence depuis le navigateur (ce testeur)

1. Délai aller-retour (RTD) — ce qu'il borne

Le RTD est l'intervalle entre l'émission d'une requête NTP et la réception de la réponse, mesuré côté client. NTP en déduit la latence aller simple comme RTD/2 — hypothèse de chemin symétrique approximativement vraie sur un réseau filaire.

Pourquoi c'est critique pour la précision : le calcul d'offset suppose que la latence aller est identique dans les deux sens. Si les latences réelles sont L_out et L_in, l'erreur d'offset due à l'asymétrie est |L_out − L_in| / 2. Le RTD borne l'asymétrie au pire cas : au plus RTD/2 d'erreur d'offset.

Règle pratique. Une source avec RTD = 10 ms peut délivrer une précision d'offset jusqu'à ±5 ms (pire cas) et typiquement ±1 ms (chemin symétrique stable). Une source avec RTD = 300 ms borne la précision à ±150 ms — c'est pourquoi le NTP continental/intercontinental est rarement utilisé comme référence Stratum 2 primaire.

2. RTD acceptable selon la distance géographique

Localisation source vs client	RTD attendu	Adéquation
Même datacenter / même LAN	< 1 ms	Idéal pour Stratum 2 interne
Même ville / métropole	1–5 ms	Excellent
Même région (< 500 km)	5–15 ms	Très bon
Même pays	10–30 ms	Bon
Même continent	30–80 ms	Acceptable en général
Intercontinental	100–250 ms	Fallback seulement
Satellite / mobile	200–800 ms	Dernier recours

3. Méthodologie de benchmark

Trois techniques complémentaires, du plus léger au plus rigoureux :

3.1 Sonde unique

Un seul aller-retour UDP. Rapide, mais une mesure isolée reflète le jitter instantané et peut induire en erreur.

$ sntp time.rdem-systems.com
+0.000234 +/- 0.001450 ntp.rdem-systems.com 172.104.143.97 s1 no-leap

$ ntpdate -q ntp.rdem-systems.com
server 172.104.143.97, stratum 1, offset +0.000234, delay 0.01821

3.2 Sonde multi-échantillon moyennée

10 à 60 échantillons sur une minute ; reportez moyenne, médiane et écart-type. Plus fiable.

# nping (suite nmap) comme sonde NTP générique
$ nping --udp --dest-port 123 --count 30 --delay 1s ntp.rdem-systems.com

# Ou l'aide dédiée chrony
$ chronyd -Q 'server ntp.rdem-systems.com iburst minpoll 2 maxpoll 2'

3.3 Supervision continue (la méthode de référence)

Ajoutez la source à votre chrony/ntp.conf et observez offset, jitter et RTD sur plusieurs heures. Seul moyen de capter les dégradations aux heures de pointe et les motifs hebdomadaires.

$ chronyc sourcestats -v

4. Comparatif des sources NTP européennes courantes

RTD typiques mesurés depuis Paris (avril 2026, fibre filaire, fenêtre moyenne d'1 minute). Vos résultats dépendront de votre FAI et de l'heure.

Source	Localisation	RTD typique (Paris)	Notes
`ntp.rdem-systems.com`	France (AS206014)	1–3 ms	Stratum 1 GNSS + PPS, NTS-capable
`time.cloudflare.com`	Anycast (PoP le plus proche)	2–8 ms	NTS-capable ; qualité selon PoP proche
`ntp1.ptb.de`	Braunschweig, DE	10–20 ms	Institut de métrologie allemand
`nts.netnod.se`	Stockholm, SE	25–40 ms	Stratum 1, implémentation NTS de référence
`time.nist.gov`	USA (anycast)	80–150 ms	Référence US faisant autorité, non optimale côté EU
`pool.ntp.org`	Variable (aléatoire)	2–80 ms	Volontaires, imprévisible à chaque requête

5. Latence vs jitter vs stratum — le compromis

Pour choisir une source NTP, trois propriétés se disputent :

Strate — plus basse = mieux (proche de la référence atomique).
RTD — plus bas = mieux (borne d'offset plus serrée).
Jitter — plus bas = mieux (mesure plus fiable).

Ces propriétés ne s'alignent rarement parfaitement. Un Stratum 1 public sur un autre continent a un excellent stratum mais un RTD médiocre. Un Stratum 2 régional a un meilleur RTD mais hérite de la précision de son amont. La sagesse conventionnelle :

Préférez un Stratum 2 régional à RTD faible et stable à un Stratum 1 lointain.
Cumulez 3–5 sources aux topologies amont distinctes pour que l'algorithme d'intersection puisse écarter un false ticker.
Pour des workloads réglementés, terminez sur une source authentifiée (NTS) pour garantir que le stratum n'est pas usurpé.

6. Mesure de latence depuis le navigateur (ce testeur)

Le testeur d'accueil reporte le RTD réseau sous « Latence » — le round-trip HTTPS vers notre référence Stratum 1 GNSS. Moins précis que du NTP UDP natif (HTTPS ajoute le handshake TLS), mais suffisant pour une estimation au premier ordre sans rien installer.

Utilisez-le comme baseline : si le navigateur reporte 200 ms vers notre serveur parisien depuis un FAI parisien, soit votre connexion est bufferbloatée, soit notre serveur reçoit un pic transitoire. Retestez dans une minute pour confirmer.

Lancer le Benchmark de Latence →