Re: [Linuxptp-devel] phc2sys, timemaster: stale/bad receive time /w ptp4l using 2 ethernet interfa
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
From: Stefan L. <s....@ga...> - 2017-03-22 11:59:51
|
Hello Richard, I manually corrected the GM properties by setting them on the GM device: pmc -u -b 0 'SET GRANDMASTER_SETTINGS_NP clockClass 248 clockAccuracy 0xfe offsetScaledLogVariance 0xffff currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 1 ptpTimescale 1 timeTraceable 0 frequencyTraceable 0 timeSource 0xa0 ' I restarted ptp4l, phc2sys and ntpd on the slave device and see: root@cp61850:~# pmc -u -b 0 'GET TIME_PROPERTIES_DATA_SET' sending: GET TIME_PROPERTIES_DATA_SET 00d093.fffe.274a5e-0 seq 0 RESPONSE MANAGEMENT TIME_PROPERTIES_DATA_SET currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 1 ptpTimescale 1 timeTraceable 0 frequencyTraceable 0 timeSource 0xa0 However, the message SHM: stale/bad receive time, delay=-37s still persists. Behaviour is as described in the first post. Maybe there is still something wrong with my GM configuration.. Anyway I still can not see why the setup would work with ptp4l using only 1 ethernet interface or phc2sys non-autoconfig, even given there was (or maybe still is) a problem in the GM configuration. For testing I currently have a board identical to the slave device acting as the Grandmaster Clock. This since I do currently not have access to our Meinberg GM clock. eth1 of the GM device is connected to a switch. From the switch, cables go to eth1 and eth2 of the slave device. However, as described, unplugging eth1 or eth2 before or after starting ptp4l has no effect on the presence of this phenomenon. Is there some more diagnosis I can do? Did I misconfigure something on the GM side that can explain the effects seen? Best regards, Stefan |