I've rather strong suspect that PTPD incorrectly assumes PTP time to be UTC time, while protocol specification explicitly says otherwise. Is it true?
My feeling is based on the fact that, for example, a time taken from getTime() is an internal time and is UTC due to gettimeofday() that is used to obtain it. Then this time is converted to external time by the fromInternalTime() that doesn't take into account UTC-to-PTP time offset (34 seconds currently), effectively leaving the time-scale to be UTC. And that time is output, say, into a SYNC packet. This way, it's UTC time that appears in the SYNC time tag, not PTP time, wrong?
Am I missing something?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've run a few tests with ptpd and ptpd2 and can affirm there are problems because in some cases the UTC offset is not handled correctly. Here's a short summary:
For regular applications the PTP standard requires TAI to be used for the time stamps in the network packets.
Assuming the PC's system time runs on UTC, not TAI, the master has to compute TAI = UTC + utc_offs to compute TAI from its UTC system time, and the slave has to compute UTC = TAI - utc_offs which can then be compared to the slave PC's UTC system time.
You need to keep in mind that on a regular PC the PTP daemon is unable to determine the current UTC offset without additional information. The PTP slave receives the UTC offset from the master via the network protocol, but you need to specify the UTC offset on the command line for the PTP master. However, this does not seem to work as expected:
master: ./ptpd2 -cDth
slave: ./ptpd2 -cDth -g
In this case the master uses the default UTC offset 0, which is defined as a constant. Thus the timestamps sent by the master are all UTC, and also the UTC offset sent in the announce msg is 0. Since the client should compute UTC = TAI - utc_offs which is 0, the client anyway synchronizes the system time correctly.
If you specify the UTC offset on the command line for the master (./ptpd2 -cDth -o 34) then the expected behaviour would be to see this UTC offset in the announce message, time stamps converted from UTC to TAI. However, the announced UTC offset is still 0, and the time stamps are still UTC. So it looks like the -o parameter does not have any effect.
If this master temporarily becomes a slave and *receives* a 34 s UTC offset from a 2nd master, and then switches back to master mode because the 2nd master goes offline, it continues to sent the correct 34 s UTC offset in the announce msg, and sends TAI timestamps in the followup msg. However, the timestamps in the sync msg are still UTC. Since the clients use the time stamp from the followup msg in twostep mode, the v2 client still determines the correct UTC time since the UTC offset is applied to the timestamps.
For ptpd (v1) the behaviour is similar, but not the same. The v1 protocol does not use announce messages, the UTC offset is transmitted in the sync message.
master: ./ptpd -cDt -p
slave: ./ptpd -cDt -g
Without specifying the UTC offset on the command line the timestamps are UTC, and the UTC offset is 0, so the v1 slave also sysnchronizes the UTC system time correctly. However, if you specify the UTC offset on the master's command line (-o 34) the master sends this UTC offset, but the time stamps are still UTC. So the master mode needs to be fixed to send TAI in this case.
Surprisingly the v1 client determines the correct UTC time even though the time stamps are UTC and the UTC offset is not 0, which should yield a wrong result. This lets me assume the UTC offset is not applied to the time stamps by v1 clients.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, what you observe (for ptpd v1) matches my investigation of the sources (I did not look at v2 code). UTC offset is only output to corresponding field of the sync messages and is otherwise unused.
BTW, UTC and TAI times are fundamentally different as UTC gets leap seconds while TAI does not. Taking this into account, it seems that it's impossible to correctly implement PTP master on usual PC as there is no way to get true TAI time when leap second is applies to UTC. Still, better approximation of correct behavior than the current one seems to be possible.
For slaves there should be no problems in fixing the behavior though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I know the difference between UTC and TAI. We are manufacturing PTP grandmasters with built-in GPS receivers which can determine the TAI to UTC offset from the satellite signals.
As you have mentioned correctly, determining the current offset on a standalone master is difficult, but the -o parameter is a good workaround for intervals between leap seconds. In any case this should be handled by both the v1 and v2 daemon correcly in order to ensure interoperability between these programs and PTP devices from other manufacturers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, OK. There should be a bug to track this, but I'm not sure if there should be a new one or the existing one should be reopened: https://sourceforge.net/tracker/?func=detail&aid=2975925&group_id=139814&atid=744632
A new bug would indicate there has been a partial fix before, and reopening the existing bug would make searches on the bug list easier.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everybody.
I've rather strong suspect that PTPD incorrectly assumes PTP time to be UTC time, while protocol specification explicitly says otherwise. Is it true?
My feeling is based on the fact that, for example, a time taken from getTime() is an internal time and is UTC due to gettimeofday() that is used to obtain it. Then this time is converted to external time by the fromInternalTime() that doesn't take into account UTC-to-PTP time offset (34 seconds currently), effectively leaving the time-scale to be UTC. And that time is output, say, into a SYNC packet. This way, it's UTC time that appears in the SYNC time tag, not PTP time, wrong?
Am I missing something?
I've run a few tests with ptpd and ptpd2 and can affirm there are problems because in some cases the UTC offset is not handled correctly. Here's a short summary:
For regular applications the PTP standard requires TAI to be used for the time stamps in the network packets.
Assuming the PC's system time runs on UTC, not TAI, the master has to compute TAI = UTC + utc_offs to compute TAI from its UTC system time, and the slave has to compute UTC = TAI - utc_offs which can then be compared to the slave PC's UTC system time.
You need to keep in mind that on a regular PC the PTP daemon is unable to determine the current UTC offset without additional information. The PTP slave receives the UTC offset from the master via the network protocol, but you need to specify the UTC offset on the command line for the PTP master. However, this does not seem to work as expected:
master: ./ptpd2 -cDth
slave: ./ptpd2 -cDth -g
In this case the master uses the default UTC offset 0, which is defined as a constant. Thus the timestamps sent by the master are all UTC, and also the UTC offset sent in the announce msg is 0. Since the client should compute UTC = TAI - utc_offs which is 0, the client anyway synchronizes the system time correctly.
If you specify the UTC offset on the command line for the master (./ptpd2 -cDth -o 34) then the expected behaviour would be to see this UTC offset in the announce message, time stamps converted from UTC to TAI. However, the announced UTC offset is still 0, and the time stamps are still UTC. So it looks like the -o parameter does not have any effect.
If this master temporarily becomes a slave and *receives* a 34 s UTC offset from a 2nd master, and then switches back to master mode because the 2nd master goes offline, it continues to sent the correct 34 s UTC offset in the announce msg, and sends TAI timestamps in the followup msg. However, the timestamps in the sync msg are still UTC. Since the clients use the time stamp from the followup msg in twostep mode, the v2 client still determines the correct UTC time since the UTC offset is applied to the timestamps.
For ptpd (v1) the behaviour is similar, but not the same. The v1 protocol does not use announce messages, the UTC offset is transmitted in the sync message.
master: ./ptpd -cDt -p
slave: ./ptpd -cDt -g
Without specifying the UTC offset on the command line the timestamps are UTC, and the UTC offset is 0, so the v1 slave also sysnchronizes the UTC system time correctly. However, if you specify the UTC offset on the master's command line (-o 34) the master sends this UTC offset, but the time stamps are still UTC. So the master mode needs to be fixed to send TAI in this case.
Surprisingly the v1 client determines the correct UTC time even though the time stamps are UTC and the UTC offset is not 0, which should yield a wrong result. This lets me assume the UTC offset is not applied to the time stamps by v1 clients.
Aargh, the SF web form has reformatted the whole text into a single paragraph :-((
Yes, what you observe (for ptpd v1) matches my investigation of the sources (I did not look at v2 code). UTC offset is only output to corresponding field of the sync messages and is otherwise unused.
BTW, UTC and TAI times are fundamentally different as UTC gets leap seconds while TAI does not. Taking this into account, it seems that it's impossible to correctly implement PTP master on usual PC as there is no way to get true TAI time when leap second is applies to UTC. Still, better approximation of correct behavior than the current one seems to be possible.
For slaves there should be no problems in fixing the behavior though.
Yes, I know the difference between UTC and TAI. We are manufacturing PTP grandmasters with built-in GPS receivers which can determine the TAI to UTC offset from the satellite signals.
As you have mentioned correctly, determining the current offset on a standalone master is difficult, but the -o parameter is a good workaround for intervals between leap seconds. In any case this should be handled by both the v1 and v2 daemon correcly in order to ensure interoperability between these programs and PTP devices from other manufacturers.
We are from similar camps ;-)
Do you think I should file corresponding bug-report?
Ah, OK. There should be a bug to track this, but I'm not sure if there should be a new one or the existing one should be reopened:
https://sourceforge.net/tracker/?func=detail&aid=2975925&group_id=139814&atid=744632
A new bug would indicate there has been a partial fix before, and reopening the existing bug would make searches on the bug list easier.
I've looked at the bug but don't see how to reopen it :-( Am I missing something, or is it indeed impossible to do?