Network Time Protocol (NTP)
Every computer has an internal clock, but those clocks naturally drift apart over time like analog watches. NTP is the invisible service that continuously resets all your devices to the correct time by checking in with atomic clocks on the internet. Without it, your server logs would show events out of order, TLS certificates would appear expired before they are, and distributed databases would disagree about which write came first.
Network Time Protocol (NTP), defined in RFC 5905, synchronizes clocks across packet-switched networks to sub-millisecond accuracy on LANs and within tens of milliseconds on the internet. It uses UDP port 123.
Stratum hierarchy:
| Stratum | Description | Example |
|---|---|---|
| 0 | Reference clocks (not on the network) | GPS, atomic clocks, radio |
| 1 | Directly connected to stratum 0 | NIST time servers, time.google.com |
| 2 | Synchronized to stratum 1 | pool.ntp.org servers |
| 3-15 | Each synchronized to the stratum above | Corporate NTP servers |
| 16 | Unsynchronized | Clock in an “unknown” state |
Key timing metrics:
- Offset: difference between the local clock and the NTP server clock
- Delay: round-trip network latency to the server (used to correct for transmission time)
- Jitter: variability in delay measurements; high jitter indicates an unstable path
- Drift: rate at which the local clock gains or loses time relative to UTC
Clock discipline algorithm: NTP does not simply set the clock; it steers it. If offset is small, it slows or speeds the clock frequency (slewing, max 500 ppm). If offset exceeds 128ms (adjustable), it steps the clock immediately. Sudden time jumps break applications that assume monotonic time, so slewing is always preferred.
NTPsec and Chrony: Modern deployments prefer Chrony (default on RHEL/Debian since ~2014) or NTPsec over classic ntpd. Chrony converges faster from cold start and handles intermittent connectivity better. It uses the same NTP wire protocol.
Security: Classic NTP has no authentication, making it vulnerable to spoofed time responses. NTPv4 supports symmetric key authentication (MD5/SHA-1). NTS (Network Time Security, RFC 8915) adds authenticated encryption via TLS and is supported by Cloudflare and Chrony 4.0+.
NTP synchronization status and server configuration
# Check synchronization status (systemd-timesyncd / timedatectl)
$ timedatectl status
Local time: Mon 2026-04-21 10:00:00 UTC
Universal time: Mon 2026-04-21 10:00:00 UTC
RTC time: Mon 2026-04-21 10:00:00
Time zone: UTC
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
# Chrony: detailed synchronization metrics
$ chronyc tracking
Reference ID : D8EF2300 (time.cloudflare.com)
Stratum : 4
Ref time (UTC) : Mon Apr 21 10:00:00 2026
System time : 0.000003451 seconds fast of NTP time
Last offset : +0.000002876 seconds
RMS offset : 0.000004231 seconds
Frequency : -12.344 ppm slow
Residual freq : -0.001 ppm
Skew : 0.042 ppm
Root delay : 0.021345678 seconds
Root dispersion : 0.000876543 seconds
Update interval : 64.2 seconds
Leap status : Normal
# Show current NTP sources and their quality
$ chronyc sources -v
MS Name/IP address Stratum Poll Reach LastRx Last sample
^* time.cloudflare.com 3 6 377 18 +1us[+2us] +/- 11ms
^+ time.google.com 1 6 377 19 -3us[-1us] +/- 8ms# /etc/chrony.conf -- production NTP configuration
# Public pool with NTS (authenticated)
server time.cloudflare.com iburst nts
server ntppool1.time.nl iburst
# Fallback to public pool
pool pool.ntp.org iburst maxsources 4
# Allow LAN clients to use this server as their NTP source
allow 192.168.0.0/16
# Keep drift file to speed up convergence after reboot
driftfile /var/lib/chrony/drift
# Step clock only on first sync if offset > 1s, slew otherwise
makestep 1.0 3Time synchronization is a silent prerequisite for almost everything in a datacenter. TLS certificate validation checks notBefore and notAfter fields against the current clock; a 5-minute drift can cause valid certificates to appear invalid. Kerberos authentication (used in Active Directory) has a maximum 5-minute clock skew tolerance. Log correlation across distributed systems is impossible when servers disagree on the time by even a few seconds. Databases like CockroachDB and Google Spanner use clock uncertainty bounds to determine transaction ordering. In practice, always run Chrony or systemd-timesyncd on every server, point it at at least two reliable upstream sources, and monitor offset and jitter as metrics in your observability stack. A server whose clock is drifting is a server about to cause mysterious failures.