Thread: [Linuxptp-users] linuxptp result doesn't match 1PPS measurement
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: Hamilton A. <ale...@gm...> - 2022-09-08 11:42:12
|
Hi: I got an issue that linuxptp result doesn't match 1PPS measurement. my board is acting as a slave, the calnex is acting as a master with reference clock. after ptp4l runs, result is below, looks pretty good: ptp4l[130166.661]: rms 1 max 2 freq -50 +/- 4 delay 9059 +/- 0 ptp4l[130167.661]: rms 1 max 1 freq -50 +/- 2 delay 9058 +/- 0 ptp4l[130168.662]: rms 1 max 2 freq -52 +/- 3 delay 9058 +/- 1 ptp4l[130169.661]: rms 1 max 3 freq -49 +/- 4 delay 9058 +/- 0 ptp4l[130170.661]: rms 1 max 2 freq -50 +/- 4 delay 9059 +/- 0 ptp4l[130171.662]: rms 1 max 2 freq -49 +/- 3 delay 9058 +/- 0 my board has 1PPS output, I connect it to the master and compared with reference PPS. however, the 1pps time error is around 40 NS, which means my board is ahead of the reference for about 40NS, which doesn't match the result dumped by ptp4l. anyone has met similar issue before? how to debug such issue? - 1ppsTE = (T1ppsMeasIngress – Dcable) - TRef https://calnexsolutions.atlassian.net/wiki/spaces/KB/pages/71991334/T-BC+Time+Error+Metrics Thanks Alex |
|
From: Hamilton A. <ale...@gm...> - 2022-09-08 12:10:18
|
Hi, Luigi: I am really thankful for your nice suggestions. 1. The delay for pps cable to calnex is already compensated in calnex configuration. 2. Yes, RX and TX path are asymmetry. the calnex can measure the T1, T4 and 2way time error, those time errors are only a few nano seconds, that means correct delays are compensated. https://www.calnexsol.cn/docman/techlib/timing-and-sync-lab/40-interpretation-of-time-error-results/file 3. the 1PPS is driven by zarlink z30772 DPLL. I will check whether is there any reclocking logic. Thanks Alex Luigi 'Comio' Mantellini <lui...@gm...> 于2022年9月8日周四 19:57写道： > Hi Alex, > > some guile line that I follow during my debug sessions: > > - Are you using a good cable-delay estimation for your cable? (Consider > ~5ns/m for classical eth cables) I suggest you to physically measure the > delay and place it as Dcable cell in Calnex configuration. > - Have you checked about any asymmetry between RX and TX paths? Can you > short-circuit your timestamper to check? You need to ask your FPGA and HW > experts. > - How is the 1PPS driven? Is there any reclocking logic? You need to ask > your FPGA-experts. > > > ciao > > luigi > > > Il giorno gio 8 set 2022 alle ore 13:44 Hamilton Alex < > ale...@gm...> ha scritto: > >> Hi: >> I got an issue that linuxptp result doesn't match 1PPS measurement. >> my board is acting as a slave, the calnex is acting as a master with >> reference clock. >> after ptp4l runs, result is below, looks pretty good: >> >> ptp4l[130166.661]: rms 1 max 2 freq -50 +/- 4 delay 9059 +/- >> 0 >> ptp4l[130167.661]: rms 1 max 1 freq -50 +/- 2 delay 9058 +/- >> 0 >> ptp4l[130168.662]: rms 1 max 2 freq -52 +/- 3 delay 9058 +/- >> 1 >> ptp4l[130169.661]: rms 1 max 3 freq -49 +/- 4 delay 9058 +/- >> 0 >> ptp4l[130170.661]: rms 1 max 2 freq -50 +/- 4 delay 9059 +/- >> 0 >> ptp4l[130171.662]: rms 1 max 2 freq -49 +/- 3 delay 9058 +/- >> 0 >> >> my board has 1PPS output, I connect it to the master and compared with >> reference PPS. >> however, the 1pps time error is around 40 NS, which means my board is >> ahead of the reference for about 40NS, which doesn't match the result >> dumped by ptp4l. >> >> anyone has met similar issue before? how to debug such issue? >> >> - >> >> 1ppsTE = (T1ppsMeasIngress – Dcable) - TRef >> >> >> https://calnexsolutions.atlassian.net/wiki/spaces/KB/pages/71991334/T-BC+Time+Error+Metrics >> >> Thanks >> Alex >> >> _______________________________________________ >> Linuxptp-devel mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel >> > > > -- > *Luigi 'Comio' Mantellini* > My Professional Profile <http://www.linkedin.com/in/comio> > > *"UNIX is very simple, it just needs a genius to understand its > simplicity." [cit.]* > > |
|
From: Miroslav L. <mli...@re...> - 2022-09-08 13:26:38
|
On Thu, Sep 08, 2022 at 07:41:53PM +0800, Hamilton Alex wrote: > ptp4l[130171.662]: rms 1 max 2 freq -49 +/- 3 delay 9058 +/- 0 > my board has 1PPS output, I connect it to the master and compared with > reference PPS. > however, the 1pps time error is around 40 NS, which means my board is > ahead of the reference for about 40NS, which doesn't match the result > dumped by ptp4l. ptp4l is just printing the measured offset. It doesn't know the actual error. A measured delay of 9 microseconds is huge. That's few kilometers of cable. What hardware do you use? Does it have PHY or MAC timestamping, and are those errors compensated? -- Miroslav Lichvar |
|
From: Hamilton A. <ale...@gm...> - 2022-09-09 00:42:09
|
Hi, Miroslav: I am using calnex to test ptp. calnex can mimic the long path delay so it is reasonable. I am using switch chip, it has MAC timestamping and rx_delay, tx_delay are compensated. Thanks Alex Miroslav Lichvar <mli...@re...> 于2022年9月8日周四 21:26写道： > On Thu, Sep 08, 2022 at 07:41:53PM +0800, Hamilton Alex wrote: > > ptp4l[130171.662]: rms 1 max 2 freq -49 +/- 3 delay 9058 > +/- 0 > > > my board has 1PPS output, I connect it to the master and compared with > > reference PPS. > > however, the 1pps time error is around 40 NS, which means my board is > > ahead of the reference for about 40NS, which doesn't match the result > > dumped by ptp4l. > > ptp4l is just printing the measured offset. It doesn't know the actual > error. > > A measured delay of 9 microseconds is huge. That's few kilometers of > cable. What hardware do you use? Does it have PHY or MAC timestamping, > and are those errors compensated? > > -- > Miroslav Lichvar > > |
|
From: Richard C. <ric...@gm...> - 2022-09-08 13:40:38
|
On Thu, Sep 08, 2022 at 07:41:53PM +0800, Hamilton Alex wrote: > however, the 1pps time error is around 40 NS, which means my board is > ahead of the reference for about 40NS, which doesn't match the result > dumped by ptp4l. > > anyone has met similar issue before? how to debug such issue? This is likely due to path asymmetry. HTH, Richard |
|
From: Richard C. <ric...@gm...> - 2022-09-08 13:43:58
|
On Thu, Sep 08, 2022 at 06:40:26AM -0700, Richard Cochran wrote: > On Thu, Sep 08, 2022 at 07:41:53PM +0800, Hamilton Alex wrote: > > > however, the 1pps time error is around 40 NS, which means my board is > > ahead of the reference for about 40NS, which doesn't match the result > > dumped by ptp4l. > > > > anyone has met similar issue before? how to debug such issue? > > This is likely due to path asymmetry. Oh, and Miroslav is correct, 9 usec path delay is huge. It should be only 5 ns per meter of cable. Good luck, Richard |
|
From: Richard C. <ric...@gm...> - 2022-09-08 13:46:21
|
On Thu, Sep 08, 2022 at 01:56:59PM +0200, Luigi 'Comio' Mantellini wrote: > - How is the 1PPS driven? Is there any reclocking logic? You need to ask > your FPGA-experts. +1 The circuit the produces the 1 PPS could well delay the signal by ten or more nanoseconds. Thanks, Richard |
|
From: Hamilton A. <ale...@gm...> - 2022-09-09 00:45:40
|
Hi, Richard: I am not quite understand. I am using Calnex master-->board slave, if the linuxptp print out is correct, that means local clock has the same frequency and phase as master clock, then the 1PPS out should near the reference 1PPS. why path asymmetry would affect the 1PPS out? Thanks Alex Richard Cochran <ric...@gm...> 于2022年9月8日周四 21:40写道： > On Thu, Sep 08, 2022 at 07:41:53PM +0800, Hamilton Alex wrote: > > > however, the 1pps time error is around 40 NS, which means my board is > > ahead of the reference for about 40NS, which doesn't match the result > > dumped by ptp4l. > > > > anyone has met similar issue before? how to debug such issue? > > This is likely due to path asymmetry. > > HTH, > Richard > |
|
From: Richard C. <ric...@gm...> - 2022-09-09 02:50:23
|
On Fri, Sep 09, 2022 at 08:45:19AM +0800, Hamilton Alex wrote: > Hi, Richard: > I am not quite understand. I am using Calnex master-->board slave, if the > linuxptp print out is correct, that means local clock > has the same frequency and phase as master clock, then the 1PPS out should > near the reference 1PPS. > > why path asymmetry would affect the 1PPS out? You reported a 40 nanosecond phase offset. One possible cause is path asymmetry. The PTP assumes the Tx and Rx transmission delays are exactly equal. However, this is almost never true. Any real asymmetry results in a phase offset that is uncorrectable by the PTP. Because your 40 ns phase offset is very small, you might very well have path asymmetry somewhere in your system. For example, your PHY might delay frames longer on Tx than on Rx. HTH, Richard |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X