Thread: [Linuxptp-users] Finding the Fixed offset between two Ports of the same NIC.
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
From: Deshpande, Y. <yas...@tu...> - 2022-05-31 12:02:45
|
Hello All, Here is my setup and what I observe: An intel i350 NIC with two RJ45 Ports is connected to a simple 4 Core PC with Linux (Ubuntu 20). A cable is connected between the two ports (this is what I call a loopback connection). When I run a PTP Source (Master) on one port and a PTP Sink (Slave) on the other with the latter in free_running mode, I see that the Sink reports a constant offset - for a test I ran for 3 hours. Since I dont adjust the time or frequency on the sink port, and I get a constant offset for an extended period of time, I assume that the clocks on both the ports are running on the same Oscillator (what the Datasheet seems to suggest as well). Is this assumption correct? The reported offset value changes every time I reboot. It also changes after I assign each port to a separate namespace. What I want to do: Now I want to find this offset value without running PTP4l because the Loopback connection will be done with a DUT in the middle. Assuming that the offset between the two ports is constant, I assume that a mechanism that gets the clock values from the two ports repeatedly and one after the other should help in finding this value. However, trying to reuse the pieces of code from phc2sys.c "read_phc" did not give satisfactory results. Here is my rough piece of code. static int64_t read_phc_offsets(clockid_t clkid1, clockid_t clkid2) { struct timespec tdst1, tdst2, tsrc; int i; int64_t interval, best_interval = INT64_MAX; int readings = 10; int64_t offset,ts; /* Pick the quickest clkid reading. */ for (i = 0; i < readings; i++) { if (clock_gettime(clkid2, &tdst1) || clock_gettime(clkid1, &tsrc) || clock_gettime(clkid2, &tdst2)) { printf("Failed to read clock"); return 0; } interval = (tdst2.tv_sec - tdst1.tv_sec) * NS_PER_SEC + tdst2.tv_nsec - tdst1.tv_nsec; if (best_interval > interval) { best_interval = interval; offset = ((tdst1.tv_sec - tsrc.tv_sec) * NS_PER_SEC) + (tdst1.tv_nsec - tsrc.tv_nsec); ts = tdst2.tv_sec * NS_PER_SEC + tdst2.tv_nsec; } } ts = best_interval; return offset; } Where clkid1 is the Clock ID of the first port and clkid2 is the Clock ID of the second port. I know that PPS loopback is probably the best way going forward - but i was wondering if there is any easier and more obvious way that I am missing out. Best Regards Yash Deshpande Yash Deshpande Lehrstuhl für Kommunikationsnetze Technische Universität München Arcisstr. 21, 80333 München Fon: +49 89 289 23511 yas...@tu... www.lkn.ei.tum.de<http://www.lkn.ei.tum.de> |
From: Miroslav L. <mli...@re...> - 2022-05-31 12:44:43
|
On Tue, May 31, 2022 at 12:02:33PM +0000, Deshpande, Yash wrote: > However, trying to reuse the pieces of code from phc2sys.c "read_phc" did not give satisfactory results. > I know that PPS loopback is probably the best way going forward - but i was wondering if there is any easier and more obvious way that I am missing out. You could compare the two clocks relative to the system clock using there calls of the PTP_SYS_OFFSET_EXTENDED ioctl, similarly to running phc_ctl eth0 cmp phc_ctl eth1 cmp phc_ctl eth0 cmp and comparing the mean offset from the first and third call with the offset from the second call. That should give you more stable measurements as the they will not be impacted by userspace, but there will likely still be some asymmetry of at least few nanoseconds due to PCIe, CPU and the I350 itself. If you decide to go with PPS timestamping and depending on how much you want to avoid asymmetries in your measurements, it might be better to have both ports as PPS input timestamping an external PPS signal instead of connecting one port as PPS output to the other as PPS input. -- Miroslav Lichvar |
From: Deshpande, Y. <yas...@tu...> - 2022-06-28 13:30:48
|
> However, trying to reuse the pieces of code from phc2sys.c "read_phc" did not give satisfactory results. Thanks a lot! I am now within a few hundred Nanos. > I know that PPS loopback is probably the best way going forward - but i was wondering if there is any easier and more obvious way that I am missing out. I would like to ask the second part of the question once again. I dont wish to synchronize the two ports. I know that their relative offset is constant as they are running on the same oscillator. This is also reported by the ptp4l. I would just like to know this offset without running ptp4l.Is there an easier way than PPS loopback? ________________________________ From: Miroslav Lichvar <mli...@re...> Sent: Tuesday, May 31, 2022 2:44:27 PM To: Deshpande, Yash Cc: lin...@li... Subject: Re: [Linuxptp-users] Finding the Fixed offset between two Ports of the same NIC. On Tue, May 31, 2022 at 12:02:33PM +0000, Deshpande, Yash wrote: > However, trying to reuse the pieces of code from phc2sys.c "read_phc" did not give satisfactory results. > I know that PPS loopback is probably the best way going forward - but i was wondering if there is any easier and more obvious way that I am missing out. You could compare the two clocks relative to the system clock using there calls of the PTP_SYS_OFFSET_EXTENDED ioctl, similarly to running phc_ctl eth0 cmp phc_ctl eth1 cmp phc_ctl eth0 cmp and comparing the mean offset from the first and third call with the offset from the second call. That should give you more stable measurements as the they will not be impacted by userspace, but there will likely still be some asymmetry of at least few nanoseconds due to PCIe, CPU and the I350 itself. If you decide to go with PPS timestamping and depending on how much you want to avoid asymmetries in your measurements, it might be better to have both ports as PPS input timestamping an external PPS signal instead of connecting one port as PPS output to the other as PPS input. -- Miroslav Lichvar |
From: Richard C. <ric...@gm...> - 2022-06-28 14:09:16
|
On Tue, Jun 28, 2022 at 01:30:32PM +0000, Deshpande, Yash wrote: > I would like to ask the second part of the question once again. I > dont wish to synchronize the two ports. I know that their relative > offset is constant as they are running on the same oscillator. This > is also reported by the ptp4l. I would just like to know this offset > without running ptp4l.Is there an easier way than PPS loopback? PPS signal is the best way. I think it is also "easy" because it removes the guess work. Thanks, Richard |
From: Deshpande, Y. <yas...@tu...> - 2022-06-29 14:29:47
|
> PPS signal is the best way. I think it is also "easy" because it removes the guesswork. Thanks a lot. Is there any source on how to enable the PPS output on the SDP pins and loop it back into the same NICs SDP inputs? My plan is this: 1) enable PPS output from port1 to SDP0 2) Then loopback a single wire from SDP0 of port1 to SDP0 of port2. 3) Run ts2phc for port2 in free-running mode. This should give me the fixed offset I mentioned in the first message of the thread. Also my two options are: ./ts2phc --free_running=1 -c enp2s0f0 -s enp2s0f1 ./ts2phc --free_running=1 -c enp2s0f0 -s generic but I am not sure which one is the correct one. Do I need to change my igb driver from the default one being able to enable pps input/output? Can step 1 be done by ts2phc or should I do it before running ts2phc? I tried a dry run of ts2phc and it failed with the following error: ts2phc[100692.637]: PTP_EXTTS_REQUEST2 failed: Invalid argument ts2phc[100692.637]: PTP_EXTTS_REQUEST2 failed: Invalid argument failed to arm PPS sinks ts2phc[100692.637]: PTP_EXTTS_REQUEST2 failed: Invalid argument is it because of the wrong igb driver or not having done step 1 or is it another problem altogether? Best Regards, Yash ________________________________ From: Richard Cochran <ric...@gm...> Sent: Tuesday, June 28, 2022 4:09:04 PM To: Deshpande, Yash Cc: Miroslav Lichvar; lin...@li... Subject: Re: [Linuxptp-users] Finding the Fixed offset between two Ports of the same NIC. On Tue, Jun 28, 2022 at 01:30:32PM +0000, Deshpande, Yash wrote: > I would like to ask the second part of the question once again. I > dont wish to synchronize the two ports. I know that their relative > offset is constant as they are running on the same oscillator. This > is also reported by the ptp4l. I would just like to know this offset > without running ptp4l.Is there an easier way than PPS loopback? PPS signal is the best way. I think it is also "easy" because it removes the guess work. Thanks, Richard |