I'm experimenting with PTPd on several embedded Linux platforms. I've cross-compiled with debugging enabled. On my ARM9-based system, it works fine and I get synchronization within 20ns or so. While PTPd runs, it shows:
On my old PPC-based system with a 2.4 kernel, I have to use unicast but I can get synchronization within 100ns or so with similar output. But on my modern PPC system with a 2.6.23 kernel, I see startup messages then:
(ptpd debug) initClock
(ptpd debug) Q = 0, R = 5
(ptpd debug) Q = 0, R = 5
(ptpd debug) Q = 0, R = 29
(ptpd debug) Q = 0, R = 28
(ptpd debug) Q = 0, R = 17
(ptpd debug) Q = 0, R = 9
I had trouble getting the packets to show up and be handled and during those failures, I saw timeouts. I think that the Q/R messages indicate that the packets are being handled but I don't understand why I'm not seeing the offset/drift messages that seem to indicate it's doing something with the data to set the clock.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm experimenting with PTPd on several embedded Linux platforms. I've cross-compiled with debugging enabled. On my ARM9-based system, it works fine and I get synchronization within 20ns or so. While PTPd runs, it shows:
(ptpd debug) offset from master: 0s 81082ns
(ptpd debug) observed drift: -17162
(ptpd debug) offset from master: 0s 78582ns
(ptpd debug) observed drift: -17084
(ptpd debug) offset from master: 0s 79082ns
(ptpd debug) observed drift: -17005
On my old PPC-based system with a 2.4 kernel, I have to use unicast but I can get synchronization within 100ns or so with similar output. But on my modern PPC system with a 2.6.23 kernel, I see startup messages then:
(ptpd debug) initClock
(ptpd debug) Q = 0, R = 5
(ptpd debug) Q = 0, R = 5
(ptpd debug) Q = 0, R = 29
(ptpd debug) Q = 0, R = 28
(ptpd debug) Q = 0, R = 17
(ptpd debug) Q = 0, R = 9
I had trouble getting the packets to show up and be handled and during those failures, I saw timeouts. I think that the Q/R messages indicate that the packets are being handled but I don't understand why I'm not seeing the offset/drift messages that seem to indicate it's doing something with the data to set the clock.