On the Hazards of 34 Years
The NTP timestamp format represents seconds and fraction as a 64-bit unsigned fixed-point integer with decimal point to the left of bit 32 numbered from the left. The 32-bit seconds field spans about 136 years, while the 32-bit fraction field precision is about 232 picoseconds. The various arithmetic operations on timestamps are carefully constructed to avoid overflow while preserving precision. This page considers important issues in these operations.
As in the protocol specification, let T1 be the client timestamp on the request message, T2 the server timestamp upon arrival, T3 the server timestamp on departure of the reply message and T4 the client timestamp upon arrival. NTP calculates the clock offset
offset = [(T2 - T1) + (T3 - T4)] / 2
and roundtrip delay
delay = (T4 - T1) - (T3 - T2).
Current implementations of the Unix system clock and NTP daemon operate with 64-bit timestamps. The various arithmetic operations on timestamps are carefully constructed to avoid overflow while preserving precision. The only arithmetic operation permitted on raw timestamps is subtraction, which produces signed 64-bit timestamp differences from 68 years in the past to 68 years in the future. The offset and delay calculations involve addition and subtraction of timestamp differences. To avoid overflow in these calculations, timestamp differences must not exceed from 34 years in the past to 34 years in the future. This is a fundamental limit in 64-bit integer calculations.
In the NTPv4 reference implementation all calculations involving offset and delay values are done in floating-double arithmetic, with the exception of raw timestamp subtraction, which is done in 64-bit integer to preserve precision. The timestamp differences are then converted to 64-bit floating-double format without loss of precision or chance of overflow in subsequent calculations.
While this change may benefit present and future NTP versions, it will not of course benefit previous versions that may be etched in hardware or firmware. Previous versions of the public NTP software, including NTP Version 3 (xntpd) will have the same problem, but these versions use integer arithmetic throughout and are much harder to update. NTP Version 3 has in addition well known ambiguities due to 16-bit overflows in some cases and is not recommended for new systems. However, it is important to note that Simple Network Time Protocol (SNTP) clients that set the clock directly and do not include the offset and delay calculations on this page do not have the 34-year overflow problem and can continue to be used without hazard, at least until 2036.
On the Hazards of Getting Really Fast
The oscillator used to interpolate between ticks in modern processors has a typical resolution of a few nanoseconds, while the time to read the clock from an application program is in the order of a few hundred nanoseconds. In these cases the application cannot read the clock more than once between increments of the oscillator and thus cannot accumulate errors as described above. However, if the oscillator resolution dips to the picosecond range and the clock can be read more than once during a nanosecond, a runaway scenario is possible. When such scenarios become possible, it will be necessary to retool the system clock from the nanoseconds of today to the picoseconds of tomorrow.
