A note on "stratum 1"

Posted on June 5, 2016

Stratum 1, in NTP parlance, refers to a network connected clock connected to a reference clock (termed “stratum-0”). A reference clock is simply a stable frequency standard that drives a counter. Since all oscillators drift (some worse than others), a reference clock usually has some way to compare the long-term rate of its oscillator against a better standard (such as the set of expensive atomic clocks in national standards laboratories that generate TAI/UTC). Also, even the most best oscillator cannot tell an absolute time; what’s colloquially referred to as “an atomic clock” is merely a frequency standard – it can only tell you how many seconds have passed since you turned it on, not an actual time of day. There needs to be some mechanism to get the correct time from some source of reference time to transform a frequency standard into a reference clock.

In the real world, common reference clocks used for NTP stratum 1 servers include GPS receivers, CDMA receivers, and atomic frequency standards. An interesting common factor with all these is that GPS 1 is almost guaranteed to be in the chain of time and frequency transfer. Atomic frequency standards need to obtain a time offset and need to be monitored for quality – this is almost always done with GPS-derived time and frequency data. GPS time standards, similarly, have a crystal oscillator that’s made accurate by keeping it at a constant temperature (by thermostatically heating it at 10°C above the maximum possible ambient temperature). Similarly, a GPS receiver adjusts the crystal’s frequency to keep it in sync with GPS-signal derived frequency information. CDMA reference clocks don’t directly receive GPS – they receive timing information from cell networks – but that timing information itself comes from a GPS-disciplined oscillator somewhere (usually in the cell site or something connected to the cell site).

GPS is a superb method of time and frequency transfer – the GPS signals are constantly monitored against the best frequency standards on Earth. This is, incidentally, why using UTC timestamps in the NTP wire format is ridiculous – all the parameters in the GPS signal are expressed in GPS time (a constant offset from TAI), so a GPS receiver needs to synthesize UTC by adding the UTC offset (also broadcast in the GPS signal), and the NTP server needs to generate the right “leap second flags” in its NTP replies, and to generate a continuous timescale, an NTP client needs to detect when a leap second has happened to avoid misinterpreting the sudden time offset change as an error. Even in the simplest setup there are three tricky conversions of time and leap second information in a time format that cannot appropriately express the semantics of the leap second. It is no surprise that almost every other public Stratum 1 NTP server don’t output correct data during a leap second event. Synthesizing UTC from TAI and the current leap offset in the GPS receiver is a mistake; it’s not an easily reversible operation and deprives everything downstream of the advantages of a continuous timescale and of the current leap offset2. Since most stratum 1 NTP servers depend on GPS timing information it is much easier to keep the TAI timestamps intact and tag them with the current leap offset (straight off the GPS signal) and avoid synthesizing UTC until UTC is actually needed. This lets NTP clients and servers (and the computer systems that run them) have easily have access to timestamps in a timescale free of discontinuities and repeated values3 which is useful not just for time synchronization but for the correctness of lots of software.


  1. Everything said here about GPS applies to other GNSS systems, except for the fact that for some unknown reason GLONASS uses Moscow local time with leap seconds unlike every other GNSS.

  2. leap seconds are nondeterministic

  3. the sign of leap seconds implies repeated UTC values – if they were of the opposite sign (if the Earth was spinning faster and constant-rate clocks needed an extra second to catch up) there would be locked-out/invalid UTC values, which would still be horrible but would at least let us unambigously represent the current UTC time as in integer, which is impossible with how leap seconds currently operate