Dennis Kong
2015-12-10 16:45:05 UTC
Hi:
I have a couple problems using linuxptp with software timestamping as a boundary clock when connected another PTP device on one of the interfaces, is the PTP grandmaster (better clock).
Background:
I have linuxptp version 1.5x running with software timestamping (2-step) and handling multiple network interfaces in an embedded linux environment. When all interfaces are in MASTER port state, the PTP follow-up messages all have preciseorigintimestamp value that matches our linux system time.
a) My linux system time was off by a few hours when I introduced a PTP device with a better clock (class and priority1/2). The BM algorithm does select the other PTP device as the grandmaster, changes that interface port state to UNCALIBRATED and then to SLAVE and updates our system time. The process takes quite a while to complete (40 sec?), one issue is that our system time is lagging about 35 seconds behind the preciseorigintimestamp in the PTP master's follow-up message. All the other interfaces (Master port state) on our switch start sending our updated utc system time (with 35 second lag) in the preciseorigintimestamp of the follow-up messages and the grandmaster identity advertised is that of the better PTP master). Any idea why there is a 35 second difference in the preciseorgintimestamp of our follow-ups compared to the PTP foreign master's? The preciseorigintimestamp in our follow-up messages, seem to use the linux kernel system time for software timestamp.
b) If I introduce a large offset either by changing my linux system time or the PTP master's time (verified that preciseorintimestamp has large offset compared to our UTC/preciseorigintimestamp), linuxptp NEVER updates the system time and hence our preciseorigintimestamp has not sycnhronized to that of the PTP master. There seems to be something fundamentally wrong here with my setup. It appears the ONLY time I can get linuxptp to synchronize our system time to the PTP master is if I restart linuxPTP. No further synchronization seems to be possible afterwards.
c) I compared behaviour with other PTP devices and it appears that their system clock does NOT get synchronized to the UTC time in PTP sync/followup messages. I've read that is usually the case for devices supporting hardware timestamping (separate clock maintained), but for software timestamping, I've read that the linux system time is synchronized by linuxPTP because the timestamp is returned by the socket/kernel when a SYNC message is transmitted, and that timestamp is what is put into the preciseorigintimestamp field in the corresponding follow-up.
Any help or guidance would be appreciated
Best regards
Dennis
I have a couple problems using linuxptp with software timestamping as a boundary clock when connected another PTP device on one of the interfaces, is the PTP grandmaster (better clock).
Background:
I have linuxptp version 1.5x running with software timestamping (2-step) and handling multiple network interfaces in an embedded linux environment. When all interfaces are in MASTER port state, the PTP follow-up messages all have preciseorigintimestamp value that matches our linux system time.
a) My linux system time was off by a few hours when I introduced a PTP device with a better clock (class and priority1/2). The BM algorithm does select the other PTP device as the grandmaster, changes that interface port state to UNCALIBRATED and then to SLAVE and updates our system time. The process takes quite a while to complete (40 sec?), one issue is that our system time is lagging about 35 seconds behind the preciseorigintimestamp in the PTP master's follow-up message. All the other interfaces (Master port state) on our switch start sending our updated utc system time (with 35 second lag) in the preciseorigintimestamp of the follow-up messages and the grandmaster identity advertised is that of the better PTP master). Any idea why there is a 35 second difference in the preciseorgintimestamp of our follow-ups compared to the PTP foreign master's? The preciseorigintimestamp in our follow-up messages, seem to use the linux kernel system time for software timestamp.
b) If I introduce a large offset either by changing my linux system time or the PTP master's time (verified that preciseorintimestamp has large offset compared to our UTC/preciseorigintimestamp), linuxptp NEVER updates the system time and hence our preciseorigintimestamp has not sycnhronized to that of the PTP master. There seems to be something fundamentally wrong here with my setup. It appears the ONLY time I can get linuxptp to synchronize our system time to the PTP master is if I restart linuxPTP. No further synchronization seems to be possible afterwards.
c) I compared behaviour with other PTP devices and it appears that their system clock does NOT get synchronized to the UTC time in PTP sync/followup messages. I've read that is usually the case for devices supporting hardware timestamping (separate clock maintained), but for software timestamping, I've read that the linux system time is synchronized by linuxPTP because the timestamp is returned by the socket/kernel when a SYNC message is transmitted, and that timestamp is what is put into the preciseorigintimestamp field in the corresponding follow-up.
Any help or guidance would be appreciated
Best regards
Dennis