Network Time Protocol

Computer clocks do not stay correct by themselves. Their oscillators run slightly fast or slow. Temperature, hardware, load, and virtualization can change that error. A small difference becomes clock drift as time passes.

Network Time Protocol, or NTP, keeps system clocks aligned with Coordinated Universal Time, or UTC. It exchanges timestamps between clients and servers. The client estimates its clock offset and the network delay. It then lets a clock-discipline algorithm correct the system clock.

That correction matters far beyond the clock display. Logs from different hosts need a shared timeline. Certificates and authentication tokens have validity windows. Distributed jobs, monitoring, backups, billing, and incident response all depend on credible timestamps.

NTP gives you a disciplined estimate of UTC. It does not make a packet network delay-free. It does not prove that every event happened in timestamp order. It also cannot make an untrusted source truthful.

The mental model

Think of NTP as a continuing control loop:

reference clocks
      |
primary time servers
      |
secondary servers
      |
clients
      |
system clocks

measure -> select -> combine -> adjust -> repeat

A reference clock is an external source such as a radio or satellite receiver. A primary server connects directly to a reference clock and operates at stratum 1. A secondary server synchronizes through one or more upstream servers. Its stratum is one greater than the server it follows.

Stratum describes distance in the synchronization hierarchy. It is not a universal quality score. A lower stratum does not guarantee a better result for your client. Network path quality, source stability, and the implementation's measurements still matter.