Qu'est-ce que le jitter NTP en termes simples ?

Le jitter est l'écart-type des mesures d'offset sur une courte fenêtre. Si chaque poll NTP retourne une valeur d'offset différente, le jitter est élevé : la mesure est bruitée. Un jitter faible signifie que l'estimation d'offset est stable et fiable.

Quelle valeur de jitter NTP est acceptable ?

LAN filaire : < 1 ms. WAN filaire continental : 1–5 ms. Broadband domestique stable : 2–10 ms. Wi-Fi ou chemin congestionné : 10–30 ms est courant. Au-delà de 50 ms, investiguer le chemin ou la source.

Qu'est-ce qui cause un jitter NTP élevé ?

Quatre causes dominantes : (1) bufferbloat sur l'uplink, (2) retransmissions et contention Wi-Fi, (3) serveur NTP surchargé (file d'attente UDP), (4) routage asymétrique où les deux directions ont des latences différentes.

Comment mesurer le jitter NTP sur Linux ?

Lancez 'chronyc sources -v' ou 'chronyc sourcestats'. La colonne 'Jitter' sur ntpq (ntpd classique) ou 'Std Dev' sur chrony reporte le jitter par source. Pour un poll unique : 'sntp -d <serveur>' montre la variation de délai.

Le jitter est-il identique à la latence ?

Non. La latence est le délai aller (ou aller-retour) — une valeur scalaire. Le jitter est la variation de cette latence (ou de l'offset dérivé) entre mesures successives. Une source peut avoir une latence élevée mais un jitter faible (lien lent stable) ou une latence faible mais un jitter élevé (Wi-Fi rapide mais variable).

Analyse du Jitter NTP | Seuils, Causes & Méthodes de Mesure

Q: Quelle valeur de jitter NTP est acceptable ?

LAN filaire : < 1 ms. WAN filaire continental : 1–5 ms. Broadband domestique stable : 2–10 ms. Wi-Fi ou chemin congestionné : 10–30 ms est courant. Au-delà de 50 ms, investiguer le chemin ou la source.

Q: Qu'est-ce qui cause un jitter NTP élevé ?

Quatre causes dominantes : (1) bufferbloat sur l'uplink, (2) retransmissions et contention Wi-Fi, (3) serveur NTP surchargé (file d'attente UDP), (4) routage asymétrique où les deux directions ont des latences différentes.

Q: Comment mesurer le jitter NTP sur Linux ?

Lancez 'chronyc sources -v' ou 'chronyc sourcestats'. La colonne 'Jitter' sur ntpq (ntpd classique) ou 'Std Dev' sur chrony reporte le jitter par source. Pour un poll unique : 'sntp -d <serveur>' montre la variation de délai.

Sommaire

1. Ce que mesure réellement le jitter NTP
2. Jitter acceptable par type de réseau
3. Les causes d'un jitter élevé
4. Mesurer le jitter — CLI et navigateur
5. Réduire un jitter élevé
6. Jitter, offset, drift — les différences

1. Ce que mesure réellement le jitter NTP

Le jitter NTP est la dispersion statistique — typiquement l'écart-type ou une variance lissée — de mesures d'offset successives entre un client et l'une de ses sources temporelles. Il quantifie à quel point le chemin est bruité, pas l'exactitude de la source.

Un client qui sonde un serveur huit fois et voit des offsets de -2, -3, -1, -2, -4, -2, -3, -2 millisecondes a un jitter faible (~1 ms). Un client observant -2, +18, -9, +24, -11, +6, -3, +15 ms a la même moyenne mais un jitter très élevé — les mesures individuelles ne sont pas fiables, même si leur moyenne reste correcte.

Pourquoi le jitter compte pour la précision. NTP sélectionne ses sources et applique un lissage exponentiel en utilisant le jitter comme entrée. Une source à jitter élevé reçoit moins de poids dans l'algorithme — c'est pourquoi une source de mauvaise qualité dégrade la précision même si sa moyenne est correcte.

2. Jitter acceptable par type de réseau

Lien / scénario	Jitter typique	Action
LAN filaire, même datacenter	< 1 ms	Sain
WAN filaire, continental	1–5 ms	Sain
Broadband domestique, au repos	2–10 ms	Acceptable
Wi-Fi, activité normale	10–30 ms	Acceptable si non critique
Mobile LTE/5G	15–50 ms	À surveiller, pas pour Stratum 2
Tout chemin	> 50 ms	Investiguer
Tout chemin	> 200 ms	Source inutilisable comme référence

