[Linuxptp-users] UTC offset

[Petr Kulhavy]

Hello,

I would like to understand how linuxptp applies the UTC/TAI offset and
how to properly configure it.

I have two devices running linuxptp as slaves with the same
configuration, the only difference is that one uses SW timestamping and
the other HW timestamping.
Both report the same GM in `pmc GET TIME_STATUS_NP`, but they have a
different time, approximately the 36 seconds in difference.

Generally I would expect both slaves to behave the same if they have the
same configuration and use the same GM.
What is wrong? What do I have to do in order to make them both have the
same time as the master?

Thanks
Petr

[Miroslav Lichvar]

I have two devices running linuxptp as slaves with the same configuration,
the only difference is that one uses SW timestamping and the other HW
timestamping.
Both report the same GM in `pmc GET TIME_STATUS_NP`, but they have a
different time, approximately the 36 seconds in difference.
Generally I would expect both slaves to behave the same if they have the
same configuration and use the same GM.
What is wrong? What do I have to do in order to make them both have the same
time as the master?

As you observed, the difference is in the timestamping. With HW
timestamping ptp4l keeps the PTP clock in TAI and it's up to phc2sys
to convert it to UTC when it synchronizes the system clock. With SW
timestamping ptp4l synchronizes the system clock, so it must convert
it to UTC.

I guess it would be possible to implement a mode where ptp4l keeps the
PTP clock in UTC. I'm not sure how useful that would be.

[Longworth, Gethyn]

Hi,

We had a similar issue where our time source was sending out ARB time rather than PTP time. The Hardware timestamped node was always out by the TAI / UTC offset (36 seconds at the moment) from the software timestamped node.

When it sends ARB (there is a flag in the PTP packet), it ends up sending the UTC time which appears to get interpreted by the hardware timestamping system as TAI, whereas the software system correctly picks it as UTC. When it sends PTP time, it has to be TAI, so both interpret it correctly.

