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 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.018213.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 -v4. 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.
Au-delà de la latence ? Utilisez l'outil adapté :
- Diagnostiquer firewall / port 123 / démon → check-ntp.net
- Audit conformité NIS 2 / ISO 27001 → online-ntp-validator.com
- Architecture de référence entreprise → ntp.rdem-systems.com