Closed echizenr closed 6 years ago
First I will start with my question regarding the sync clock algorithm. Where can I find it in order to understand how NXP achieves nanosecond precision, the calculation of the clock and the frequency.
Since the servo algorithm used is PI, the offset and frequency calculations are done here. Programs like ptp4l feed samples to the feedback loop there and apply its output (clock stepping or frequency correction) here.
could you provide a way to prove the offset value with an external means (the gap between master clock and slave clock). For example Meinberg, a NTP/PTP device provider, gives method to check the real value of the offset using the PPS (Pulse per Second) output from master and slave.
Unfortunately PPS output is not routed from the SoC onto a usable pin header on the LS1021A-TSN board. A similar board where it is, though, is the LS1021A-TWR. Normally you'd activate the output by running:
echo 1 > /sys/class/ptp/ptp0/pps_enable
Can you also send me information about the phase at the Cobalt API level since this is the real-time side. I would also like to validate that we can actually synchronize a system clock "Cobalt" without going through Linux.
I'll have to ask to make sure, but as far as I know, we don't support running a 1588 stack in Xenomai at this time.
The ctrl + c stop the clock sync or it is still working ?
If you stop the slave only, the master continues to send SYNC/FOLLOW_UP packets. I also feel that I should mention that ptp4l only synchronizes the PHC devices (/dev/ptp0). To also (indirectly) synchronize the system clocks you will need to run the phc2sys program simultaneously with ptp4l.
In addition, is there a specific hardware for sending the frames with the hours and specific frames to have frequency correction ?
I don't understand this question.
In both case, I can't obtain results like in the user guide (max : 22ns & min : -23ns) and an offset stable state.
In the "switch" test case, were you sending traffic through an external switch, or through the SJA1105 connected to the internal eth2 interface? As a debugging step, could you try setting up the synchronization on the eth2 interface too and see if it makes any difference? There might be an issue with the PHY chips on eth0 and eth1 which go to sleep autonomously when they detect low amounts of traffic (like PTP only) and this may cause packet drop.
Moreover, the command : ptp4l -i eth0 -p /dev/ptp0 -f /etc/ptp4l_default.cfg –m isn't working for me, like if each LS1021 board become master without seeing the other one.
Are the boards able to ping one another?
Can you also send me information about the phase at the Cobalt API level since this is the real-time side. I would also like to validate that we can actually synchronize a system clock "Cobalt" without going through Linux.
Can I ask again what is the exact use case for running the ptp4l in the real-time domain? As far as my understanding goes, most of the sync inaccuracies are resolved by using hardware timestamping. I'm not sure what benefit would running in Xenomai bring.
I thank you for the information you sent me.
Regarding the question about both boards, I can confirm you that they are able to ping one another but the following command : ptp4l -i eth0 -p /dev/ptp0 -f /etc/ptp4l_default.cfg –m still isn't working.
I have few questions about my current tests.
Could you confirm me that the value named path delay is the delay that frames takes to pass through the link which relay both boards ? And could you tell me if it's a one-way time value or a round-trip time value.
Does the value named freq on slave's display, once it's synchronize with the master, represent the frequency correction value ?
Also regarding an old test that I made, could you tell me why in point to point connection between my two boards, I have a bad accuracy and when I put an external switch between them, I can see a significant improvement ?
You mention that we can't perform tests with PPS value with those boards but could you tell me if there is a way to externally evaluate/prove the synchronization state in order to make my tests as robust as possible.
How do you calculate the synchronization value (you provide me the code but I need to know the operation you perform). Also which hardware you use to perform frequency and delay correction ?
Regarding my tests, I would like to connect a PTP servor (linked to a GPS) to a LS201ATSN board. When I try, the PTP servor and the LS1021ATSN board can't see each other, do you know why ? Is the LS1021ATSN board not able to synchronize with another device than a LS1021ATSN Board ?
My last question is about network disturbance. I'm currently trying to disturb my network (2 LS1021ATSN Boards) with a SPIRENT but I need a crucial information : is the dating of frames made by the internal switch (SJA1105) or by the subscriber ? If it's the switch that make the dating, I suppose that I will need to put an external switch between my two boards in order to observe the influence of the traffic generated by the SPIRENT. You could find an attach file named Direct & indirect link with spirent traffic that can give you a better view of what I'm trying to do. The case 2 represent the configuration that I suppose to be the right one in the case where the board's internal switch makes the dating.
Can I ask again what is the exact use case for running the ptp4l in the real-time domain? As far as my understanding goes, most of the sync inaccuracies are resolved by using hardware timestamping. I'm not sure what benefit would running in Xenomai bring.
It's because real time in linux is not good enough to perform nanosecond precision and test around this metric. We though that running in Xenomai will improve the accuracy of our test.
Could you confirm me that the value named path delay is the delay that frames takes to pass through the link which relay both boards ? And could you tell me if it's a one-way time value or a round-trip time value.
According to the code in tsproc.c, the path delay is calculated based on the same basic formula as presented on the Meinberg blog:
delay = (t2 - t1 + t4 - t3) / 2
Actually there seems to be an extra correction which takes into account the fact that the master clock might run faster/slower than the slave (the clock frequency ratio is denoted as rr
or tsp->clock_rate_ratio
). So as to not throw off the results, the formula becomes:
delay = ((t2 - t3) * rr + (t4 - t1)) / 2
So a simple answer to your question: the path delay is actually a round-trip time divided by 2.
Not the actual round-trip time that ping (for instance) would report. Since t1
, t2
, t3
, t4
are all collected at the Ethernet MAC side, the software processing delay is not included in this calculation.
Does the value named freq on slave's display, once it's synchronize with the master, represent the frequency correction value ?
The frequency value is actually specific to the Ethernet controller (eTSEC) and its own internal clock adjustment digital circuitry. It has no real meaning in an absolute unit of measurement. I've seen it been called PPB (parts per billion), although I'm not sure what's that supposed to mean exactly.
The maximum frequency adjustment permitted by the eTSEC driver is configured in gianfar_ptp.c to 512000. Please study the ptp_gianfar_adjfreq
function, the related DTS bindings and correlate with this diagram of the 1588 clock adjustment digital logic block (slide 15) to understand how frequency adjustment actually works.
There is also another limit to the frequency adjustment that can be imposed to the ptp4l program from its configuration file. The program correctly knows how to respect the smallest limit of the two.
Also regarding an old test that I made, could you tell me why in point to point connection between my two boards, I have a bad accuracy and when I put an external switch between them, I can see a significant improvement ?
This can be indicative of some PHY parameters that are negotiated differently in the 2 cases (back-to-back and switch in-between) - thinking along the lines of EEE abilities, as I said earlier. I'll take some time and see if I can reproduce this with a back-to-back connection.
Regarding my tests, I would like to connect a PTP servor (linked to a GPS) to a LS201ATSN board. When I try, the PTP servor and the LS1021ATSN board can't see each other, do you know why ? Is the LS1021ATSN board not able to synchronize with another device than a LS1021ATSN Board ?
Do you see the packets with tcpdump on the Layerscape board? What network transport are they encapsulated in? Raw Ethernet (in which case run with ptp4l -2
) or UDP (ptp4l -4
)?
How do you calculate the synchronization value (you provide me the code but I need to know the operation you perform). Also which hardware you use to perform frequency and delay correction ?
I don't understand this question very well. The 1588 stack is provided by Richard Cochran's linux-ptp open source project. It takes care of being compliant with the 1588 standard (the "business logic" of the protocol sits there). The application is designed to collaborate with a large variety of Ethernet controllers made by various vendors through a standard Linux API. Some (but probably not all) of these APIs are for:
On the LS1021, these functions are implemented in the gianfar
and gianfar_ptp
kernel drivers.
is the dating of frames made by the internal switch (SJA1105) or by the subscriber ?
The SJA1105 will interfere in the process of timestamping in the following conditions:
ptp4l -2
) andIGNORE2STF
configuration field is enabled orWhat I just described above is called Transparent Clock in 1588v2 terminology. Such a device monitors the PTP synchronization between the master and the slave passively - it is neither a master and a slave, and therefore packet termination never occurs on a TC. It keeps its internal clock running at the same frequency as the master, and adjusts the timestamps of all forwarded PTP packets [that it understands] so as to compensate for the internal propagation delay that the packet spent inside the TC device.
To be precise, the PTP master and slave exchange time through the originTimestamp
field etc in the PTP packet body. The behavior of a Transparent Clock does NOT alter the originTimestamp
. Instead, there is a reserved field in the PTP header called correctionField
, which is reserved for use by devices like the Transparent Clock. PTP endpoints that are 1588v2-compliant should know to take the correctionField
into consideration when they calculate the offset and delay.
So to answer your question: yes, the SJA1105 might alter timestamps in PTP packets under the conditions above, but it alters a field which is reserved for that use specifically. The timestamps that are placed in packets by the master and the slave are not altered.
I thank you for the information you sent me.
So if I understand, I can overload the network with spirent traffic when I'm in case number two (previous figure) without adding an external switch.
I don't understand this question very well. The 1588 stack is provided by Richard Cochran's linux-ptp open source project. It takes care of being compliant with the 1588 standard (the "business logic" of the protocol sits there). The application is designed to collaborate with a large variety of Ethernet controllers made by various vendors through a standard Linux API. Some (but probably not all) of these APIs are for:
Collecting the timestamp recorded at the MAC for sent and received packets (done through socket ioctl calls). Adjusting the hardware clock of the Ethernet controller (done through the POSIX clock API). On the LS1021, these functions are implemented in the gianfar and gianfar_ptp kernel drivers.
To be more explicit, I need to understand how do you mathematically calculate the synchronization gap and how this value is interpreted by the slave and finally how the slave applies this correction to be synchronized to the master. For example, with NTP protocol, it was performed by Kalman filter. Do you use a similar method ?
In addition, is it possible to obtain the time of the slave before synchronization in order to evaluate, apart from the messages displayed by the program, the state of synchronization and confirm it?
I thank you in advance
So if I understand, I can overload the network with spirent traffic when I'm in case number two (previous figure) without adding an external switch.
So you are trying to measure the effect of queuing delays upon the synchronization performance. Since timestamping is done at the Ethernet controllers of the Layerscape chips, yes, you don't need to add yet another switch apart from the 2 SJA1105 devices.
To be more explicit, I need to understand how do you mathematically calculate the synchronization gap and how this value is interpreted by the slave and finally how the slave applies this correction to be synchronized to the master. For example, with NTP protocol, it was performed by Kalman filter. Do you use a similar method ? In addition, is it possible to obtain the time of the slave before synchronization in order to evaluate, apart from the messages displayed by the program, the state of synchronization and confirm it?
At the highest level, the synchronization is done in the port_synchronize function. There you can also find the protocol t1 and t2 timestamps. This function further calls clock_synchronize. Here, the calculated master<->slave offset is fed into a stateful feedback loop (by calling servo_sample
) that implements one of multiple possible regulator backends. The default backend for the servo is a PI regulator, a link to which I already sent you (the pi.c file).
The servo can be in 3 states:
SERVO_UNLOCKED
(initial state) - you can see it as s0
in the output of ptp4l
,SERVO_JUMP
(master-slave offset is large; the slave clock is adjusted through stepping, meaning that in order to close the gap quicker, its clock is set to a particular value directly through clock_adjtime
(with an empty struct timex *tx
) - you can see this state as s1
in the output of ptp4l
.SERVO_LOCKED
(this is the stable state where the master-slave offset is small enough as to be controlled through frequency adjustment on the slave clock only - either accelerate or slow down, but no jumps - see the clockadj_set_freq
function which calls clock_adjtime
with the frequency specified in the struct timex *tx
parameter) - you can see this denoted as s2
in the output of ptp4l
.It's difficult to do a more detailed writeup without going into implementation details. You can insert additional debugging prints in the code and come back if you need an explanation if something is strange or confusing.
Thank you for your answer.
I am currently conducting a TSN evaluation for the civil avionics world which will involve the mandatory passage of selected equipment through certification phases. This may allow you to better understand why I'm asking those specific questions. I try to be as complete as possible in this study phase.
I also have a question about a test result I did a few days ago. I managed to make the ptp4l -i eth2 -p /dev/ptp0 -f /etc/ptp4l_default.cfg -m command work and I would like information on the meaning and interpretation of the values obtained (rms, max, both +/-).
I attached the file bellow.
ptp4l[145.004]: selected /dev/ptp0 as PTP clock ptp4l[145.006]: driver changed our HWTSTAMP options ptp4l[145.007]: tx_type 1 not 1 ptp4l[145.007]: rx_filter 1 not 12 ptp4l[145.007]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[145.007]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[145.008]: port 1: link up ptp4l[151.710]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[151.710]: selected best master clock 00049f.fffe.ef0808 ptp4l[151.710]: assuming the grand master role ptp4l[153.901]: port 1: new foreign master 00049f.fffe.ef0000-1 ptp4l[157.911]: selected best master clock 00049f.fffe.ef0000 ptp4l[157.911]: port 1: MASTER to UNCALIBRATED on RS_SLAVE ptp4l[158.706]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[159.486]: rms 1745 max 2300 freq -976 +/- 1213 delay 6900 +/- 0 ptp4l[160.526]: rms 303 max 489 freq +18 +/- 423 delay 6881 +/- 0 ptp4l[161.566]: rms 490 max 544 freq +936 +/- 153 ptp4l[162.606]: rms 292 max 420 freq +1076 +/- 39 delay 6900 +/- 0 ptp4l[163.646]: rms 106 max 185 freq +1006 +/- 47 delay 6912 +/- 0 ptp4l[164.686]: rms 56 max 105 freq +859 +/- 69 delay 6900 +/- 0 ptp4l[165.726]: rms 42 max 85 freq +823 +/- 40 delay 6892 +/- 0 ptp4l[166.766]: rms 21 max 30 freq +845 +/- 29 delay 6900 +/- 0 ptp4l[167.806]: rms 26 max 40 freq +866 +/- 33 delay 6895 +/- 0 ptp4l[168.846]: rms 27 max 50 freq +865 +/- 37 delay 6900 +/- 0 ptp4l[169.886]: rms 41 max 75 freq +824 +/- 52 delay 6895 +/- 0 ptp4l[170.926]: rms 31 max 58 freq +858 +/- 40 delay 6887 +/- 0 ptp4l[171.966]: rms 28 max 53 freq +875 +/- 35 ptp4l[173.006]: rms 19 max 33 freq +886 +/- 22 delay 6891 +/- 4 ptp4l[174.046]: rms 51 max 87 freq +802 +/- 45 delay 6882 +/- 0 ptp4l[175.086]: rms 19 max 38 freq +827 +/- 26 delay 6878 +/- 0 ptp4l[176.126]: rms 39 max 62 freq +882 +/- 41 delay 6878 +/- 0 ptp4l[177.166]: rms 37 max 76 freq +861 +/- 51 delay 6876 +/- 0 ptp4l[178.206]: rms 37 max 86 freq +828 +/- 47 delay 6867 +/- 0 ptp4l[179.246]: rms 30 max 68 freq +855 +/- 40 delay 6857 +/- 0 ptp4l[180.286]: rms 38 max 58 freq +881 +/- 48 delay 6858 +/- 0 ptp4l[181.326]: rms 48 max 93 freq +828 +/- 62 delay 6863 +/- 0 ptp4l[182.366]: rms 35 max 63 freq +828 +/- 48 delay 6858 +/- 0 ptp4l[183.406]: rms 26 max 53 freq +851 +/- 34 delay 6860 +/- 2 ptp4l[184.446]: rms 39 max 67 freq +827 +/- 53 ptp4l[185.486]: rms 30 max 42 freq +793 +/- 30 delay 6862 +/- 2 ptp4l[186.526]: rms 41 max 76 freq +873 +/- 35 delay 6866 +/- 2 ptp4l[187.566]: rms 22 max 37 freq +870 +/- 24 delay 6868 +/- 0 ptp4l[188.606]: rms 47 max 88 freq +820 +/- 61 delay 6868 +/- 0 ptp4l[189.646]: rms 24 max 42 freq +839 +/- 32 ptp4l[190.686]: rms 33 max 52 freq +871 +/- 39 delay 6868 +/- 0 ptp4l[191.726]: rms 30 max 68 freq +837 +/- 41 delay 6868 +/- 0 ptp4l[192.766]: rms 27 max 47 freq +823 +/- 34 ptp4l[193.806]: rms 29 max 48 freq +857 +/- 36 delay 6867 +/- 0 ptp4l[194.846]: rms 30 max 48 freq +880 +/- 34 delay 6867 +/- 0 ptp4l[195.886]: rms 54 max 106 freq +798 +/- 59 delay 6871 +/- 0 ptp4l[196.926]: rms 31 max 59 freq +844 +/- 42 delay 6866 +/- 0 ptp4l[197.966]: rms 35 max 54 freq +886 +/- 32 delay 6866 +/- 0 ptp4l[199.006]: rms 61 max 91 freq +807 +/- 76 delay 6876 +/- 0 ptp4l[200.046]: rms 27 max 44 freq +836 +/- 38 delay 6878 +/- 0 ptp4l[201.086]: rms 27 max 52 freq +868 +/- 29 delay 6878 +/- 0 ptp4l[202.126]: rms 36 max 78 freq +825 +/- 47 delay 6878 +/- 0 ptp4l[203.166]: rms 25 max 44 freq +841 +/- 35 delay 6886 +/- 0 ptp4l[204.206]: rms 30 max 69 freq +876 +/- 33 delay 6886 +/- 0 ptp4l[205.251]: rms 35 max 46 freq +863 +/- 49 delay 6886 +/- 0 ptp4l[206.286]: rms 42 max 81 freq +799 +/- 38 delay 6889 +/- 0 ptp4l[207.326]: rms 29 max 51 freq +867 +/- 29 delay 6879 +/- 0 ptp4l[208.366]: rms 35 max 61 freq +908 +/- 25 ptp4l[209.406]: rms 62 max 114 freq +807 +/- 67 delay 6878 +/- 0 ptp4l[210.446]: rms 31 max 52 freq +823 +/- 41
I thank you in advance.
As I understand, you'd still like to be able to externally verify the synchronization offset, via measuring the phase difference of the PPS outputs from the master and slave. I'm trying to figure out what is the necessary board configuration that needs to be done for this experiment. Is this ok?
Yes that's what I'm trying to do if it's possible. Because if your equipment is selected, it must go through a certification phase where this test will be done (with other test of course).
Regarding my last question, could you give me an explanation as to the results obtained as well as the meaning of rms, max and both +/- (what are their signification and how can I interpret them ?)
Also I have a question regarding the kit content, is their a way to only buy the same USB 2.0 cable present in this kit (the one allowing us to make the serial link with the PC). Maybe you have a product reference ?
Also I have a question regarding the kit content, is their a way to only buy the same USB 2.0 cable present in this kit (the one allowing us to make the serial link with the PC). Maybe you have a product reference ?
The microUSB cable is not special in any way, as far as I am aware.
Yes I saw that, I asked because during my last test, an error occurs about missing requirement from the cable. It was for sure a bug because now it's working.
Thanks for the confirmation.
On the LS1021A chip, the auxilliary 1588 functionality is multiplexed with GPIO and RGMII (Ethernet).
On the LS1021A-TSN board, the primary functionality of these pins is RGMII. The eth2
port is routed towards the SJA1105 switch. Therefore, this experiment by its nature disables communication between the LS1021 and the SJA1105, since both pinmux functionalities cannot be enabled at the same time.
The 1588 pins from the LS1021 are spread out on the board in 3 places:
The pinmux functionality of the pins on Layerscape devices is controlled through the Reset Configuration Word (RCW), which is a 512 bit structure.
On the LS1021A-TSN, OpenIL distributes the Reset Configuration Word as a binary that is included in the U-boot bootloader present on the SD card (the u-boot-with-spl-pbl.bin
file).
In particular, the pinmux settings for 1588 functionality are accessible through the RCW[EC3] field.
The boot/uboot/0001-ls1021atsn-extra-rcw-ec3.patch
file in the feature/ls1021atsn-pps-output branch includes two extra RCWs which enable the alternative configurations of the RGMII port pins:
board/freescale/ls1021atsn/ls102xa_rcw_sd_qspi_gpio.cfg
)board/freescale/ls1021atsn/ls102xa_rcw_sd_qspi_1588.cfg
)The RCW that will be included in U-boot is decided in the include/configs/ls1021atsn.h
file (by default set to GPIO).
There are additional patches on the Linux kernel and the sja1105-tool
for this functionality to work correctly. They are not discussed here.
Any *.patch
files in a package's directory are automatically picked up by the Buildroot build system during the .stamp_patched
phase. Therefore, the following sequence is sufficient to pull and apply the patches:
git checkout feature/ls1021atsn-pps-output
rm -rf output/build/uboot-LSDK-17.09
rm -rf output/build/linux-LSDK-17.09-V4.9
rm -rf output/build/sja1105-tool-master/
make uboot
make linux
make sja1105-tool
This procedure is prone to mistakes which might cause many hours wasted on debugging inexistent problems. Since the needed pins on the LS1021A-TSN board were only routed for the primary functionality (RGMII connectivity with the SJA1105 switch), one might face multiple difficulties:
package/sja1105-tool/0001-Makefile-do-not-install-init-scripts.patch
.To illustrate the last bullet, here is how PPS output will look like, when captured with an improper logic analyzer. The low sample rate will cause many pulse misses.
Please ensure that the boot/uboot/0001-ls1021atsn-extra-rcw-ec3.patch
file contains this line (by default it does):
+ board/freescale/ls1021atsn/ls102xa_rcw_sd_qspi_gpio.cfg
Recompile U-boot:
rm -rf output/build/uboot-LSDK-17.09
make uboot
A quick way to reflash U-boot on the SD card using TFTP:
setenv ipaddr 10.0.0.2;setenv serverip 10.0.0.100;tftp 82000000 u-boot-with-spl-pbl.bin;mmc erase 8 0x500;mmc write 0x82000000 8 0x500
Then in Linux, do the following:
for controller in /sys/class/gpio/gpiochip*; do echo ${controller}; cat ${controller}/label; done
for pin in 901 956 957 958 959; do echo ${pin} > /sys/class/gpio/export; echo out > /sys/class/gpio/gpio${pin}/direction; done
for val in 0 1 0 1 0 1 0 1 0 1; do echo ${val} > /sys/class/gpio/gpio958/value; sleep 0.5; done
The following output should be visible on GPIO pin 958 (bottom, pinmuxed with TSEC_1588_CLK_OUT
).
Please ensure that the boot/uboot/0001-ls1021atsn-extra-rcw-ec3.patch
file contains this line (by default it doesn't, so it needs to be changed):
+ board/freescale/ls1021atsn/ls102xa_rcw_sd_qspi_1588.cfg
Recompile U-boot as described above.
When configured for 1588 functionality, the TSEC_1588_CLK_OUT
is expected to generate a signal similar to the one below, with no further configuration:
In Linux, to enable PPS output, do the following:
echo 1 > /sys/class/ptp/ptp0/pps_enable
The following should be visible on the TSEC_1588_PULSE_OUT1
pin (near the SJA1105):
Thank you for your answer. I will study those cases, I'm sure they will be helpful for the rest of the study phase.
Regarding my last question for the line command : ptp4l -i eth2 -p /dev/ptp0 -f /etc/ptp4l_default.cfg -m, the rms value is understandable but the first +/- value match with frequency adjustment, Am I right ?
I have a question regarding the transparent clock. I saw on a OVDA publication that transparent clock are not implemented in 802.1AS profile because they violate IEEE802 layering conventions. I don't really understand what they means and how 802.1AS will provide latency compensation on switches without transparent clock.
Thanks again for all the help you gave me !
ptp4l[169.886]: rms 41 max 75 freq +824 +/- 52 delay 6895 +/- 0
To be honest this is the first time I notice these lines in the output of ptp4l
.
They seem to be enabled through the summary_interval
option in /etc/ptp4l_default.cfg
. Comment out that line and they go away.
According to the manual (man -l ptp4l.8
):
summary_interval The time interval in which are printed summary statistics of the clock. It is specified as a power of two in seconds. The statistics include offset root mean square (RMS), maximum absolute offset, frequency offset mean and standard deviation, and path delay mean and standard deviation. The units are nanoseconds and parts per billion (ppb). If there is only one clock update in the interval, the sample will be printed instead of the statistics. The messages are printed at the LOG_INFO level. The default is 0 (1 second).
So yes, the frequency adjustment figures are averages measured in PPB. They seem to be printed from clock.c.
I have a question regarding the transparent clock. I saw on a OVDA publication that transparent clock are not implemented in 802.1AS profile because they violate IEEE802 layering conventions. I don't really understand what they means and how 802.1AS will provide latency compensation on switches without transparent clock.
I don't have any relevant comment to add to this. As far as I know, the 802.1AS-2011 spec has the following to say (I'm quoting from 7.5 Differences between gPTP and PTP):
In gPTP there are only two types of time-aware systems: end stations and Bridges, while IEEE 1588 has ordinary clocks, boundary clocks, end-to-end transparent clocks, and P2P transparent clocks. A time-aware end station corresponds to an IEEE 1588 ordinary clock, and a time-aware Bridge is a type of IEEE 1588 boundary clock where its operation is very tightly defined, so much so that a time-aware Bridge with Ethernet ports can be shown to be mathematically equivalent to a P2P transparent clock in terms of how synchronization is performed, as shown in 11.1.3. A time-aware system measures link delay and residence time, and communicates these in a correction field.
So Transparent Clock functionality is definitely not absent from the 802.1AS spec, it's just implemented as part of so-called Time-Aware Bridges. However that's about all I know.
Thanks for your answer !
I wanted to check the validity of the information given by the OVDA.
I close this issue
Hello,
I have few questions. In order to be understandable I will display results and configurations in bold.
First I will start with my question regarding the sync clock algorithm. Where can I find it in order to understand how NXP achieves nanosecond precision, the calculation of the clock and the frequency. Also regarding the performance, could you provide a way to prove the offset value with an external means (the gap between master clock and slave clock). For example Meinberg, a NTP/PTP device provider, gives method to check the real value of the offset using the PPS (Pulse per Second) output from master and slave.
In addition, is there a specific hardware for sending the frames with the hours and specific frames to have frequency correction ?
Moreover, I would like to know the method you used to perform the phase measurements on synchronized clocks. Can you also send me information about the phase at the Cobalt API level since this is the real-time side. I would also like to validate that we can actually synchronize a system clock "Cobalt" without going through Linux.
My last question before I display my configuration and results is the following one : When I use the following command : "ptp4l -i eth0 -p /dev/ptp0 -2 -m" and do a ctrl + c to stop it when I gather enough measure. The ctrl + c stop the clock sync or it is still working ? (I ask because I put a mirroring port and a wireshark to observe the traffic and even after a ctrl +c I still receive sync message from the master.
Here you can find all I did since I buid the sdcard.img and load it on each sdcard.
on master :
ifconfig eth0 hw ether 00:04:9F:EF:01:01 ptp4l -i eth0 -p /dev/ptp0 -2 -m -l 7
On slave :
ptp4l -i eth0 -p /dev/ptp0 -2 -m -l 7
vi /etc/ptp4l_default.cfg
[global] #
Default Data Set
# twoStepFlag 1 slaveOnly 0 priority1 128 priority2 128 domainNumber 0 clockClass 248 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 #
Port Data Set
# logAnnounceInterval 1 logSyncInterval -3 logMinDelayReqInterval 0 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval 4 neighborPropDelayThresh 20000000 #
Run time options
# assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 tx_timestamp_timeout 2 use_syslog 1 verbose 0 summary_interval -3 kernel_leap 1 check_fup_sync 0 #
Servo Options
# pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 0.0 first_step_threshold 0.00002 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 #
Transport options
# transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l #
Default interface options
# network_transport UDPv4 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 #
Clock description
# productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0
You can find output files below : ptp4l_offset_direct_link.zip ptp4l_offset_switch.zip
The ptp4l_offset_direct_link.zip contain measure and graph of direct Ethernet connection test between 2 LS1021ATSN.
The ptp4l_offset_switch.zip contain measure and graph of Ethernet connection test between 2 LS1021ATSN with a switch.
In both case, I can't obtain results like in the user guide (max : 22ns & min : -23ns) and an offset stable state.
Moreover, the command : ptp4l -i eth0 -p /dev/ptp0 -f /etc/ptp4l_default.cfg –m isn't working for me, like if each LS1021 board become master without seeing the other one.
I thank you in advance for your help !