I am seeing a problem that I hope I can get some help with. I am using two
embedded boards, each has a HW capable Ethernet port. I connected the two
ethernet ports to each other and configured one board to be the PTP master and
the other PTP slave. I am seeing very large master offset values on the slave
even after letting the boards run for a while.
This is what I see on the master from ptp4l:
Jul 30 16:12:03 imx6sxsabresd sapling_startup.sh[255]: ptp4l[20.331]: selected
/dev/ptp0 as PTP clock
Jul 30 16:12:03 imx6sxsabresd sapling_startup.sh[255]: ptp4l[20.335]: port 1:
INITIALIZING to LISTENING on INIT_COMPLETE
Jul 30 16:12:03 imx6sxsabresd sapling_startup.sh[255]: ptp4l[20.336]: port 0:
INITIALIZING to LISTENING on INIT_COMPLETE
Jul 30 16:12:10 imx6sxsabresd sapling_startup.sh[255]: ptp4l[27.867]: port 1:
LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
Jul 30 16:12:10 imx6sxsabresd sapling_startup.sh[255]: ptp4l[27.867]: selected
local clock 00049f.fffe.038698 as best master
Jul 30 16:12:10 imx6sxsabresd sapling_startup.sh[255]: ptp4l[27.867]: assuming
the grand master role
Some data that I printed using pmc command on the master board:
00049f.fffe.038698-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET
stepsRemoved 0
offsetFromMaster 0.0
meanPathDelay 0.0
00049f.fffe.038698-1 seq 1 RESPONSE MANAGEMENT PORT_DATA_SET
portIdentity 00049f.fffe.038698-1
portState MASTER
logMinDelayReqInterval 0
peerMeanPathDelay 0
logAnnounceInterval 1
announceReceiptTimeout 3
logSyncInterval 0
delayMechanism 1
logMinPdelayReqInterval 0
versionNumber 2
00049f.fffe.038698-0 seq 2 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 0
ingress_time 0
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent false
gmIdentity 00049f.fffe.038698
On the slave I am seeing a large master offset, even though everything else
looks OK:
Jul 30 17:13:36 imx6sxsabresd sapling_startup.sh[268]: ptp4l[19.923]: selected
/dev/ptp0 as PTP clock
Jul 30 17:13:36 imx6sxsabresd sapling_startup.sh[268]: ptp4l[19.927]: port 1:
INITIALIZING to LISTENING on INIT_COMPLETE
Jul 30 17:13:36 imx6sxsabresd sapling_startup.sh[268]: ptp4l[19.930]: port 0:
INITIALIZING to LISTENING on INIT_COMPLETE
Jul 30 17:13:37 imx6sxsabresd sapling_startup.sh[268]: ptp4l[20.546]: port 1:
new foreign master 00049f.fffe.038698-1
Jul 30 17:13:41 imx6sxsabresd sapling_startup.sh[268]: ptp4l[24.546]: selected
best master clock 00049f.fffe.038698
Jul 30 17:13:41 imx6sxsabresd sapling_startup.sh[268]: ptp4l[24.550]: port 1:
LISTENING to UNCALIBRATED on RS_SLAVE
Jul 30 17:13:45 imx6sxsabresd sapling_startup.sh[268]: ptp4l[28.544]: port 1:
UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
Jul 30 17:13:46 imx6sxsabresd sapling_startup.sh[268]: ptp4l[29.544]: rms
4221736682 max 6188514016 freq +24575999 +/- 14188960 delay -176183455 +/-
21733815
Jul 30 17:13:50 imx6sxsabresd sapling_startup.sh[268]: ptp4l[33.545]: rms
2142047989 max 2789503784 freq +32767999 +/- 0 delay -135155526 +/- 13700476
Jul 30 17:13:54 imx6sxsabresd sapling_startup.sh[268]: ptp4l[37.546]: rms
3986976994 max 4658282454 freq +32767999 +/- 0 delay -105344420 +/- 19861006
Jul 30 17:13:58 imx6sxsabresd sapling_startup.sh[268]: ptp4l[41.547]: rms
5856346420 max 6552477411 freq +32767999 +/- 0 delay -91917207 +/- 5273554
Jul 30 17:13:18 imx6sxsabresd sapling_startup.sh[268]: ptp4l[45.548]: rms
7784743992 max 8502558255 freq +32767999 +/- 0 delay -111694340 +/- 21558642
Jul 30 17:13:22 imx6sxsabresd sapling_startup.sh[268]: ptp4l[49.384]: rms
9730190782 max 10438842210 freq +32767999 +/- 0 delay -168804728 +/- 11088501
>From pmc on the slave board:
00049f.fffe.0385f2-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET
stepsRemoved 1
offsetFromMaster 303972865947.0
meanPathDelay -122070171.0
00049f.fffe.0385f2-1 seq 1 RESPONSE MANAGEMENT PORT_DATA_SET
portIdentity 00049f.fffe.0385f2-1
portState SLAVE
logMinDelayReqInterval 0
peerMeanPathDelay 0
logAnnounceInterval 1
announceReceiptTimeout 3
logSyncInterval 0
delayMechanism 1
logMinPdelayReqInterval 0
versionNumber 2
00049f.fffe.0385f2-0 seq 2 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 303972865947
ingress_time 1596129842254879351
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true
gmIdentity 00049f.fffe.038698
I am using timemaster to start phc2sys, ptp4l and chronyd on the slave board.
This is what I have in timemaster.conf on the slave board:
[timemaster]
ntp_program chronyd
rundir /var/run/timemaster
[ntp_server ntp.ubuntu.com]
[ptp_domain 0]
interfaces eth0
delay 10e-6
[chronyd]
path /usr/sbin/chronyd
options
[chrony.conf]
makestep 1 3
rtcsync
driftfile /var/lib/chrony/drift
[phc2sys]
path /usr/bin/phc2sys
[ptp4l]
path /usr/bin/ptp4l
options
[ptp4l.conf]
twoStepFlag 1
verbose 1
time_stamping hardware
use_syslog 1
logging_level 6
summary_interval 1
I also tried starting phc2sys, ptp4l and chronyd manually (without timemaster)
and saw the same result. Can anyone explain why the master offset would be so
large and how do I go about fixing it?
Thank you,
Irene.
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
