TMDS64EVM: PPS offset

Hello Julien,

What version of Linux processor SDK are you using?

Regards,

Nick

Hello Nick,

We are on the SDK 10_00_07_04.

Regards,

Julien

Hi Julien,

A couple more questions

1. What is the output you see when synchronizing your TMDS64EVM as a clock follower to your grandmaster device? I.e. what is the output when running "ptp4l -i eth0 -q -f /home/ptp4l.cfg"?

2. Instead of "echo 1 > /sys/class/ptp/ptp0/pps_enable" can you test "/usr/bin/kselftests/ptp/testptp -d /dev/ptp0 -P 1" to see if the behavior changes?

3. What is your grandmaster device? Are you able to measure a PPS from your grandmaster device?

-Daolin

Hello Daolin,

1. If I activate my PPS output before ptp4l, I get an unsynchronized pps and have to deactivate and reactivate it ("testptp -d /dev/ptp0 -P 0" then "testptp -d /dev/ptp0 -P 1").

If I run ptp4l and then testptp, I get the same result as described above.

2. I found testptp on the following path: “/usr/kernel-selftest/ptp/testptp” . However, it doesn’t seem to change the result. I used testptp for the current tests.
3. It is a GPS antenna from Omicron lab. Will see for the reference if needed.

I am not able to directly get a PPS signal from it, but we've carried out a few tests in the past which have proved conclusive.

Regards,

Julien

Hi Julien,

Daolin Qiu said:

1. What is the output you see when synchronizing your TMDS64EVM as a clock follower to your grandmaster device? I.e. what is the output when running "ptp4l -i eth0 -q -f /home/ptp4l.cfg"?

Julien Dupuis said:

1. If I activate my PPS output before ptp4l, I get an unsynchronized pps and have to deactivate and reactivate it ("testptp -d /dev/ptp0 -P 0" then "testptp -d /dev/ptp0 -P 1").

If I run ptp4l and then testptp, I get the same result as described above.

I was wondering if you could show the log output of ptp4l (I think you will have to also add the "-m" option to see the log/print to standard output) so something like "ptp4l -i eth0 -q -f /home/ptp4l.cfg -m". I would expect to see some logs showing over time the offset compared to the grandmaster clock decreasing over time as a first check. 

Julien Dupuis said:

It is a GPS antenna from Omicron lab. Will see for the reference if needed.

Is your grandmaster device (this GPS antenna) have the ability to run ptp4l (Linuxptp)?

Additionally, when you get the chance, assuming you are testing PTP on CPSW Ethernet, please try running "ptp4l -P -2 -H -i eth0 -f gPTP.cfg \ --step_threshold=1 -m -q -p /dev/ptp0" where gPTP.cfg is the below and see if the behavior changes.

# 802.1AS example configuration containing 
those attributes which
# differ from the defaults. See the file, 
default.cfg, for the
# complete list of available options.
#
[global]
gmCapable 1
priority1 240
priority2 248
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
ingressLatency 96
egressLatency 288

-Daolin

Hi Daolin,

Daolin Qiu said:

I was wondering if you could show the log output of ptp4l (I think you will have to also add the "-m" option to see the log/print to standard output) so something like "ptp4l -i eth0 -q -f /home/ptp4l.cfg -m". I would expect to see some logs showing over time the offset compared to the grandmaster clock decreasing over time as a first check. 

Here is the output, which I think is correct:

