Network Time Protocol
Network Time Protocol keeps computer clocks aligned by exchanging timestamps with time servers and estimating network delay. It helps systems agree on time despite clock drift and changing network conditions.
itNetworking | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic - Network Time Protocol
Network Time Protocol, or NTP, is how computers agree on civil time without convening a committee every time a quartz oscillator develops opinions. A computer clock runs from an oscillator that is a little fast or slow. That error accumulates, and soon logs, certificates, jobs, and monitoring systems are telling slightly different stories about the same afternoon.
NTP does not grab a timestamp once and declare victory. It runs a feedback loop. A client asks time servers for measurements, estimates offset, the difference between its clock and a source, and delay, the time spent moving across the network. It rejects bad candidates, combines credible ones, then adjusts its own clock. The important verbs are measure, select, discipline, repeat. Everything else is the paperwork required to make those verbs less alarming.
The servers form a hierarchy. A reference clock supplies a primary server, called stratum 1. Secondary servers follow upstream servers, and clients can follow them in turn. Stratum counts synchronization steps, not moral worth. A lower number on a poor path can be less useful than a higher number backed by stable measurements. Several sources matter because one source cannot disagree with itself, which is a remarkably common limitation of single-source designs.
The surprise is that a reply is evidence, not proof. A server can answer packets while unsynchronized, inconsistent with the other sources, or reached through an unstable path. Basic NTP also does not authenticate the traffic. Network Time Security, or NTS, adds server authentication, packet integrity, replay protection, and request-response binding, but it cannot make a server honest or make network delay disappear. Timing remains a measurement problem with a security problem attached, because apparently one problem was not enough.
Leap seconds add policy rather than magic. NTP can signal a pending leap. Some services smear it by changing clock rate around the event. Mixing smeared and ordinary sources makes a client compare clocks that intentionally disagree, which is a poor basis for calm operations.
Read the Intro for the full architecture and security boundary. Open Slides for the four-timestamp exchange and the source-selection flow. Keep the Cheatsheet nearby when offset, jitter, stratum, root distance, or leap state needs interpretation. The Reference tab leads into the RFCs and implementation material once the mental model has stopped looking like a time-themed escape room.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.rfc-editor.org/info/rfc5905
Supports
- NTPv4 purpose, architecture, modes, hierarchy, associations, and UTC synchronization goal
- Primary and secondary servers, reference clocks, stratum levels, and unsynchronized state
- UDP port 123, polling, packet fields, leap indicator, root delay, and root dispersion
- Four-timestamp client-server exchange and the delay and offset formulas
- Filtering, intersection, clustering, source selection, combining, and clock-discipline behavior
- Clock step, slew, frequency correction, drift, jitter, and path-asymmetry limits
- NTP tolerance of packet loss and the timing problems introduced by reliable retransmission
- https://www.rfc-editor.org/info/rfc8633
Supports
- Operational recommendation for at least four independent and diverse time sources
- Source maintenance, monitoring, public-pool use, control-query restrictions, and leaf-client exposure
- Leap-second handling and prohibition on mixing smeared and non-smeared sources
- Risks in unauthenticated NTP, limits of authentication against delay attacks, and rejection of Autokey
- Ingress and egress filtering, implementation updates, rate response, and large-correction safeguards
- Vendor requirement to use public servers only with permission
- https://www.rfc-editor.org/info/rfc8915
Supports
- NTS architecture for NTP client-server modes
- TLS-based key establishment, cookies, keys, and authenticated NTP extension fields
- Server identity, packet authentication, replay prevention, request-response consistency, and non-amplification goals
- NTS limits for delay attacks and the distinction between authenticated identity and correct time
- https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml
Supports
- Current NTP registries for reference identifiers, extension fields, Kiss-o'-Death codes, and defining RFCs
- https://www.ntppool.org/en/
Supports
- NTP Pool as a DNS-distributed cluster of volunteer time servers
- Public service purpose, operating model, and project ownership
- https://www.ntppool.org/en/use.html
Supports
- Pool zone selection, client use, changing server addresses, and vendor guidance
- https://www.ntp.org/documentation/4.2.8-series/ntpq/
Supports
- Learner use of ntpq to inspect peers, associations, status, packet variables, and system variables
- https://github.com/sindresorhus/awesome
Supports
- Discovery of the Awesome Sysadmin list from the canonical Awesome index
- https://github.com/awesome-foss/awesome-sysadmin#time-servers
Supports
- Curated Time Servers category and inclusion of Chrony, NTPsec, and OpenNTPD
- Category descriptions for NTP, PTP, and Roughtime implementations
- https://chrony-project.org/
Supports
- Chrony as an NTP implementation for system-clock synchronization
- Synchronization from NTP servers and reference clocks
- Operation as an NTPv4 server or peer
- https://chrony-project.org/documentation.html
Supports
- Availability of configuration, daemon, command-line monitoring, installation, examples, and FAQ documentation
- https://docs.ntpsec.org/latest/
Supports
- NTPsec as an RFC 5905 implementation derived from NTP Classic
- Client and server use, configuration manuals, monitoring tools, and standards material
- https://docs.ntpsec.org/latest/ntpsec.html
Supports
- NTPsec security-hardening focus and removal of vulnerable or obsolete legacy features
- https://www.openntpd.org/
Supports
- OpenNTPD as an OpenBSD NTP implementation
- Synchronizing the local clock from remote NTP servers
- Serving the local clock to downstream NTP clients
- https://www.openntpd.org/manual.html
Supports
- OpenNTPD manual pages for daemon operation, configuration, and status queries
- https://www.rfc-editor.org/info/rfc958/
Supports
- RFC 958 publication in September 1985 as the first NTP RFC
- https://www.rfc-editor.org/info/rfc1059/
Supports
- RFC 1059 publication in July 1988 as NTP version 1
- https://www.rfc-editor.org/rfc/rfc1119.pdf
Supports
- RFC 1119 publication in October 1989 as NTP version 2
- https://www.rfc-editor.org/info/rfc1305/
Supports
- RFC 1305 publication in March 1992 as NTP version 3
- https://www.rfc-editor.org/info/rfc2030/
Supports
- RFC 2030 publication in October 1996 as Simple NTP version 4
- https://www.meinbergglobal.com/english/products/ntp-time-server.htm
Supports
- Meinberg LANTIME NTP server products and their reference-clock integration
- https://www.microchip.com/en-us/products/clock-and-timing/systems/enterprise-network-time-servers
Supports
- Microchip enterprise NTP time-server product family and GNSS timing inputs
