PTP Timescale (and what the heck is Arb time?)

Five Minute Facts About Packet Timing

By Doug Arnold

Most application which use PTP to distribute time, don’t actually need standard time, as understood by national laboratories.  All that is needed is for the clocks in a network to have the same time.  However, there are several reasons to use a standard timescale when distributing PTP:

1. It can be useful if the network time can easily be converted to human readable standard local time. 
2. If two live networks, that already have a sense of time, are connected together, then it causes less transient chaos if they start with approximately the same time.  It is easier to achieve this if a standard timescale is used.
3. Some government regulations and technology standards specify standard time tied to national labs.

To start with, every timing network should use the standard SI second.  IEEE 1588 doesn’t actually require that, but many parts of the standard nevertheless assume it.  Also not using the SI second makes it very difficult to convert the network time into any kind of standard time.  So don’t even consider putting time into any network which is not based on the SI second. You’re thinking of a corner case where this isn’t needed. Don’t!

The default and recommended timescale of 1588, the PTP Timescale, is your equipment’s best estimate of the international standard timescale TAI.  TAI, or in English, International Atomic Time, is maintained by the French national lab, BIPM.  “Does anybody really know what time it is?”  It turns out the answer is no.  Since TAI is derived in a complicated way from an ensemble of atomic clocks in national laboratories all over the world, the calculations need to create TAI take weeks.  So, scientists only know what time it was a few weeks ago.  Not to worry.  Every national lab maintains a continuous prediction of TAI, which is typically accurate to within a few nanoseconds.  These predictions are compared with each other using techniques such as satellite two-way time transfer, or TWSTT, see Figure 1. 

Figure 1.  TAI:BIPM is compared to TAI:PTB (the German national lab) using two way satellite time transfer.

TWSTT, as it turns out, is a time transfer mechanism similar to PTP and NTP.  Specifically, time is transferred in each direction so that communication delays can be accounted for.  The TAI predictions are available via satellite and radio signals.  For example, GPS time is convertible to the prediction of TAI at the United States Naval Observatory, one of the contributors to TAI.

But isn’t the international standard called Coordinated Universal Time, or UTC?   Yes, but UTC is defined as TAI offset by an integer number of seconds.  The purpose of this UTC offset is to keep UTC close to astronomically time, which is determined by the position of the stars in the sky.  To achieve this the UTC offset is periodically update by inserting a leap second.  Like all of us, the Earth slows down over time.  Atomic clocks, however, do not. So, leap seconds are added every six months or year, or two years or so.  If the Earth ever speeds up, a second can be taken away from the UTC offset, but this has never happened.  Apparently, the astronomers have a lot of pull with the scientists at national labs to add the complication of leap seconds to international standard time. 

Leaps seconds are notorious for causing technical problems in applications which use time.  For this reason PTP uses TAI in the timestamps which appear in PTP messages.  The UTC offset is also distributed in case UTC is needed in the application.  Note that local time is always derived from UTC, by shifting UTC for the time zone offset.  So if the application needs local time, then it first needs UTC. The UTC offset is available from PTP ports in the master state as a field in the Announce message, see Figure 2.

Figure 2.  Structure of the PTP announce message

Additional information about UTC is available in the flag field of the PTP common header on all PTP messages, see Figure 3.

Figure 3. Flags in the PTP message common header.

OK, so what is Arb time?  The wise and mighty 1588 working group anticipated that some applications, for example in a small network, might not want to go through the trouble of using GPS receiver or some other means of getting TAI, so it is allowed that the timescale can be arbitrary (know by its friends as simply “Arb”).  If the grandmaster of the network is putting out Arb time, then PTP slaves should not make any assumptions about the relationship between the network time and any standard timescale.

If you have any questions about packet timing, don’t hesitate to send me an email at doug.arnold@meinberg.de or visit our website at www.meinbergglobal.com.