NTP

Why accurate time matters

Many systems break when clocks are wrong:

• TLS certificates. A certificate that hasn't reached its validity start date or has passed its expiry is rejected. A wildly wrong clock breaks HTTPS, email, signed code.
• Kerberos and other authentication. Tickets have time windows. More than 5 minutes of clock skew breaks Active Directory logins.
• Log analysis. Correlating events across machines requires synchronized timestamps. Wrong clocks make incident investigation impossible.
• Distributed databases. Many use timestamps for conflict resolution. Wrong clocks cause data inconsistency.
• Email delivery. Mail servers reject messages with dates too far in the past or future.
• Financial systems. Trading order timestamps. Regulatory requirements often mandate sub-millisecond accuracy.
• Cryptocurrency. Block timestamps must be within tolerance windows.

How NTP works

An NTP client periodically queries one or more NTP servers and uses statistical analysis of the responses to set its own clock. Each query exchange records four timestamps:

Client                      Server
T1: client send  ────►
                              T2: server receive
                              T3: server send
                  ◄──── T4: client receive

From these four values, the client calculates:

• Round-trip delay: (T4 - T1) - (T3 - T2)
• Clock offset: ((T2 - T1) + (T3 - T4)) / 2

The client takes many samples, filters outliers, and gradually adjusts its clock to minimize offset. NTP discipline algorithms slowly slew the clock rather than jumping — abrupt clock changes cause problems (logs going backwards, scheduled tasks firing twice or not at all).

The stratum hierarchy

NTP sources are organized in strata:

The stratum number is informational; it does not strictly determine accuracy. A stratum 3 server with a good network path can be more accurate than a stratum 2 server on a worse path. Clients query multiple servers and use the statistically best samples.

Public NTP services

For production servers, a common pattern is to point at the NTP Pool plus a major anycast service (Cloudflare or Google) so you have geographic and operational diversity. For embedded devices and IoT, the OS default is usually fine.

The leap second problem

Earth's rotation is not perfectly uniform. The International Earth Rotation and Reference Systems Service (IERS) occasionally inserts a "leap second" into UTC to keep it aligned with solar time. Leap seconds happen every 1-3 years on average.

Leap seconds cause real problems in computing because the clock jumps by 1 second instead of progressing smoothly. The minute 23:59:60 exists on a leap-second day, and not all software handles it correctly. Notable outages have happened around leap seconds.

Modern alternatives:

• Leap smear — major cloud providers (Google, Amazon, Facebook/Meta) spread the leap second over a long window (12-24 hours) so the clock simply runs slightly slower or faster, never having a 23:59:60. Most servers don't see the leap second at all.
• UTC abolition proposals — there's ongoing debate about removing leap seconds entirely after 2035. The current consensus leans toward eliminating them in favor of letting UTC drift slightly from solar time.

NTS — securing NTP

Classic NTP has no authentication; an on-path attacker can manipulate responses to set client clocks to arbitrary values, breaking certificate validation, log forensics, and authentication systems. Network Time Security (NTS, RFC 8915, 2020) adds TLS-based authentication and integrity to NTP exchanges.

NTS deployment is growing but still partial. Cloudflare's time.cloudflare.com supports NTS; some Linux NTP clients (chrony) support it; many devices and OS clients do not. For most users, classic NTP over a trusted network path is acceptable; for high-security environments, NTS is the right choice where available.

Common NTP client implementations

• chrony — modern, low-overhead, well-behaved with intermittent connectivity. Default on most current Linux distributions.
• ntpd — the original reference implementation. Still widely deployed; chrony has largely displaced it on new systems.
• systemd-timesyncd — minimalist SNTP client included in systemd. Simpler than chrony but adequate for most desktop and server uses.
• Windows Time service (w32time) — Microsoft's SNTP client. Synced to time.windows.com by default; managed via Group Policy in domain environments.
• OpenNTPD — minimalist BSD implementation focused on simplicity and security.

Frequently Asked Questions

What port does NTP use?

UDP port 123. NTP runs over UDP because the protocol is loss-tolerant — losing an occasional time sample is fine; what matters is the statistical accuracy across many samples. TCP would add overhead without benefit. Some networks block outbound UDP 123; in those cases, NTP clients need to use a local time source on the network or be exempted in firewall rules.

How accurate is NTP?

Typically 1-50 milliseconds over the internet, sub-millisecond on local networks with low jitter. The accuracy depends on the network path's symmetry, jitter, and the stratum of the time source. For high-precision applications (trading systems, scientific instruments), PTP (Precision Time Protocol, IEEE 1588) achieves microsecond or nanosecond accuracy on LANs with hardware timestamping.

What is an NTP stratum?

Stratum is the distance from an authoritative time source. Stratum 0 is the actual reference clock (atomic clocks, GPS receivers). Stratum 1 servers are directly connected to stratum 0 sources. Stratum 2 servers sync from stratum 1, stratum 3 from stratum 2, and so on up to stratum 15 (16 = unsynchronized). Public NTP pool servers are typically stratum 2 or 3. Lower stratum = closer to the reference, but the practical accuracy difference between stratum 2 and stratum 5 is small over the internet.

Why does my certificate validation fail when my clock is wrong?

TLS certificates have validity periods (notBefore and notAfter dates). If the system clock is significantly off, the device may consider a current certificate as "not yet valid" or "expired." This is why a wildly incorrect system clock (often happens after CMOS battery failure on PCs, or on first boot of devices that have no RTC) breaks HTTPS, email, and most secure protocols. The fix is to set the clock via NTP — but NTP itself may fail if certificate-validating NTP clients refuse to sync due to the wrong clock.