Re: [Linuxptp-users] ptp4l : rms values on slave consistently greater than 10000000 ns

[Vladimir O. <ol...@gm...>]

On Sat, Nov 27, 2021 at 10:42:27AM +0530, Raj kishore Chhatoi wrote:
> Hi Team,
> 
> We are using linuxptp-3.1 version.We are running ptp4l with Primary
> configuration on a DUT and running ptp4l with salve configuration in
> another DUT. Both Primary and slaves are connecetd via Radmoon Media
> converter.
> 
> We observed that Primary board is successfully sending sync(in every 125
> ms),Follow up message,PDelayResp,PdelayRespFollowUp..etc and slave also
> sending Peer_Dealy_Req_message  and is recived by Primary DUT. The Primary
> Board system time  is also successfully updating in Slave board, however we
> observed that "rms" vlues in the slave board is >10000000 consistently.
> 
> When we analyzed the sync packet we found that "LogMessagePeriod: -3" .
> 
> Could you please let us know in which scenario/case the "LogMessagePeriod:
> -3" is getting updated in sync packet ?

-3 means 2 to the power of -3 seconds which means 1/8 = 125 ms. It is
the interval between Sync packets. You've mentioned this interval
yourself, it is typical for the automotive profile of 802.1AS.
Is that your question?

> 
> Note : we are running "phc2sys -s eth0 -c CLOCK_REALTIME
> --step_threshold=1" in slave board
> 
> Logs:
> root:~# ./ptp4l -i eth0 -f automotive-slave.cfg -m
> ptp4l[291.097]: selected /dev/ptp0 as PTP clock
> ptp4l[291.170]: port 1: INITIALIZING to SLAVE on INIT_COMPLETE
> ptp4l[291.171]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[292.108]: port 1: new foreign master 0022a0.fffe.000106-1
> ptp4l[293.030]: rms 14298871623 max 28633786542 freq +32767999 +/-   0 delay 249550 +/-   0
> ptp4l[293.998]: rms 834329141 max 1086841975 freq +32767999 +/-   0 delay 238995 +/-   0
> ptp4l[294.966]: rms 656424174 max 1242086770 freq +32767999 +/-   0 delay 228440 +/-   0
> ptp4l[295.934]: rms 834413078 max 1086933599 freq +32767999 +/-   0 delay 47601 +/-   0
> ptp4l[295.977]: selected best master clock 0022a0.fffe.000106
> ptp4l[296.992]: rms 546142504 max 1241973769 freq +32767999 +/-   0 delay 219031 +/-   0
> ptp4l[297.919]: rms 910259892 max 1164392370 freq +32767999 +/-   0 delay 217901 +/-   0
> ptp4l[298.893]: rms 546157036 max 1242015850 freq +32767999 +/-   0 delay 216772 +/-   0
> ptp4l[299.867]: rms 910419317 max 1164606134 freq +32767999 +/-   0 delay 41767 +/-   0
> ptp4l[300.821]: rms 546124273 max 1242235894 freq +32767999 +/-   0 delay 216772 +/-   0
> ptp4l[301.735]: rms 910078978 max 1164216378 freq +32767999 +/-   0 delay 213509 +/-   0
> ptp4l[302.709]: rms 546122078 max 1241845058 freq +32767999 +/-   0 delay 148756 +/-   0
> ptp4l[303.682]: rms 910298081 max 1164439875 freq +32767999 +/-   0 delay 142954 +/-   0
> ptp4l[304.651]: rms 546142664 max 1242083695 freq +32767999 +/-   0 delay 201156 +/-   0
> ptp4l[305.551]: rms 910186093 max 1164323638 freq +32767999 +/-   0 delay 201156 +/-   0
> ptp4l[306.524]: rms 546136673 max 1241949998 freq +32767999 +/-   0 delay 189790 +/-   0
> ptp4l[307.498]: rms 910274018 max 1164416786 freq +32767999 +/-   0 delay 189790 +/-   0
> ptp4l[308.472]: rms 546156330 max 1242043326 freq +32767999 +/-   0 delay 199359 +/-   0
> ptp4l[309.381]: rms 910243669 max 1164393419 freq +32767999 +/-   0 delay 201871 +/-   0
> ptp4l[310.282]: rms 546152446 max 1242024319 freq +32767999 +/-   0 delay 199359 +/-   0
> ptp4l[311.182]: rms 910248741 max 1164373995 freq +32767999 +/-   0 delay 190736 +/-   0

The path delay is very high, and has a lot of jitter (all the way from
47 us to 249 us). PTP synchronization relies on having a constant path
delay and symmetric in both directions. The path delay should not be any
higher than around 10 us for a 100Mbps link. My guess is that the
RAD-Moon media converter is to blame for the jitter. It would be good if
you could test PTP straight between two 100base-T1 ports.

Also, when asking for help related to synchronization failures, it is of
utmost importance to mention the kernel and driver versions you are
using. Most issues come from driver bugs, and there is a chance this one
is no different.