Possible incorrect calculation of residenceTime in gPTP

[rhornig]

While the gPTP code seems to correctly work and keep the clock in sync, the calculation of residenceTime is not clear.

The time correction value is calculated as the newTime variable by peerSentTimeSync + peerDelay + correctionField + residenceTime. But why residenceTime is added at all?

[haug-den-lucas]

I would argue this implementation is correct in regards to that.
My figure is based here is based on the old implementation which uses the receptionEnded and transmissionEnded timestamps (typically one would use the receptionStarted and transmissionStarted, which I also fixed in my PR #1032 but even then the figure would look similar and I would argue it's correct in both cases)

• preciseOriginTimestamp is the timestamp generated at the master when the SYNC message is generated but transmitted (unaltered) in the FollowUp (orange)
• the residenceTime at the GM is added as the correctionField to the FollowUp (green)
• The syncIngresstimestamp is generated at receptionEnded. The time between syncTxEndTimestamp and syncIngressTimestamp is the peer delay which has been calculated using PDelay_Req and PDelay_Resp messages
• After arrival of the FollowUp at the gPTP module (which can be arbitrary large if any processing delay is added within the node), the sync() function is called and the residenceTimeAtSlave is calculated between this (current) time and the syncIngresstimestamp.

Thus as shown in the figure the newTime equals exactly the preciseOriginTimestamp plus the three colored arrow timespans adding up the correct delay.

[haug-den-lucas]

I think the misunderstanding might be the assumption that the preciseOriginTimestamp is the peerSentTimeSync.
This is not the case, instead the peerSentTimeSync is equal to preciseOriginTimestamp + correctionField which for the slave is an alias of what syncTxEnd is at the GM.

So an alternative for the newTime calculation would be replacing preciseOriginTimestamp+correctionField by peerSentTimeSync.

The residenceTime however is crucial to capture the delay between the Sync and FU as well as any additional process delay at the slave.

[levy]

Thanks for the detailed description @haug-den-lucas !