Test reachability, stratum, offset, and accuracy from the command line
The ntpdate -q command queries an NTP server without modifying your clock. It's the fastest way to test if a server responds.
| Field | Good Value | Problem |
|---|---|---|
| stratum | 1–4 | 16 = server unsynchronized |
| offset | < 0.1 (100ms) | > 1.0 = significant drift |
| delay | < 0.2 (200ms) | > 0.5 = high latency |
On modern systems, ntpdate may not be installed by default:
sudo apt install ntpdate (Debian/Ubuntu) or sudo dnf install ntpdate (RHEL/Fedora)
If chrony is your NTP client, use chronyc to check your configured sources:
^* = Currently selected source (best)^+ = Acceptable alternative source^? = Source not responding or unusableIf using NTS-secured servers: chronyc authdata — look for Mode: NTS and NAK: 0.
| Symbol | Meaning |
|---|---|
* | Current sync source (system peer) |
+ | Candidate for selection |
- | Outlier, not selected |
x | Designated falseticker (bad) |
| (space) | Rejected or unreachable |
Many NTP servers block ntpq queries (mode 6/7) to prevent amplification attacks. Getting no response to ntpq -p <server> does not mean the server is down — use ntpdate -q instead.
The sntp command performs a simple NTP query and works on most Unix systems:
The +0.000234 is the offset in seconds. s1 confirms Stratum 1.
If NTP-specific tools are not available, test basic UDP port 123 connectivity:
A successful port check only confirms UDP 123 is reachable. The server might still respond with stratum 16 (unsynchronized) or REFUSED. Always follow up with an NTP-level test (ntpdate -q).
| Metric | Excellent | Acceptable | Problem |
|---|---|---|---|
| Stratum | 1 | 2–3 | 16 (unsynchronized) |
| Offset | < 1ms | < 100ms | > 500ms |
| Delay | < 10ms | < 100ms | > 500ms |
| Jitter | < 1ms | < 10ms | > 50ms |
| Reach (chrony/ntpd) | 377 (all OK) | > 177 | 0 (no response) |
Reach is displayed in octal. Each bit represents one poll: 377 octal = 11111111 binary = last 8 polls all succeeded. A reach of 17 = 00001111 = only last 4 polls succeeded (server was unreachable before that).
Causes:
The server is running but has no valid time source. This is usually a temporary condition — the server may be starting up or lost connectivity to its upstream sources. Wait and retry, or use a different server.
Some servers filter by IP range or geographic origin. A REFUSED response doesn't mean the server is broken — it means you're not allowed to use it. Try a public server like ntp-pool.rdem-systems.com or pool.ntp.org.
If delay is over 200ms, the server is likely geographically far or your network path has congestion. Choose a closer server. If offset is high but delay is low, the server itself may have sync issues.
Run ntpdate -q <server>. It queries without changing your clock and shows stratum, offset, and delay. If it times out, the server is unreachable.
The server is running NTP but is not synchronized to any time source. Don't use it as a reference. This is usually temporary.
For internet servers: offset < 100ms, delay < 200ms. On LAN: offset < 1ms, delay < 5ms. If offset exceeds 500ms, something is wrong.
The server responded but was rejected — usually stratum 16, IP filtering, or excessive jitter. Try another server or check firewall rules.
Don't have CLI access? Use our online tools to test NTP servers instantly:
All tools powered by RDEM Systems Stratum 1 infrastructure