ptp4l[131.514]: selected /dev/ptp0 as PTP clock
ptp4l[131.529]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[131.530]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[131.530]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[132.020]: port 1 (eth0): new foreign master 20b7c0.fffe.007da2-1
ptp4l[136.023]: selected best master clock 20b7c0.fffe.007da2
ptp4l[136.023]: port 1 (eth0): LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[137.496]: master offset      -9587 s0 freq   +3983 path delay      6998
ptp4l[138.499]: master offset     -10074 s2 freq   +3497 path delay      6955
ptp4l[138.499]: port 1 (eth0): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[139.503]: master offset      -9801 s2 freq   -6304 path delay      6955
ptp4l[140.505]: master offset       1590 s2 freq   +2147 path delay      5330
ptp4l[141.508]: master offset       2488 s2 freq   +3522 path delay      5877
ptp4l[142.512]: master offset       2012 s2 freq   +3792 path delay      6424
ptp4l[143.515]: master offset       1639 s2 freq   +4023 path delay      6603
ptp4l[144.518]: master offset       1205 s2 freq   +4080 path delay      6603
ptp4l[145.521]: master offset        694 s2 freq   +3931 path delay      6786
ptp4l[146.524]: master offset        161 s2 freq   +3606 path delay      6786
ptp4l[147.527]: master offset        277 s2 freq   +3770 path delay      6793
ptp4l[148.531]: master offset         41 s2 freq   +3617 path delay      6817
ptp4l[149.534]: master offset         -3 s2 freq   +3586 path delay      6817
ptp4l[150.537]: master offset       -121 s2 freq   +3467 path delay      6886
ptp4l[151.540]: master offset       -209 s2 freq   +3343 path delay      6893
ptp4l[152.543]: master offset         26 s2 freq   +3515 path delay      6836
ptp4l[153.547]: master offset        236 s2 freq   +3733 path delay      6836
ptp4l[154.549]: master offset       -190 s2 freq   +3377 path delay      6872
ptp4l[155.553]: master offset        180 s2 freq   +3690 path delay      6830
ptp4l[156.556]: master offset         19 s2 freq   +3583 path delay      6830
ptp4l[157.558]: master offset        -54 s2 freq   +3516 path delay      6837
ptp4l[158.561]: master offset       -247 s2 freq   +3307 path delay      6837
ptp4l[159.565]: master offset        -53 s2 freq   +3427 path delay      6835
ptp4l[160.567]: master offset         21 s2 freq   +3485 path delay      6835
ptp4l[161.571]: master offset        209 s2 freq   +3679 path delay      6835
ptp4l[162.574]: master offset         58 s2 freq   +3591 path delay      6835
ptp4l[163.578]: master offset       -288 s2 freq   +3262 path delay      6860
ptp4l[164.581]: master offset        209 s2 freq   +3673 path delay      6783
ptp4l[165.584]: master offset       -194 s2 freq   +3333 path delay      6808
ptp4l[166.587]: master offset        193 s2 freq   +3661 path delay      6753
ptp4l[167.590]: master offset       -188 s2 freq   +3338 path delay      6753

Daolin Qiu said:

Additionally, when you get the chance, assuming you are testing PTP on CPSW Ethernet, please try running "ptp4l -P -2 -H -i eth0 -f gPTP.cfg \ --step_threshold=1 -m -q -p /dev/ptp0" where gPTP.cfg is the below and see if the behavior changes.

The output:

ptp4l[1767.930]: selected /dev/ptp0 as PTP clock
ptp4l[1767.951]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1767.951]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1767.952]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1771.639]: selected local clock 1c6349.fffe.1ad759 as best master

It does not select the grandmaster as the best clock using this command, it uses its own clock.

Julien

Hi Julien, 

For the "ptp4l -i eth0 -q -f /home/ptp4l.cfg -m" could you add the "-H" option and see if that changes the output to have a smaller offset?

Julien Dupuis said:

We are on the SDK 10_00_07_04.

Is it possible for you test on SDK 10.1 (10.01.10.04) or newer?

For your application, is there a requirement of using the CPSW Ethernet interface (eth0 by default on the TMDS64EVM) vs using the PRU_ICSSG Ethernet interface (eth2 by default on the TMDS64EVM)? If you are able to test on SDK 10.1 or newer, as a sanity check, can you check the PPS signal when running PTP on PRU_ICSSG Ethernet and see if you observe the same behavior (3 microsecond offset)? It has to be SDK 10.1 or newer for PRU_ICSSG since there have been fixes to the PPS synchronization issues found in older SDK versions.

-Daolin

Daolin Qiu said:

For the "ptp4l -i eth0 -q -f /home/ptp4l.cfg -m" could you add the "-H" option and see if that changes the output to have a smaller offset?

It does not change the offset.

Daolin Qiu said:

For your application, is there a requirement of using the CPSW Ethernet interface (eth0 by default on the TMDS64EVM) vs using the PRU_ICSSG Ethernet interface (eth2 by default on the TMDS64EVM)? If you are able to test on SDK 10.1 or newer, as a sanity check, can you check the PPS signal when running PTP on PRU_ICSSG Ethernet and see if you observe the same behavior (3 microsecond offset)? It has to be SDK 10.1 or newer for PRU_ICSSG since there have been fixes to the PPS synchronization issues found in older SDK versions.

I tested on 10.01.10.04 with two TMDS64EVM:

ptp4l -i eth2 -q -H -2 -P

and the other with the argument '-s'.

I'm having much better results: almost 0ns offset and a very low jitter (around 100ns).

I believe my grandmaster is using IPv4 protocol and not IEEE 802.3 protocol. I need to confirm that.

Using two TMDS64EVM, I tried the command

ptp4l -i eth2 -q -H -m

On the client board: adding argument '-s' to work as a client.

Same commands as before without '-P' and '-2'.

