Network Time Protocol (NTP) helps computers synchronize their clocks with time servers. A simple client sends a request, reads the reply, and estimates how far its local clock differs from the server’s. Repeating that process lets a clock move toward agreement over time. section 9.9 section 9.9.2
One request and response produce four timestamps:
- T1: the client sends the request; T2: the server receives it. section 9.9.1
- T3: the server sends its reply; T4: the client receives it. section 9.9.1
The four timestamps let the client estimate both clock offset (θ) and network delay (δ). A large delay makes a reading less reliable: the reply took longer to travel, so the client has less confidence in its comparison. There is no directly accessible, universal “right” time—only readings to compare. section 9.9.1 section 9.9.2
Table 9.2 How to calculate δ and θ in NTP (view table figure)
Use the timestamp formulas to calculate the estimated delay and offset for a round trip. section 9.9.2
A clock at boot
A Raspberry Pi without a battery-backed real-time clock starts with its system clock set to epoch time and uses NTP during boot to find the current time. Without a network connection, that approach cannot supply an accurate timestamp; an added real-time clock is one alternative. section 9.1
A practical client can query several trusted servers rather than rely on one reply. It can favor quicker responses and limit how much any adjustment changes the local clock. NTP also has an always-on mode in which computers continually work toward agreement. section 9.9.2 section 9.9