Les workloads de trading financier ou de synchronisation télécom opèrent en sub-milliseconde et requièrent PTP/IEEE 1588, pas NTP. Les workloads d'entreprise courants (AD, logs, TLS) tolèrent 10–30 ms de jitter sans impact opérationnel.

3. Les causes d'un jitter élevé

Quatre causes dominantes, par fréquence d'occurrence :

Bufferbloat sur l'uplink. Un uplink saturé met les sondes UDP sortantes en file derrière le trafic TCP en masse, gonflant et randomisant leur instant de départ. Confirmez avec flent rrul ou waveform bufferbloat.
Retransmissions Wi-Fi. Une trame Wi-Fi perdue est retransmise au niveau MAC, ajoutant 5–20 ms par retry. Le jitter augmente avec la contention du canal et la distance à l'AP.
Serveur NTP surchargé. Un Stratum 1 gérant 10k+ requêtes/s peut mettre des paquets UDP en file brièvement. Cherchez des pics de jitter corrélés sur plusieurs clients pointant la même source.
Routage asymétrique. NTP suppose une latence aller simple symétrique. Quand les chemins aller et retour diffèrent (fréquent sur les réseaux multi-home), le calcul d'offset hérite de l'asymétrie comme jitter.

4. Mesurer le jitter — CLI et navigateur

Depuis le navigateur (ce site)

Le testeur en direct rééchantillonne la référence Stratum 1 GNSS toutes les 10 secondes. Le jitter est implicite dans la variation de l'offset affiché entre polls successifs — chargez la page et observez la valeur pendant 1–2 minutes.

Linux — chrony

$ chronyc sourcestats -v
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
=======================================================================
ntp.rdem-systems.com       18  10  259   -0.012     0.034      -2ms    0.8ms
pool.ntp.org               16   9  245   +0.005     0.051      +4ms    2.1ms

La colonne Std Dev est l'estimation du jitter pour les mesures d'offset. Cible : sous 2 ms pour un client Stratum 2.

Linux — ntpd classique / ntpsec

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.0.2.1       .GPS.            1 u   21   64  377   14.132   -1.842   0.421

La colonne jitter est en millisecondes. Cible : < 1 ms sur un peer Stratum 1 sélectionné.

Windows

> w32tm /query /status
Root Dispersion: 0.0156257s
Source: ntp.rdem-systems.com,0x8
Poll Interval: 10 (1024s)

Windows n'expose pas le jitter par source directement ; Root Dispersion est une borne supérieure conservatrice du jitter combiné sur l'arbre de synchronisation.

5. Réduire un jitter élevé

Fixez-vous sur une source plus proche. Remplacez les serveurs pool lointains par un Stratum 2 régional, ou exécutez votre propre Stratum 2 interne proche des clients.
Activez SQM sur le routeur. Smart Queue Management (fq_codel, cake) élimine le bufferbloat en une configuration.
Préférez le filaire au Wi-Fi sur les serveurs. Le jitter Wi-Fi est physique et non configurable.
Augmentez l'intervalle de poll. Contre-intuitif mais efficace : moins de polls laisse au filtre kernel le temps de moyenner le bruit. Passez minpoll de 6 à 8 sur les clients NTP avec amont stable.
Utilisez plusieurs sources. Trois à cinq sources permettent à l'algorithme d'intersection de chrony d'écarter l'outlier bruité et de garder l'horloge verrouillée sur la majorité plus calme.

6. Jitter, offset, drift — les différences

Métrique	Ce qu'elle mesure	Unité	Valeur typique
Offset	Différence entre horloge locale et temps de référence	ms ou µs	< 100 ms excellent
Jitter	Variabilité des mesures d'offset successives	ms	< 1 ms sur LAN
Drift	Vitesse à laquelle l'horloge locale prend du retard	ppm	±10 ppm quartz typique
Délai / RTD	Temps aller-retour vers la source	ms	< 50 ms continental

Une horloge stable présente un jitter faible, un drift faible, un offset faible. Le diagnostic commence par isoler laquelle des trois est dégradée : voir le guide offset en direct et le benchmark de latence.

Lancer le Testeur de Jitter en Direct →