PTP: sync fails on emmc based CM4
vjach opened this issue · comments
Describe the bug
While PTP sync works fine for CM4 lite it does not work for emmc based CM4. I have tried on two such boards and I get the same behavior: there is always an offset of ~-1400000 ns compared to master clock. My guess is that clock frequency adjustment has no effect at all. One can see in the logs that frequency shift gets bigger while timer offset still holds.
Steps to reproduce the behaviour
sudo ptp4l -m -i eth0 -f ./ptp4l.conf -s --tx_timestamp_timeout 200
Device (s)
Raspberry Pi CM4
System
Linux raspberrypi 5.15.76-v8+ #15 SMP PREEMPT Tue Nov 8 22:23:39 CET 2022 aarch64 GNU/Linux
Logs
ptp4l[26.838]: selected /dev/ptp0 as PTP clock
ptp4l[26.892]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[26.893]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[28.676]: port 1: new foreign master 80615f.fffe.0ed38c-1
ptp4l[32.676]: selected best master clock 80615f.fffe.0ed38c
ptp4l[32.677]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[33.676]: master offset -1667942767941861510 s0 freq -0 path delay 440
ptp4l[34.677]: master offset -1667942767941875030 s0 freq -0 path delay 440
ptp4l[35.677]: master offset -1667942767941888556 s0 freq -0 path delay 438
ptp4l[36.679]: master offset -1667942767941902066 s1 freq -13081 path delay 436
ptp4l[37.679]: master offset -1428330 s1 freq -13167 path delay 436
ptp4l[38.679]: master offset -1434140 s1 freq -727829 path delay 438
ptp4l[39.679]: master offset -1434612 s1 freq -1446530 path delay 438
ptp4l[40.679]: master offset -1428308 s1 freq -1807537 path delay 438
ptp4l[41.679]: master offset -1431932 s1 freq -2522417 path delay 438
ptp4l[42.679]: master offset -1329625 s1 freq -3062056 path delay 451
ptp4l[43.679]: master offset -1331457 s1 freq -3551251 path delay 467
ptp4l[44.679]: master offset -1334010 s1 freq -4128951 path delay 468
ptp4l[45.679]: master offset -1328419 s1 freq -4646441 path delay 469
ptp4l[46.680]: master offset -1332811 s1 freq -5179280 path delay 469
ptp4l[47.679]: master offset -1330614 s1 freq -5727096 path delay 472
ptp4l[48.680]: master offset -1330196 s1 freq -6254270 path delay 470
ptp4l[49.680]: master offset -1475516 s1 freq -6794353 path delay 470
ptp4l[50.680]: master offset -1358580 s1 freq -7405449 path delay 470
ptp4l[51.680]: master offset -1356732 s1 freq -7954437 path delay 470
ptp4l[52.680]: master offset -1446028 s1 freq -8471244 path delay 470
ptp4l[53.680]: master offset -1363118 s1 freq -9095966 path delay 472
ptp4l[54.680]: master offset -1364604 s1 freq -9633260 path delay 470
ptp4l[55.680]: master offset -1159068 s1 freq -10163243 path delay 470
ptp4l[56.680]: master offset -1362316 s1 freq -10642558 path delay 470
ptp4l[57.680]: master offset -1367972 s1 freq -11175798 path delay 470
ptp4l[58.680]: master offset -1360579 s1 freq -11786819 path delay 469
ptp4l[59.680]: master offset -1358546 s1 freq -12293369 path delay 468
ptp4l[60.681]: master offset -1364210 s1 freq -12861430 path delay 468
ptp4l[61.681]: master offset -1353034 s1 freq -13422911 path delay 468
ptp4l[62.681]: master offset -1756058 s1 freq -13960098 path delay 468
ptp4l[63.681]: master offset -1355554 s1 freq -14722571 path delay 468
ptp4l[64.681]: master offset -1347754 s1 freq -15274509 path delay 468
ptp4l[65.681]: master offset -1355186 s1 freq -15718608 path delay 468
ptp4l[66.681]: master offset -1370618 s1 freq -16375898 path delay 468
Additional context
Test was done between a desktop system (hw timestamping on) and CM4. I even tested between two CM4s (emmc based) with the same failure as described above.
By using the same procedure and the same kernel I can sync a CM4 Lite phy's clock to a master clock.
The actual reason was in the ptp config: step_threshold=0.00002. Moving it back to 0.0 fixed the issue and therefore is not CM4 specific as I initially stated.
Thank goodness for that - I had no idea why the EMMC version might be different.