Thread: [Linuxptp-users] Want to reduce offset (which is distance dependant) between boundary clocks.
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
From: aniket <an...@gm...> - 2016-01-15 10:55:41
|
Hi...very good afternoon to all. Myself Aniket Hendre, project engineer C from National Centre for Radio Astrophysics, India. I am synchronising two boundary clocks using ptp4l. I found that the offset at the slave PHY clock from master PHY clock varies with respect to distance between these clocks. In my first experiment, master and slave are 2 Km away from each other. In this case I got offset at slave PHY clock around 50 nano second. In second experiment I relocate my slave around 20 Km from master where I got offset of 150 nano seconds. Ideally the offset between PHY clocks should remain constant though we are varying distance between them (correct me if I am wrong). For both experiments mentioned above I am issuing following common command ptp4l -i eth1 -m. I have connected these two machine using fibre optic cable with media converter on both ends. My both ethernet ports are supporting IEEE1588. Do we need to specify any parameter (which is distance dependant) while issuing above command? Because there are many PROGRAM AND CLOCK OPTIONS in ptp4l. Do we need to set any specific option? Please help. Thanks in advance Aniket Hendre |
From: Richard C. <ric...@gm...> - 2016-01-15 15:10:57
|
On Fri, Jan 15, 2016 at 03:51:57PM +0530, aniket wrote: > In my first experiment, master and slave are 2 Km away from each other. > In this case I got offset at slave PHY clock around 50 nano second. > > In second experiment I relocate my slave around 20 Km from master where > I got offset of 150 nano seconds. So you are checking against GPS, right? > Ideally the offset between PHY clocks should remain constant though we > are varying distance between them (correct me if I am wrong). If the system is properly calibrated, then the offset should be minimal, and the difference in distance should be reflected in the path delay. > Do we need to specify any parameter (which is distance dependant) while > issuing above command? Because there are many PROGRAM AND CLOCK OPTIONS > in ptp4l. Do we need to set any specific option? We do have options to calibrate the system: delayAsymmetry - corrects for any asymmetry between the Rx and Tx paths egressLatency - corrects the transmit latency at the MAC/PHY ingressLatency - corrects the receive latency at the MAC/PHY What you observe sounds like an asymmetry. If it is, then it is surprising to me that the asymmetry grows with distance. Then again, I don't know anything about your equipment, and so maybe this is simply a property of your fibre optic links. HTH, Richard |
From: Richard C. <ric...@gm...> - 2016-01-20 21:13:45
|
On Wed, Jan 20, 2016 at 02:13:35PM +0100, Richard Cochran wrote: > On Wed, Jan 20, 2016 at 12:13:13PM +0100, Miroslav Lichvar wrote: > > I would like to try this. I don't have an i210 card nearby, but I > > assume it requires some soldering. Do you have any pictures that show > > where the connection should go and how big is the pad? > > The card has a 6 pin header, so no soldering is required. I couldn't > find any documentation, and so I ohm'ed the pins out to the chip. > I'll post a photo and my notes. Rich Schmidt sent me this photo he had already made. http://linuxptp.sourceforge.net/i210/i210-SDPs.jpg The "Software Defined Pins" (SDP) are on the right side of the 6 pin header. On the left side you have one 3.3V pin and two ground pins. The signal level is CMOS, and there is no ESD protection at all. Be careful! The SDPs can be programmed as inputs (time stamps on signal edges) or as outputs (periodic signals). You can do some interesting things with them. I once made a BC with 3 cards on one mother board, letting the "lead" card send a 1 PPS to the other two, using the external time stamps to lock to the lead card. HTH, Richard |
From: Miroslav L. <mli...@re...> - 2016-01-21 16:25:59
|
On Wed, Jan 20, 2016 at 10:13:33PM +0100, Richard Cochran wrote: > Rich Schmidt sent me this photo he had already made. > > http://linuxptp.sourceforge.net/i210/i210-SDPs.jpg > > The "Software Defined Pins" (SDP) are on the right side of the 6 pin > header. On the left side you have one 3.3V pin and two ground pins. > > The signal level is CMOS, and there is no ESD protection at all. > Be careful! Great, thanks for the information. I'll see if I can get an i210 and connect a GPS PPS signal to it. The PPS is at the TTL level so I guess I just need a voltage divider. -- Miroslav Lichvar |
From: Xavier B. <xav...@fr...> - 2016-01-18 13:34:22
|
Hi Aniket, Le vendredi 15 janvier 2016 à 15:51 +0530, aniket a écrit : > Hi...very good afternoon to all. > > Myself Aniket Hendre, project engineer C from National Centre for Radio > Astrophysics, India. > > I am synchronising two boundary clocks using ptp4l. I found that the > offset at the slave PHY clock from master PHY clock varies with respect > to distance between these clocks. > > In my first experiment, master and slave are 2 Km away from each other. > In this case I got offset at slave PHY clock around 50 nano second. Over such a distance you may be interested in https://en.wikipedia.org/wiki/The_White_Rabbit_Project Regards, Xav |
From: Richard C. <ric...@gm...> - 2016-01-19 09:38:39
|
On Tue, Jan 19, 2016 at 09:47:40AM +0530, Aniket Hendre wrote: > Richard I have a server class machine (Dell R720) which is locked to my > GPS10RBN frequency and time standards unit using Network Time Protocol > (NTP). Simultaneously I have 1PPS out from GPS10RBN which I have connected > to my server class machine. NTP daemon has been configured on server class > machine to use this 1PPS by adding following line in /etc/ntp.conf. > > server 127.127.22.0 minpoll 4 maxpoll 4 > fudge 127.127.22.0 refid PPS flag3 1 flag4 1 time1 -0.060 Do you have a GPS at the master and at the slaves nodes, or only at the master? > So I do believe that my Dell R720 is now behaving like a PTP grandmaster. > (correct me if I am wrong). Well, NTP will correct the Linux system time, but not the time in your PHC device. What MAC/PHY hardware are you using? How have you configured ptp4l and phc2sys on each node? > I am now trying to first synchronise two PHY clock by running ptp4l, where > I have observed offset changes w.r.t distance. What do you mean by "observed offset changes"? Do you mean perhaps the observed jitter? ptp4l will always reduce the observed offset to zero, even in the presence of asymmetry. Thanks, Richard |
From: Richard C. <ric...@gm...> - 2016-01-19 16:12:25
|
On Tue, Jan 19, 2016 at 05:30:10PM +0530, Aniket Hendre wrote: > *phc2sys -s CLOCK_REALTIME -c eth1 -m -O -35 * FYI, you should be aware that this method reads time stamps over the PCIe interface. Because of the delay and uncertainty in reading single values over PCIe, this introduces a time error on the order of microseconds. You can avoid this error by directly feeding the 1-PPS into PTP card that supports external time stamps (like the Intel i210). Then you can write a little servo to discipline the PTP card to the GPS clock. > I mean to say that I am observing offset at slave side and noticed that the > offset from master is large for large distance between master and slave. Not sure what you mean. Can you post the client side ptp4l logs for both cases? Thanks, Richard |
From: Richard C. <ric...@gm...> - 2016-01-20 10:56:42
|
On Wed, Jan 20, 2016 at 02:35:26PM +0530, Aniket Hendre wrote: > So you want to say that instead of steer phy clock of master to synchronize > with its system clock, it is better to steer phy clock by using direct PPS > feeding through intel i210 card. So I don't need to feed PPS to my master > machine through serial port (correct me if i am wrong). Yes, that is the idea. The i210 has two input pins at CMOS level, and the most recent Linux kernels support time stamps of external signals in the i210 driver. (It does not solve your 2/20 km problem, though.) Thanks, Richard |
From: Miroslav L. <mli...@re...> - 2016-01-20 11:13:21
|
On Wed, Jan 20, 2016 at 11:56:31AM +0100, Richard Cochran wrote: > Yes, that is the idea. The i210 has two input pins at CMOS level, and > the most recent Linux kernels support time stamps of external signals > in the i210 driver. I would like to try this. I don't have an i210 card nearby, but I assume it requires some soldering. Do you have any pictures that show where the connection should go and how big is the pad? -- Miroslav Lichvar |
From: Richard C. <ric...@gm...> - 2016-01-20 13:13:46
|
On Wed, Jan 20, 2016 at 12:13:13PM +0100, Miroslav Lichvar wrote: > I would like to try this. I don't have an i210 card nearby, but I > assume it requires some soldering. Do you have any pictures that show > where the connection should go and how big is the pad? The card has a 6 pin header, so no soldering is required. I couldn't find any documentation, and so I ohm'ed the pins out to the chip. I'll post a photo and my notes. Thanks, Richard |
From: Keller, J. E <jac...@in...> - 2016-01-20 17:23:24
|
These should be documented in the data sheet. But I believe what's in the kernel is correct. Regards, Jake On Wed, 2016-01-20 at 14:13 +0100, Richard Cochran wrote: > On Wed, Jan 20, 2016 at 12:13:13PM +0100, Miroslav Lichvar wrote: > > I would like to try this. I don't have an i210 card nearby, but I > > assume it requires some soldering. Do you have any pictures that > > show > > where the connection should go and how big is the pad? > > The card has a 6 pin header, so no soldering is required. I couldn't > find any documentation, and so I ohm'ed the pins out to the chip. > I'll post a photo and my notes. > > Thanks, > Richard > > > > ------------------------------------------------------------------- > ----------- > Site24x7 APM Insight: Get Deep Visibility into Application > Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |