NTP: Stratum, Clock Discipline, and Why Time Drifts

Introduction¶

A wrong clock breaks TLS (certificate validity), Kerberos (5-minute skew window), TOTP/2FA, log correlation, and database replication. NTP keeps clocks within milliseconds — when it works. Here's how it works and how to fix it when it doesn't.

Concepts¶

• Stratum — distance from a reference clock. Stratum 0 is the hardware source (GPS, atomic clock). A server directly attached to one is stratum 1. A server syncing to a stratum 1 is stratum 2, and so on. Higher stratum is not "worse quality" per se — a well-connected stratum 3 can beat a distant stratum 2 — but stratum 16 means "unsynchronised."
• Offset — how far the local clock is from true time (what NTP corrects).
• Delay / jitter — round-trip time to the server and its variance. High jitter (asymmetric or congested paths) makes the offset estimate noisy.
• NTP uses four timestamps per exchange (T1 send, T2 recv, T3 reply-send, T4 reply-recv) to compute offset and delay while cancelling out symmetric network latency.

Slew vs step¶

• Slew — speed the clock up or down slightly until it catches up. Time never goes backwards, never jumps. Used for small offsets.
• Step — set the clock instantly. Used at startup or for large offsets (default threshold ~1 s in chrony's makestep). A backward step can break applications that assume monotonic wall time — which is why databases and clustered software care about NTP config.

Hands-on (chrony — the modern default)¶

# Sync status
chronyc tracking
#   Reference ID    : A.B.C.D (ntp1.example.com)
#   Stratum         : 3
#   System time     : 0.000042 seconds slow of NTP time
#   Last offset     : -0.000015 seconds
#   Leap status     : Normal

# Which sources, and which is selected (^* = current sync peer)
chronyc sources -v

# Per-source stats: offset, jitter, how many samples
chronyc sourcestats

# Force an immediate correction (e.g. after a big jump)
sudo chronyc makestep

Minimal /etc/chrony/chrony.conf:

pool 2.pool.ntp.org iburst maxsources 4
makestep 1.0 3            # step (not slew) if offset > 1s, but only for first 3 updates
rtcsync                  # keep the hardware clock in sync too
driftfile /var/lib/chrony/chrony.drift

For an internal NTP server, add local stratum 10 (serve time even if it loses upstream sync) and allow 10.0.0.0/8.

systemd-timesyncd (lightweight, client-only)¶

timedatectl show-timesync --all
timedatectl set-ntp true

timesyncd is SNTP — simpler, no server mode, less accurate under jitter, but fine for a laptop or a container host.

Verification and troubleshooting¶

timedatectl                       # "System clock synchronized: yes"?
chronyc ntpdata                   # raw last-exchange numbers
sudo tcpdump -ni any udp port 123

• Leap status : Not synchronised, stratum 16 — no source is usable. UDP 123 blocked outbound (very common in restricted networks — use an internal NTP server), all pool servers unreachable, or every source rejected for high jitter/asymmetry.
• Clock drifts seconds per day — NTP isn't running, or the VM's clock is unstable (host contention, live migration). On VMs, prefer a kvm-clock/ paravirt time source and let the host's NTP be authoritative; chronyc on the guest still helps.
• Big offset, chrony won't fix it — past the makestep limit (only applies to the first N updates). sudo chronyc makestep once, or widen makestep.
• Kerberos "clock skew too great" — offset > 5 minutes on the client or the KDC. chronyc tracking on both.
• TLS "certificate is not yet valid" — clock is behind. Fix time, retry.
• Two servers, times differ by ~1s — one is slewing toward truth from a recent step, or they're syncing to different upstreams with a real offset. chronyc sourcestats shows each source's estimated error.
• chronyc says "506 Cannot talk to daemon" — chronyd not running, or you're not root / not on the command socket (cmdallow).

Related tools and reading¶

• On-site: Port Checker (UDP 123), Super Scanner.
• Related posts: SNMP v2c vs v3 in practice, chrony vs ntpd.