NTP and Time Sync Explained: Stratum, Offset and Why Logs Need the Right Time (Network+)
What you’ll know
How the Network Time Protocol keeps clocks in step, what stratum, offset and jitter mean, what NTS and PTP add, and why wrong time breaks logins and investigations. Then check how far off your own computers are.
Why it matters. Time sounds boring until it’s wrong. Kerberos (Windows domain logins) refuses tickets when clocks differ by more than five minutes by default, certificates look “not yet valid” or expired, and log timelines from different servers stop lining up. Network+ lists NTP, PTP and NTS as network services you need to know.
The words you need
| Term | Plain meaning |
|---|---|
| NTP | Network Time Protocol, on UDP port 123. Clients ask time servers and slowly correct their clocks. |
| Stratum | How many steps from a reference clock. Stratum 0 is the reference itself (atomic clock, GPS); stratum 1 servers are wired to one; stratum 2 learns from stratum 1, and so on. Lower is closer to the source, not “better quality” by itself. |
| Offset | How far your clock is from the server’s right now. |
| Delay and jitter | Round-trip time to the server, and how much that time varies. NTP allows for both. |
| NTS | Network Time Security: authenticates NTP answers so an attacker can’t feed you a false time. |
| PTP | Precision Time Protocol (IEEE 1588): sub-microsecond accuracy using hardware timestamps, for trading, telecom and industrial networks. |
Every incident report starts with “at 2:14 AM”. Whose 2:14? If the firewall is four minutes fast, the attacker technically arrived before they broke in. — Nyx
Try it 1: Linux (Ubuntu or WSL)
$ timedatectl Universal time: Sun 2026-11-01 17:38:22 UTC Time zone: America/New_York (EST, -0500) System clock synchronized: yes NTP service: active
System clock synchronized: yes plus NTP service: active is what you want. Servers should log in UTC or with the offset shown, so timelines from different time zones line up.
$ timedatectl timesync-status Server: 185.125.190.57 (ntp.ubuntu.com) Stratum: 2 Offset: -2.103582s Delay: 104.714ms Jitter: 795.079ms
Our WSL clock was about 2.1 seconds off and syncing from ntp.ubuntu.com, a stratum 2 server. The high jitter is normal right after a sync starts. On machines using chrony instead, run chronyc tracking.
Try it 2: Windows
PS> w32tm /stripchart /computer:time.windows.com /samples:3 /dataonly Tracking time.windows.com [40.119.6.228:123]. 12:39:24, -01.3221281s 12:39:26, -01.3263695s 12:39:28, -01.3261812s
This asks time.windows.com three times and prints the difference from your PC’s clock: ours was about 1.3 seconds out. Note the :123, the NTP port. w32tm /query /status shows the full sync status, but on many home PCs the Windows Time service only starts when it’s needed, so that command may say the service isn’t running.
Troubleshooting time problems
- Users suddenly can’t log in to a Windows domain from one PC: check its clock against the domain controller (five-minute Kerberos limit).
- “Certificate not yet valid” on a fresh device: its clock is in the past (common after a dead CMOS battery).
- NTP not syncing at all: a firewall blocking UDP 123 outbound.
- Logs that don’t line up during an investigation: check every device’s time source and time zone first.
Where this fits
This is part of the free Network+ roadmap: every hands-on networking lesson on StashGrid, in order, tagged by exam domain.
NextSyslog and SNMP monitoring lab→
Go deeper
- Troubleshooting capstone — fix five broken networks
- Common ports cheat sheet — UDP 123 and friends
- Linux log triage — why timestamps matter in practice
Explainer, written by StashGrid with AI help and checked against the CompTIA Network+ (N10-009) exam objectives before publishing. Every command was run in Ubuntu 24.04 (WSL2) and Windows 11 on 1 Nov 2026, and the output shown is what we got. StashGrid isn’t affiliated with CompTIA. Spotted an error? Tell us.