EN FR Accueil

Benchmark de Latence NTP

Délai aller-retour, comparatif de serveurs et méthodologie de mesure

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.

2. RTD acceptable selon la distance géographique

Localisation source vs clientRTD attenduAdéquation
Même datacenter / même LAN< 1 msIdéal pour Stratum 2 interne
Même ville / métropole1–5 msExcellent
Même région (< 500 km)5–15 msTrès bon
Même pays10–30 msBon
Même continent30–80 msAcceptable en général
Intercontinental100–250 msFallback seulement
Satellite / mobile200–800 msDernier 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.

SourceLocalisationRTD typique (Paris)Notes
ntp.rdem-systems.comFrance (AS206014)1–3 msStratum 1 GNSS + PPS, NTS-capable
time.cloudflare.comAnycast (PoP le plus proche)2–8 msNTS-capable ; qualité selon PoP proche
ntp1.ptb.deBraunschweig, DE10–20 msInstitut de métrologie allemand
nts.netnod.seStockholm, SE25–40 msStratum 1, implémentation NTS de référence
time.nist.govUSA (anycast)80–150 msRéférence US faisant autorité, non optimale côté EU
pool.ntp.orgVariable (aléatoire)2–80 msVolontaires, 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 :

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

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 →

Au-delà de la latence ? Utilisez l'outil adapté :

Questions fréquentes

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 (&lt; 500 km) : &lt; 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 &lt;serveur&gt;' ou 'sntp &lt;serveur&gt;' 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.