Greyware Automation Products, Inc.
Greyware Automation Products, Inc.   
     Home    Products    Store    Downloads    Customer Service    Site Search    
Log in  or   Create an account now -- FREE!        
Kb > Determining TAI-UTC Offset options

KB2021.328
Determining TAI-UTC Offset options

This article applies to Domain Time II.

Last Updated: 28 Mar 2021

The PTP IEEE-1588/2019 specification requires that master clocks indicate what timescale to use when interpreting timestamps. Timestamps are provided in TAI (International Atomic Time). UTC (Coordinated Universal Time) is based on TAI, but offset by the current number of leap seconds needed to compensate for changes in the Earth's rotational speed. PTP uses the Announce packet to indicate whether the time is using the PTP timescale (ptpTimescale), and if so, what offset to use to calculate UTC time and if that offset is valid. Unfortunatly, PTP masters often vary in their implementation of these settings.

Announce timescale options
If the Announce packet are marked as PTP timescale, this normally means that timestamps will be in TAI, and an offset must be subtracted to derive UTC. For example, as of March 2021, TAI is ahead of UTC by 37 seconds. This number changes with each new leap second.

If the Announce packets are marked as ARB timescale, by convention only, this means timestamps are in UTC. 1588 provides no meaning for any setting other than the PTP timescale with TAI-UTC offset information included. Any timescale at all is possible, with no setting in 1588 to tell you which. An Announce that advertises the ARBitrary timescale must be sending UTC timestamps, else your clock will be wrong. In this case, no UTC offset should be applied.

UTC Offset variables
The Announce packet has two other variables, a flag "currentUtcOffsetValid" (sometimes called "utcOffsetReasonable"), and a 16-bit signed integer, currentUtcOffset. If an Announce says it is using the ptpTimescale, but either the currentUtcOffsetValid flag is false, or if the currentUtcOffset value is zero, then the timestamps are presumed to be UTC instead of TAI.

It is possible to configure a master to serve TAI timestamps, but not set the corresponding flags to provide TAI-UTC offset information. This type of configuration is forbidden by 1588-2008 and 1588-2019. The only way to obtain the correct time of day from such a master is for the slave to know and apply the missing TAI-UTC offset information, which is outside the scope of 1588, and considered a misconfiguration of the master.

Overriding incorrect or missing offset information
DTClient (Windows), DTServer (Windows), and DTLinux (Linux) allow you to override the (or provide the missing) currentUtcOffset value.

On Windows, you must set two registry values found in the HKEY_LOCAL_MACHINE\SOFTWARE\Greyware\Domain Time Server\Time Sources\PTPv2 (IEEE 1588) key:

    TAI-UTC Offset Discovered (seconds)
    TAI-UTC Offset Locked

On Linux, you must change ptp:utcOffsetOverride setting in dtlinux.conf.

These settings allow you to compensate for a misconfigured master that sends TAI timestamps without also providing the TAI-UTC offset (or old hardware that provides the wrong TAI-UTC offset). If an override is provided, Domain Time will use it, and treat timestamps as TAI. If an override is not provided, Domain Time will use the Announce packet's information to determine if the timestamps are TAI or UTC.

Other possible master configurations
Many grandmasters set the ptpTimescale and currentUtcOffsetValid flags to true, but set the currentUtcOffset value to zero (or just set the currentUtcOffsetValid flag to false, regardless of the currentUtcOffset value). This is equivalent to announcing that it is not using ptpTimescale, and the only possible interpretation of the timestamps is UTC. In this case, you should set Domain Time to set the TAI-UTC offset to zero.

Some masters allow either the currentUtcOffsetValid flag to be false, or the currentUtcOffset value to be zero. This violates the 1588 standard, but convention says it means the timestamps are in UTC, and that the TAI-UTC offset does not apply. If the master is actually sending TAI timestamps, you must use the override procedure, else your clock will be wrong by the current TAI-UTC offset value. In this case, you should set Domain Time to use the current correct TAI-UTC offset.

My Account  |   Contact Us  |   Privacy Policy  |   Printer-Friendly Version
 
Copyright © 1995-2021 Greyware Automation Products, Inc.  All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.