If I understand right, it should have work with IPv4 and E2E since these are the default parameters.

With this configuration, the client board doesn't synchronize with my first grandmaster board. It select its local clock as best master.

Is that an expected behavior?

Is P2P and/or IEEE 802.3 transport protocol required to work with TMDS64EVM?

Hi Julien, 

Julien Dupuis said:

I'm having much better results: almost 0ns offset and a very low jitter (around 100ns).

Good to hear that with eth2 on SDK 10.01.10.04, you are able to see a more reasonable offset. Just to confirm, is there a requirement for using CPSW Ethernet (eth0) or PRU_ICSSG Ethernet (eth2) for your application?

Julien Dupuis said:

If I understand right, it should have work with IPv4 and E2E since these are the default parameters.

With this configuration, the client board doesn't synchronize with my first grandmaster board. It select its local clock as best master.

Is that an expected behavior?

ptp4l (Linux PTP) is a general Linux application/utility tool that the Linux filesystem that the TI SDKs happen to enable. However, we at TI are not experts in the options Linux PTP provides as this is more of an application specific issue, so I cannot say for sure if IPv4 and E2E are the default parameters. Looking at a ptp4l manpage, I don't actually see any indication this is the default configuration. 

Julien Dupuis said:

Is P2P and/or IEEE 802.3 transport protocol required to work with TMDS64EVM?

We have not specifically tested for all the different variations of PTP with TMDS64EVM, only the ones that have been shown in our SDK documentation. That is not say that other variations of PTP using Linux PTP won't work, just that it may result in some untracked behavior because we haven't tested it before.

https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/CPSW-PTP.html#ptp-with-ordinary-clock-mac-mode

https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU_ICSSG_Ethernet_Switch.html#ptp

-Daolin

Hi Daolin,

Thank you for your quick reply, as always.

Daolin Qiu said:

Good to hear that with eth2 on SDK 10.01.10.04, you are able to see a more reasonable offset. Just to confirm, is there a requirement for using CPSW Ethernet (eth0) or PRU_ICSSG Ethernet (eth2) for your application?

I am not constrained to use CPSW or PRU_ICSSG.

Daolin Qiu said:

ptp4l (Linux PTP) is a general Linux application/utility tool that the Linux filesystem that the TI SDKs happen to enable. However, we at TI are not experts in the options Linux PTP provides as this is more of an application specific issue, so I cannot say for sure if IPv4 and E2E are the default parameters. Looking at a ptp4l manpage, I don't actually see any indication this is the default configuration. 

I think this was a misunderstanding of mine, as everything works fine using two TMDS64EVMs: one as a grand master and the other as a slave.

I'm going to pursue further tests with the grandmaster used since the offset is still there somehow.

I was wondering, I flashed the SDK 10.01.10.04 on an SD card. I plugged it into the TMDS64EVM without any modification of the board or the SD card.

On startup, everything goes well - or at least without errors, but for HW clocks I get the following:

[FAILED] Failed to start Synchronize System and HW clocks.

Is that expected? I got the "Failed" error on two separated TMDS64EVM.

Regards,

Julien

Another question,

Is the path delay (indicated by the ptp4l log) taken into account by the pps signal generated by the PPS output?

Julien

Julien Dupuis said:

On startup, everything goes well - or at least without errors, but for HW clocks I get the following:

Fullscreen

1

[FAILED] Failed to start Synchronize System and HW clocks.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

[FAILED] Failed to start Synchronize System and HW clocks.

Is that expected? I got the "Failed" error on two separated TMDS64EVM.

I think this message is a result of the sync-clocks service. To my knowledge, I don't think this is necessary for local PTP synchronization. From some quick research I did on what this service does, I think it is simply meant to synchronize the system clock and HW clocks to a remote time server (for example the internet). To my knowledge, currently this message is seen by default on the SDK 10.1 but it shouldn't actually cause any functionality issues for PTP synchronization.

Starting Synchronize System and HW clocks...
[FAILED] Failed to start Synchronize System and HW clocks.
See 'systemctl status sync-clocks.service' for details.

Julien Dupuis said:

Is the path delay (indicated by the ptp4l log) taken into account by the pps signal generated by the PPS output?

From my understanding, path delay is the time it takes for a PTP synchronization message to travel from a grandmaster clock to a follower clock and back and used to compensate for the network delay between the clocks. PPS on the other hand, to my knowledge, is simply meant as an indication of how synchronized the devices in the PTP network are with each other and should be a reflection of the synchronization from ptp4l which uses path delay. 

I'm not sure if that helps address your question. If not, can you elaborate by what you mean by "taken into account by the pps signal"?

-Daolin