Offset NTP en Direct
Mesure et interprétation du décalage d'horloge — comprenez la valeur en temps réel
1. Ce que mesure l'offset NTP en direct
L'offset NTP est la différence signée entre votre horloge système locale et une source temporelle de référence à l'instant de la mesure. C'est le nombre le plus important en synchronisation temporelle : il dit de combien et dans quelle direction votre horloge est fausse.
Une mesure d'offset « en direct » signifie que la valeur se rafraîchit en continu sous vos yeux. Sur le testeur de la page d'accueil, l'offset se rafraîchit toutes les 10 secondes, vous montrant à la fois l'erreur courante et son évolution entre resyncs.
2. Positif vs négatif — convention de signe
La convention NTP (utilisée par chrony, ntpq, w32tm et ce testeur) :
| Signe | Signification | Correction NTP appliquée |
|---|---|---|
+150 ms | Horloge locale en avance de 150 ms sur la référence | Ralentir l'horloge (step négatif de fréquence) |
-75 ms | Horloge locale en retard de 75 ms | Accélérer l'horloge (step positif de fréquence) |
0 ms | Parfaitement synchronisée à cet instant | Maintenir la fréquence |
Intuition : le signe de l'offset est l'opposé de la correction que NTP doit appliquer. Si vous lisez +150 ms, NTP va vous ralentir de 150 ms pour revenir à zéro.
3. Offset acceptable par usage
| Usage | Offset acceptable | Seuil de casse |
|---|---|---|
| Poste bureautique / mail / web | < 1 s | Certificats TLS (> ~5 min d'écart) |
| Active Directory / Kerberos | < 5 s par défaut | Échec d'authentification à 5 min d'écart |
| Validation certificats TLS / HTTPS | < 5 min | Erreurs de certificat, échec OCSP |
| Corrélation de logs / SIEM | < 100 ms | Inversion de causalité entre services |
| Trading financier (MiFID II RTS 25) | < 1 ms en HFT, < 100 µs en colocation | Non-conformité réglementaire |
| Télécom 5G / qualité PTP | < 100 ns | Synchronisation requiert PTP, pas NTP |
La plupart des applications vivent confortablement sous 100 ms d'offset — zone verte du testeur. Au-delà d'1 seconde, NTP est effectivement cassé ou absent.
4. Comment le navigateur mesure l'offset (méthode HTTPS)
NTP fonctionne normalement sur UDP port 123 que les navigateurs ne peuvent pas émettre. Notre testeur utilise une approximation HTTPS :
- Enregistrer l'horodatage local
t1juste avant l'envoi de la requête HTTPS. - Le serveur retourne son horodatage de référence
t_server(précision microseconde, depuis une source Stratum 1 GNSS). - Enregistrer l'horodatage local
t2à la réception. - Estimer la latence aller simple comme
(t2 - t1) / 2— l'hypothèse que NTP lui-même utilise. - Calculer l'offset :
offset = ((t1 + t2) / 2) - t_server.
Cette méthode reproduit l'algorithme à quatre timestamps classique de NTP adapté au modèle requête/réponse HTTPS. La précision est limitée par la symétrie du chemin TCP/TLS — typiquement ±10–30 ms sur une bonne connexion, contre ±1 ms pour NTP UDP natif.
5. Interpréter un offset qui dérive
Observez l'offset sur le testeur d'accueil pendant 2 minutes. Vous devriez voir l'un de ces motifs :
- Plat proche de zéro (±5 ms d'oscillation) : NTP fonctionne et est synchronisé. Sain.
- Dérive monotone lente (ex. +2 ms toutes les 10 s) : NTP est OFF ou en pause. Le quartz local dérive sans opposition. Réactivez
chronyd/systemd-timesyncd/w32time. - Motif en dents de scie (saut à zéro puis dérive vers le haut) : NTP tourne avec un intervalle de poll long. Chaque « saut » est une correction par palier. Normal pour
minpoll 10ou plus. - Sauts aléatoires de 50–500 ms : jitter élevé du chemin réseau. Voir l'analyse du jitter.
- Offset élevé constant (ex. +3600000 ms) : Décalage de fuseau horaire, PAS un problème NTP. Vérifiez la configuration TZ.
6. Offset élevé ou instable — étapes suivantes
Si le testeur reporte un offset au-delà d'1 seconde ou très instable :
- Vérifiez le statut du service NTP.
systemctl status chrony(Linux),w32tm /query /status(Windows). S'il n'est pas actif, démarrez-le. - Vérifiez les blocages firewall sur UDP 123. Pour les problèmes de port 123 et de démon, utilisez check-ntp.net — le site de diagnostic NTP dédié.
- Vérifiez au moins 4 sources configurées. Moins de 3 sources actives empêche NTP de détecter un false ticker.
- Regardez aussi le délai aller-retour. Un offset élevé avec un RTD élevé indique souvent une source lointaine ou congestionnée — voir le benchmark de latence.
- Workload réglementé ? Pour preuve de conformité NIS 2 / ISO 27001 / DORA, online-ntp-validator.com produit des rapports prêts pour l'audit.
- Voir un audit réel. Cas client : dérive de 4,2 s ramenée sous 50 ms sur 12 serveurs.
Au-delà de l'offset ? 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