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
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
