FollowUp message interval

[hhhansen]

It seems that every minute the follow up messages are delayed. I've attached a corresponding wireshark capture. The first delayed packet is number 144.
ptpd2-syncfup-interval.zip

[wowczarek]

Hans,

If you want someone to investigate, you will have to provide more information than this.

FollowUp is sent as soon as PTPd receives its own Sync message. Indeed, in your capture every 60 seconds FollowUp is delayed by the same amount, 61 ms. The reason could be anything, and if the reason is not external to PTPd, it could be some internal housekeeping task taking too long, such as writing to a file or something similar.

Which version are you using - github source?
Is this fully reproducible? Also on other systems or only on your platform?
Does this happen every time, regardless of Sync message interval?
What is your ptpd configuration?
What is the OS you are using?
What is the hardware platform?
Is there much other traffic on the network?
Did you try enabling debug mode?

Thanks,
Wojciech

[hhhansen]

I've used PTPDv2 2.3.0 and it was full reproducible on two different ubuntu systems. Please handle this report only as a hint. Sorry, but I'm not able to give you more informations. The systems aren't longer available.

[wowczarek]

Thanks - are you aware of this actually causing issues? In addition - this should not be happening on systems which use transmit timestamping, because in those cases PTPd always grabs the TX timestamp after sending the Sync, and sends FollowUp immediately after. Same case with hardware timestamping. The delay can only happen if PTPd has to receive its own packets to approximate when they were sent.

If there is no TX timestamping, the process is:

1. Check if we have any packets to handle, handle incoming packets <- here also own Sync is received and FollowUp is sent
2. Check if we have any scheduled packets to send, send them
3. Check if we have any timers expired to run any other tasks, run them <- this may take up some time. This can be writing to log files, a slow write can take some time
4. Goto 1

So as you see, step 4. can cause some delay. Furthermore, timers interrupt the select() call waiting for packets.

I would classify this as a performance issue where Sync transmission co-incides with another task. This can be looked into at some point, for example by using slightly randomised timers.

This is for multicast, one sync for all. Now if you're running unicast and have hundreds of slaves, this gets even more interesting.