How the Kernel Stays Accurate
A freshly booted Linux machine with no network access will drift. The RTC is accurate to maybe a few seconds per day, and the kernel's software clock accumulates its own small errors. Over weeks, a server with no time synchronization can be minutes off. For distributed systems — where event ordering, TLS certificate validation, and log correlation all depend on accurate time — even a few seconds of drift is catastrophic.
Network Time Protocol (NTP) solves this by continuously comparing the local clock against a hierarchy of reference clocks and making small, gradual corrections.
The Stratum Hierarchy
NTP organizes time sources into layers called strata:
- Stratum 0: Physical reference clocks — GPS receivers, atomic clocks, radio time signals. These are not on the network; they connect directly to Stratum 1 servers.
- Stratum 1: Servers directly connected to Stratum 0 devices. These are the primary time servers (e.g.,
time.google.com,pool.ntp.org). - Stratum 2: Servers that synchronize from Stratum 1. Your corporate NTP server is likely here.
- Stratum 3+: Clients synchronizing from Stratum 2, and so on. Each hop adds a small amount of uncertainty.
Your Linux server is typically a Stratum 3 or 4 client.
Slewing vs. Stepping
NTP uses two correction strategies:
- Slewing: For small offsets (typically < 128ms), NTP adjusts the clock rate slightly — running the clock at 1.0005× or 0.9995× speed until it converges. This is invisible to applications and never causes backward jumps.
- Stepping: For large offsets (> 128ms by default in
ntpd), NTP makes an immediate jump. This is the dangerous case that can trigger the negative-duration bug. Most NTP daemons only step at startup; after that, they slew only.
systemd-timesyncd vs. ntpd vs. chrony
Modern Linux systems use one of three NTP implementations:
| Daemon | Use Case |
|---|---|
systemd-timesyncd |
Simple SNTP client, default on many desktop/server distros. Good enough for most servers. |
ntpd |
Full NTP implementation. More accurate, supports serving time to other hosts. |
chrony |
Preferred for servers that are frequently suspended, VMs, or environments with intermittent network. Converges faster after large offsets. |
Tools like chronyc tracking surface the live discipline state: which reference server the clock is synced to, the stratum of that server, the current offset from NTP time, and a Frequency field (in parts per million, ppm) that tells you how fast or slow your local oscillator runs relative to NTP. A value of 12 ppm slow means your clock loses about 1 second per day without correction — NTP compensates by running the clock slightly faster.