Testez l'accessibilité, le stratum, l'offset et la précision depuis la ligne de commande
La commande ntpdate -q interroge un serveur NTP sans modifier votre horloge. C'est le moyen le plus rapide de tester si un serveur répond.
| Champ | Bonne valeur | Problème |
|---|---|---|
| stratum | 1–4 | 16 = serveur non synchronisé |
| offset | < 0.1 (100ms) | > 1.0 = dérive significative |
| delay | < 0.2 (200ms) | > 0.5 = latence élevée |
Sur les systèmes modernes, ntpdate n'est pas toujours installé par défaut :
sudo apt install ntpdate (Debian/Ubuntu) ou sudo dnf install ntpdate (RHEL/Fedora)
Si chrony est votre client NTP, utilisez chronyc pour vérifier vos sources configurées :
^* = Source actuellement sélectionnée (meilleure)^+ = Source alternative acceptable^? = Source ne répondant pas ou inutilisableSi vous utilisez des serveurs sécurisés par NTS : chronyc authdata — recherchez Mode: NTS et NAK: 0.
| Symbole | Signification |
|---|---|
* | Source de synchronisation actuelle (pair système) |
+ | Candidat à la sélection |
- | Aberrant, non sélectionné |
x | Désigné comme falseticker (mauvais) |
| (espace) | Rejeté ou inaccessible |
De nombreux serveurs NTP bloquent les requêtes ntpq (mode 6/7) pour prévenir les attaques par amplification. L'absence de réponse à ntpq -p <serveur> ne signifie pas que le serveur est hors service — utilisez ntpdate -q à la place.
La commande sntp effectue une requête NTP simple et fonctionne sur la plupart des systèmes Unix :
Le +0.000234 est l'offset en secondes. s1 confirme le Stratum 1.
Si les outils spécifiques à NTP ne sont pas disponibles, testez la connectivité de base du port UDP 123 :
Un test de port réussi confirme uniquement que le port UDP 123 est accessible. Le serveur peut tout de même répondre avec stratum 16 (non synchronisé) ou REFUSED. Effectuez toujours un test au niveau NTP ensuite (ntpdate -q).
| Métrique | Excellent | Acceptable | Problème |
|---|---|---|---|
| Stratum | 1 | 2–3 | 16 (non synchronisé) |
| Offset | < 1ms | < 100ms | > 500ms |
| Délai | < 10ms | < 100ms | > 500ms |
| Gigue (Jitter) | < 1ms | < 10ms | > 50ms |
| Reach (chrony/ntpd) | 377 (tout OK) | > 177 | 0 (aucune réponse) |
Le Reach est affiché en octal. Chaque bit représente un sondage : 377 octal = 11111111 binaire = les 8 derniers sondages ont tous réussi. Un reach de 17 = 00001111 = seuls les 4 derniers sondages ont réussi (le serveur était inaccessible avant cela).
Causes :
Le serveur fonctionne mais n'a pas de source de temps valide. C'est généralement une condition temporaire — le serveur est peut-être en cours de démarrage ou a perdu la connexion avec ses sources en amont. Attendez et réessayez, ou utilisez un autre serveur.
Certains serveurs filtrent par plage d'adresses IP ou origine géographique. Une réponse REFUSED ne signifie pas que le serveur est en panne — cela signifie que vous n'êtes pas autorisé à l'utiliser. Essayez un serveur public comme ntp-pool.rdem-systems.com ou pool.ntp.org.
Si le délai dépasse 200 ms, le serveur est probablement géographiquement éloigné ou votre chemin réseau est congestionné. Choisissez un serveur plus proche. Si l'offset est élevé mais le délai est faible, le serveur lui-même peut avoir des problèmes de synchronisation.
Exécutez ntpdate -q <serveur>. Cette commande interroge le serveur sans modifier votre horloge et affiche le stratum, l'offset et le délai. Si le délai d'attente est dépassé, le serveur est inaccessible.
Le serveur exécute NTP mais n'est pas synchronisé avec une source de temps. Ne l'utilisez pas comme référence. C'est généralement temporaire.
Pour les serveurs Internet : offset < 100 ms, délai < 200 ms. Sur un LAN : offset < 1 ms, délai < 5 ms. Si l'offset dépasse 500 ms, quelque chose ne va pas.
Le serveur a répondu mais a été rejeté — généralement stratum 16, filtrage IP ou gigue excessive. Essayez un autre serveur ou vérifiez les règles de pare-feu.
Pas d'accès en ligne de commande ? Utilisez nos outils en ligne pour tester des serveurs NTP instantanément :
Tous les outils sont alimentés par l'infrastructure Stratum 1 de RDEM Systems