Once we managed to get the timesource to output PTP time (a Symmetricom source that wouldn't send PTP time unless it has a valid GPS lock) the problem went away.

Cheers,

Gethyn

-----Original Message-----
From: Miroslav Lichvar [mailto:***@redhat.com]
Sent: 14 July 2017 08:05
To: Petr Kulhavy
Cc: linuxptp-***@lists.sourceforge.net
Subject: Re: [Linuxptp-users] UTC offset

Post by Petr Kulhavy
I have two devices running linuxptp as slaves with the same
configuration, the only difference is that one uses SW timestamping
and the other HW timestamping.
Both report the same GM in `pmc GET TIME_STATUS_NP`, but they have a
different time, approximately the 36 seconds in difference.
Generally I would expect both slaves to behave the same if they have
the same configuration and use the same GM.
What is wrong? What do I have to do in order to make them both have
the same time as the master?

As you observed, the difference is in the timestamping. With HW timestamping ptp4l keeps the PTP clock in TAI and it's up to phc2sys to convert it to UTC when it synchronizes the system clock. With SW timestamping ptp4l synchronizes the system clock, so it must convert it to UTC.

I guess it would be possible to implement a mode where ptp4l keeps the PTP clock in UTC. I'm not sure how useful that would be.

--
Miroslav Lichvar

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Linuxptp-users mailing list
Linuxptp-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
The data contained in, or attached to, this e-mail, may contain confidential information. If you have received it in error you should notify the sender immediately by reply e-mail, delete the message from your system and contact [phone] (Security Operations Centre) if you need assistance. Please do not copy it for any purpose, or disclose its contents to any other person.

An e-mail response to this address may be subject to interception or monitoring for operational reasons or for lawful business practices.

(c) 2017 Rolls-Royce plc

Registered office: 62 Buckingham Gate, London SW1E 6AT Company number: 1003142. Registered in England.

[Petr Kulhavy]

Hi,

thank you guys for the explanation.

My master is another ptp4l running device. What you're saying would then
mean that ptp4l in master mode sends its time in UTC. Fair enough.
But it doesn't make much sense if it sends UTC time on one side and
interprets it as TAI on the other side, does it?

Do you have maybe some hints how the master needs to be configured?
I don't need an absolute synchronization, I just need that the few
devices are accurately in sync with each other.

Thanks
Petr

Post by Longworth, Gethyn
Hi,
We had a similar issue where our time source was sending out ARB time rather than PTP time. The Hardware timestamped node was always out by the TAI / UTC offset (36 seconds at the moment) from the software timestamped node.
When it sends ARB (there is a flag in the PTP packet), it ends up sending the UTC time which appears to get interpreted by the hardware timestamping system as TAI, whereas the software system correctly picks it as UTC. When it sends PTP time, it has to be TAI, so both interpret it correctly.
Once we managed to get the timesource to output PTP time (a Symmetricom source that wouldn't send PTP time unless it has a valid GPS lock) the problem went away.
Cheers,
Gethyn
-----Original Message-----
Sent: 14 July 2017 08:05
To: Petr Kulhavy
Subject: Re: [Linuxptp-users] UTC offset

Post by Petr Kulhavy
I have two devices running linuxptp as slaves with the same
configuration, the only difference is that one uses SW timestamping
and the other HW timestamping.
Both report the same GM in `pmc GET TIME_STATUS_NP`, but they have a
different time, approximately the 36 seconds in difference.
Generally I would expect both slaves to behave the same if they have
the same configuration and use the same GM.
What is wrong? What do I have to do in order to make them both have
the same time as the master?

As you observed, the difference is in the timestamping. With HW timestamping ptp4l keeps the PTP clock in TAI and it's up to phc2sys to convert it to UTC when it synchronizes the system clock. With SW timestamping ptp4l synchronizes the system clock, so it must convert it to UTC.
I guess it would be possible to implement a mode where ptp4l keeps the PTP clock in UTC. I'm not sure how useful that would be.
--
Miroslav Lichvar
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Linuxptp-users mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
The data contained in, or attached to, this e-mail, may contain confidential information. If you have received it in error you should notify the sender immediately by reply e-mail, delete the message from your system and contact [phone] (Security Operations Centre) if you need assistance. Please do not copy it for any purpose, or disclose its contents to any other person.
An e-mail response to this address may be subject to interception or monitoring for operational reasons or for lawful business practices.
(c) 2017 Rolls-Royce plc
Registered office: 62 Buckingham Gate, London SW1E 6AT Company number: 1003142. Registered in England.

[Richard Cochran]

Post by Petr Kulhavy
My master is another ptp4l running device. What you're saying would then
mean that ptp4l in master mode sends its time in UTC.

So your setup is this?

1. GM using SW time stamping
2. Slave 1 using SW time stamping
3. Slave 2 using HW time stamping

Can you please post your setting, ie config file and command lines for
both ptp4l and phc2sys on each host?

Also, please post the log files.

Post by Petr Kulhavy
I don't need an absolute synchronization, I just need that the few devices
are accurately in sync with each other.

Putting aside the UTC issue, you will get better results by using HW
time stamping on the master by configuring #3 as GM.

Thanks,
Richard

[Petr Kulhavy]

Hi Richard,

The setup is as you say, with the difference that the GM is already
using HW time stamping:

1. GM using HW time stamping
2. Slave 1 using SW time stamping
3. Slave 2 using HW time stamping

So to recap, the two devices with HW timestamping (GM and slave 2) are
in sync, whereas the SW timestamping slave 1 is about 36 seconds behind.

The master is running:
ptp4l -A -i eth0

The log is:
ptp4l: [423899.781] selected /dev/ptp0 as PTP clock
ptp4l: [423899.790] driver changed our HWTSTAMP options
ptp4l: [423899.791] tx_type 1 not 1
ptp4l: [423899.792] rx_filter 1 not 12
ptp4l: [423899.793] port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l: [423899.794] port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l: [423899.796] port 1: link up
ptp4l: [423907.090] port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l: [423907.091] selected best master clock 00049f.fffe.03fa92
ptp4l: [423907.091] assuming the grand master role

Both slaves are running:
ptp4l -f linuxptp.cfg

The HW-timestamping slave is also running:
/usr/sbin/phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -S 1.0 -O 0

The config contains:
-------------
[global]
slaveOnly 1
delay_mechanism Auto
network_transport UDPv4
#time_stamping hardware # for the HW-timestamping slave
time_stamping software # for the SW-timestamping slave
step_threshold 1.0

# make sure our slave clock is never elected as master
priority1 255
priority2 255

[eth0]
-------------

Log of the SW-timestamping slave is:
ptp4l: [413736.212] port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l: [413736.212] port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l: [413736.212] port 1: link up
ptp4l: [413737.945] port 1: new foreign master 00049f.fffe.03fa92-1
ptp4l: [413741.946] selected best master clock 00049f.fffe.03fa92
ptp4l: [413741.946] running in a temporal vortex
ptp4l: [413741.946] port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l: [413743.946] master offset 1000031308 s0 freq +6617 path
delay 118951
ptp4l: [413744.946] master offset 999987122 s0 freq +6617 path
delay 133867
ptp4l: [413745.947] master offset 999986236 s0 freq +6617 path
delay 133776
ptp4l: [413746.947] master offset 999989484 s0 freq +6617 path
delay 129759
...
ptp4l: [413760.950] master offset 16011 s2 freq +5550 path
delay 126526
ptp4l: [413760.950] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l: [413761.951] master offset 18280 s2 freq +5795 path
delay 126142
ptp4l: [413762.951] master offset 5303 s2 freq +4503 path
delay 126390
...

The log of the HW-timestamping device is:
ptp4l: [248.549] selected /dev/ptp0 as PTP clock
ptp4l: [248.566] driver changed our HWTSTAMP options
ptp4l: [248.569] tx_type 1 not 1
ptp4l: [248.572] rx_filter 1 not 12
ptp4l: [248.572] port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l: [248.573] port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l: [248.575] port 1: link up
ptp4l: [248.633] port 1: new foreign master 00049f.fffe.03fa92-1
ptp4l: [252.633] selected best master clock 00049f.fffe.03fa92
ptp4l: [252.634] running in a temporal vortex
ptp4l: [252.635] port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l: [253.649] master offset -521 s0 freq +2421 path delay
12900
ptp4l: [254.649] master offset -372 s2 freq +2570 path delay
12810
ptp4l: [254.650] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l: [255.650] master offset -463 s2 freq +2107 path delay
12810
ptp4l: [256.650] master offset -492 s2 freq +1939 path delay
12810
ptp4l: [257.650] master offset 127 s2 freq +2410 path delay
12810
ptp4l: [258.650] master offset 119 s2 freq +2441 path delay
12808
ptp4l: [259.651] master offset -81 s2 freq +2276 path delay
12806
...

Thanks for your help!
Petr

Post by Richard Cochran

Post by Petr Kulhavy
My master is another ptp4l running device. What you're saying would then
mean that ptp4l in master mode sends its time in UTC.

So your setup is this?
1. GM using SW time stamping
2. Slave 1 using SW time stamping
3. Slave 2 using HW time stamping
Can you please post your setting, ie config file and command lines for
both ptp4l and phc2sys on each host?
Also, please post the log files.

Post by Petr Kulhavy
I don't need an absolute synchronization, I just need that the few devices
are accurately in sync with each other.

Putting aside the UTC issue, you will get better results by using HW
time stamping on the master by configuring #3 as GM.
Thanks,
Richard

[Richard Cochran]

Post by Petr Kulhavy
1. GM using HW time stamping

Okay, so make sure the master has the correct UTC offset.

[global]
utc_offset 37
or
ptp4l --utc_offset=37

Post by Petr Kulhavy
/usr/sbin/phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -S 1.0 -O 0

With '-O 0' you have set the UTC/TAI offset to zero by hand. That
explains the offset between your two slaves. Instead, use this:

phc2sys -a -r

Post by Petr Kulhavy
ptp4l: [413741.946] running in a temporal vortex
ptp4l: [252.634] running in a temporal vortex

These messages about "temporal vortex" mean that the GM is reporting a
UTC offset that is less than the hard coded default. Probably you are
running an older ptp4l version on the GM than on the slaves. I
recommend running the same version on all the nodes.

Thanks,
Richard

[Petr Kulhavy]

Hi Richard,

thank you for the hints. I have loaded the same version of linuxptp on
all three devices and applied your configuration changes.
Now the situation has changed. The master is in sync with the
SW-timestamping slave and the HW-timestamping slave is 37 seconds behind.
Why is that?

Below the logs:

Master:
-------
ptp4l: [590123.733] selected /dev/ptp0 as PTP clock
ptp4l: [590123.741] driver changed our HWTSTAMP options
ptp4l: [590123.742] tx_type 1 not 1
ptp4l: [590123.742] rx_filter 1 not 12
ptp4l: [590123.743] port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l: [590123.745] port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l: [590123.747] port 1: link up
ptp4l: [590131.661] port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l: [590131.662] selected best master clock 00049f.fffe.03fa92
ptp4l: [590131.662] assuming the grand master role



Slave (HW ts):
--------------
ptp4l: [62558.294] selected /dev/ptp0 as PTP clock
ptp4l: [62558.298] driver changed our HWTSTAMP options
ptp4l: [62558.298] tx_type 1 not 1
ptp4l: [62558.299] rx_filter 1 not 12
ptp4l: [62558.299] port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l: [62558.300] port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l: [62558.301] port 1: link up
ptp4l: [62558.483] port 1: new foreign master 00049f.fffe.03fa92-1
phc2sys: [62558.795] phc offset -36 s2 freq +2008 delay 4666
phc2sys: [62559.795] phc offset -38 s2 freq +1995 delay 4667
phc2sys: [62560.796] phc offset 14 s2 freq +2036 delay 4708
phc2sys: [62561.797] phc offset 10 s2 freq +2036 delay 4709
ptp4l: [62562.484] selected best master clock 00049f.fffe.03fa92
ptp4l: [62562.485] port 1: LISTENING to UNCALIBRATED on RS_SLAVE
phc2sys: [62562.798] phc offset 6 s2 freq +2035 delay 4709
phc2sys: [62563.799] phc offset -33 s2 freq +1998 delay 4708
ptp4l: [62563.931] master offset -190 s0 freq +2024 path
delay 12850
phc2sys: [62564.800] phc offset -16 s2 freq +2005 delay 4666
ptp4l: [62564.931] master offset -135 s2 freq +2079 path
delay 12850
ptp4l: [62564.932] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
phc2sys: [62565.801] phc offset 88 s2 freq +2104 delay 4709


Regards
Petr

Post by Richard Cochran

Post by Petr Kulhavy
1. GM using HW time stamping

Okay, so make sure the master has the correct UTC offset.
[global]
utc_offset 37
or
ptp4l --utc_offset=37

Post by Petr Kulhavy
/usr/sbin/phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -S 1.0 -O 0

With '-O 0' you have set the UTC/TAI offset to zero by hand. That
phc2sys -a -r

Post by Petr Kulhavy
ptp4l: [413741.946] running in a temporal vortex
ptp4l: [252.634] running in a temporal vortex

These messages about "temporal vortex" mean that the GM is reporting a
UTC offset that is less than the hard coded default. Probably you are
running an older ptp4l version on the GM than on the slaves. I
recommend running the same version on all the nodes.
Thanks,
Richard

[Richard Cochran]

Post by Petr Kulhavy
Now the situation has changed. The master is in sync with the
SW-timestamping slave and the HW-timestamping slave is 37 seconds behind.
Why is that?

I guess because your PHC on the GM is set to UTC and not TAI.

Normally, when implementing a GM, you will use a global time reference
like a GPS to discipline the PHC. If you don't have a good reference,
then you can set the PHC to TAI by hand like this.

#
# set phc to clock_realtime (utc)
#
testptp -s

#
# shift phc to tai
#
testptp -t 37

#
# check to see offset
#
testptp -g; date

If you want the PHC on the GM to track the local system time, then you
can run phc2sys on the GM like this.

phc2sys -a -r -r

(Note that -r is repeated.)

HTH,
Richard