Thread: [Linuxptp-users] clock_nanosleep on /dev/ptpX
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: Koehrer M. (ETAS/ESW5) <mat...@et...> - 2014-02-19 14:20:04
|
Hi all, using linuxptp I can obtain a really good synchronization between multiple PCs. I want to run an application on each of the PCs, the execution should be synchronized. My idea was to use clock_nanosleep on the PTP clock (similar as the testptp does for getting the PTP clock time) using absolute time stamps to synchronize the running threads. However this is not working as the PTP clocks do not have nsleep implemented in the kernel (kernel 3.2.54-rt77). Does this mean that I have to use phc2sys to use the system clock again? Or is there any way to work directly on the PTP clock? Thanks for all hints! Best Regards Mathias |
|
From: Ledda W. E. <Wil...@it...> - 2014-02-19 14:39:53
|
On PTP clock you can't use nanosleep and neither you can't create timers. Once that your system time is synchronize with phc2sys you can use CLOCK_REALTIME or CLOCK_MONOTONIC to do this kind of things. William -----Original Message----- From: Koehrer Mathias (ETAS/ESW5) [mailto:mat...@et...] Sent: 19 February 2014 15:20 To: lin...@li... Subject: [Linuxptp-users] clock_nanosleep on /dev/ptpX Hi all, using linuxptp I can obtain a really good synchronization between multiple PCs. I want to run an application on each of the PCs, the execution should be synchronized. My idea was to use clock_nanosleep on the PTP clock (similar as the testptp does for getting the PTP clock time) using absolute time stamps to synchronize the running threads. However this is not working as the PTP clocks do not have nsleep implemented in the kernel (kernel 3.2.54-rt77). Does this mean that I have to use phc2sys to use the system clock again? Or is there any way to work directly on the PTP clock? Thanks for all hints! Best Regards Mathias ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Richard C. <ric...@gm...> - 2014-02-19 14:41:36
|
On Wed, Feb 19, 2014 at 02:19:41PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > I want to run an application on each of the PCs, the execution should be synchronized. Do you have specific performance requirements? > Does this mean that I have to use phc2sys to use the system clock again? Yes. > Or is there any way to work directly on the PTP clock? No. The dynamic posix clock implementation does allow the (future) possibility of implementing timers directly on the PHC devices. It would mean a fair amount of kernel work to actually make this work. I might do it one day, but so far I haven't had a really compelling reason to do so. Probably using the Linux system clock (and phc2sys) will be good enough most of the time. It would be interesting to find out whether that is true for your own application. Thanks, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2014-02-19 14:58:50
|
> I might do it one day, but so far I haven't had a really compelling reason to do so. Probably using the Linux system clock (and phc2sys) will be good enough > most of the time. It would be interesting to find out whether that is true for your own application. Richard, Think about this "simple" but very interesting problem. System time is not monotonic (assuming it is in UTC), PTP time yes (assuming it is TAI). In a real time control system you could have the need to make a "wait_until" or to execute some functions in a very well-defined time in spite of any clock adjustment made to recover some UTC leap second event. This could be a valid reason to implement these features on a PHC? William -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: 19 February 2014 15:41 To: Koehrer Mathias (ETAS/ESW5) Cc: lin...@li... Subject: Re: [Linuxptp-users] clock_nanosleep on /dev/ptpX On Wed, Feb 19, 2014 at 02:19:41PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > I want to run an application on each of the PCs, the execution should be synchronized. Do you have specific performance requirements? > Does this mean that I have to use phc2sys to use the system clock again? Yes. > Or is there any way to work directly on the PTP clock? No. The dynamic posix clock implementation does allow the (future) possibility of implementing timers directly on the PHC devices. It would mean a fair amount of kernel work to actually make this work. > I might do it one day, but so far I haven't had a really compelling reason to do so. Probably using the Linux system clock (and phc2sys) will be good enough > most of the time. It would be interesting to find out whether that is true for your own application. Thanks, Richard ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Ledda W. E. <Wil...@it...> - 2014-02-19 14:42:05
|
To be precise CLOCK_REALTIME is synchronized with your PTP clock using phc2sys, CLOCK_MONOTINIC not... William -----Original Message----- From: Ledda William EXT [mailto:Wil...@it...] Sent: 19 February 2014 15:40 To: Koehrer Mathias (ETAS/ESW5); lin...@li... Subject: Re: [Linuxptp-users] clock_nanosleep on /dev/ptpX On PTP clock you can't use nanosleep and neither you can't create timers. Once that your system time is synchronize with phc2sys you can use CLOCK_REALTIME or CLOCK_MONOTONIC to do this kind of things. William -----Original Message----- From: Koehrer Mathias (ETAS/ESW5) [mailto:mat...@et...] Sent: 19 February 2014 15:20 To: lin...@li... Subject: [Linuxptp-users] clock_nanosleep on /dev/ptpX Hi all, using linuxptp I can obtain a really good synchronization between multiple PCs. I want to run an application on each of the PCs, the execution should be synchronized. My idea was to use clock_nanosleep on the PTP clock (similar as the testptp does for getting the PTP clock time) using absolute time stamps to synchronize the running threads. However this is not working as the PTP clocks do not have nsleep implemented in the kernel (kernel 3.2.54-rt77). Does this mean that I have to use phc2sys to use the system clock again? Or is there any way to work directly on the PTP clock? Thanks for all hints! Best Regards Mathias ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Koehrer M. (ETAS/ESW5) <mat...@et...> - 2014-02-19 15:03:52
|
Hi William
>
> To be precise CLOCK_REALTIME is synchronized with your PTP clock using
> phc2sys, CLOCK_MONOTINIC not...
According to "man clock_gettime"
CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time since some unspecified
starting point. This clock is not affected by discontinuous jumps in the sys-
tem time (e.g., if the system administrator manually changes the clock), but is
affected by the incremental adjustments performed by adjtime(3) and NTP.
I think that phc2sys uses clock_adjtime() to modify the clock.
My thought was that this should effect CLOCK_REALTIME and CLOCK_MONOTONIC...
But likely I am wrong.
Regards
Mathias
|
|
From: Richard C. <ric...@gm...> - 2014-02-19 15:12:14
|
On Wed, Feb 19, 2014 at 03:03:41PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > > I think that phc2sys uses clock_adjtime() to modify the clock. > My thought was that this should effect CLOCK_REALTIME and CLOCK_MONOTONIC... > But likely I am wrong. Both CLOCK_REALTIME and CLOCK_MONOTONIC use the same frequency, but CLOCK_MONOTONIC starts with zero at boot time, and it never jumps. So you cannot use it to start tasks on two different machines at the same moment in time. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2014-02-19 15:08:15
|
On Wed, Feb 19, 2014 at 02:58:40PM +0000, Ledda William EXT wrote: > > I might do it one day, but so far I haven't had a really compelling reason to do so. Probably using the Linux system clock (and phc2sys) will be good enough > > most of the time. It would be interesting to find out whether that is true for your own application. > > Richard, > Think about this "simple" but very interesting problem. System time is not monotonic (assuming it is in UTC), PTP time yes (assuming it is TAI). In a real time control system you could have the need to make a "wait_until" or to execute some functions in a very well-defined time in spite of any clock adjustment made to recover some UTC leap second event. This could be a valid reason to implement these features on a PHC? Well, now that we have CLOCK_TAI in Linux, that takes of the leap second issue. I agree that it would be nice to have the PHC timers, but considering the scheduling latency on typical Linux systems (even RT), I do think using the system CLOCK_REALTIME or CLOCK_TAI will be good enough. In fact, timers built off of PHC devices which are PCIe cards will probably have *worse* latency than using system timers. I would expect that only register based SoC devices (like the gianfar) would bring any benefit at all. Thanks, Richard |
|
From: Julien H. <ju...@ya...> - 2014-02-19 16:03:54
|
I wanted to send packets bursts on gigabit ports spread on numerous computers at precise dates specified in a common scenario. I could achieve a ~200ns jitter among packets in a burst by synchronizing the computers (only two at this time...) with a slightly modified ptp4l and phc2sys (dedicated gbe links for synchronization) and a task in a dedicated module which waits on msleep_interruptible, usleep_range, ndelay or a polling with getnstimeofday depending on the interval between the different dates in scenario. This task triggers the packet sending at the date wanted. I rapidly gave up timers for small intervals because of the scheduling latency. Julien. ________________________________ De : Richard Cochran <ric...@gm...> À : Ledda William EXT <Wil...@it...> Cc : "lin...@li..." <lin...@li...> Envoyé le : Mercredi 19 février 2014 16h08 Objet : Re: [Linuxptp-users] clock_nanosleep on /dev/ptpX On Wed, Feb 19, 2014 at 02:58:40PM +0000, Ledda William EXT wrote: > > I might do it one day, but so far I haven't had a really compelling reason to do so. Probably using the Linux system clock (and phc2sys) will be good enough > > most of the time. It would be interesting to find out whether that is true for your own application. > > Richard, > Think about this "simple" but very interesting problem. System time is not monotonic (assuming it is in UTC), PTP time yes (assuming it is TAI). In a real time control system you could have the need to make a "wait_until" or to execute some functions in a very well-defined time in spite of any clock adjustment made to recover some UTC leap second event. This could be a valid reason to implement these features on a PHC? Well, now that we have CLOCK_TAI in Linux, that takes of the leap second issue. I agree that it would be nice to have the PHC timers, but considering the scheduling latency on typical Linux systems (even RT), I do think using the system CLOCK_REALTIME or CLOCK_TAI will be good enough. In fact, timers built off of PHC devices which are PCIe cards will probably have *worse* latency than using system timers. I would expect that only register based SoC devices (like the gianfar) would bring any benefit at all. Thanks, Richard ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Ledda W. E. <Wil...@it...> - 2014-02-21 08:50:53
|
Richard, > Well, now that we have CLOCK_TAI in Linux, that takes of the leap second issue. Which is the kernel version that include CLOCK_TAI? Thanks William -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: 19 February 2014 16:08 To: Ledda William EXT Cc: Koehrer Mathias (ETAS/ESW5); lin...@li... Subject: Re: [Linuxptp-users] clock_nanosleep on /dev/ptpX On Wed, Feb 19, 2014 at 02:58:40PM +0000, Ledda William EXT wrote: > > I might do it one day, but so far I haven't had a really compelling > > reason to do so. Probably using the Linux system clock (and phc2sys) will be good enough most of the time. It would be interesting to find out whether that is true for your own application. > > Richard, > Think about this "simple" but very interesting problem. System time is not monotonic (assuming it is in UTC), PTP time yes (assuming it is TAI). In a real time control system you could have the need to make a "wait_until" or to execute some functions in a very well-defined time in spite of any clock adjustment made to recover some UTC leap second event. This could be a valid reason to implement these features on a PHC? Well, now that we have CLOCK_TAI in Linux, that takes of the leap second issue. I agree that it would be nice to have the PHC timers, but considering the scheduling latency on typical Linux systems (even RT), I do think using the system CLOCK_REALTIME or CLOCK_TAI will be good enough. In fact, timers built off of PHC devices which are PCIe cards will probably have *worse* latency than using system timers. I would expect that only register based SoC devices (like the gianfar) would bring any benefit at all. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2014-02-21 08:58:31
|
On Fri, Feb 21, 2014 at 08:50:43AM +0000, Ledda William EXT wrote: > Which is the kernel version that include CLOCK_TAI? v3.10 HTH, Richard |
|
From: Richard C. <ric...@gm...> - 2014-02-21 09:03:31
|
On Fri, Feb 21, 2014 at 09:58:12AM +0100, Richard Cochran wrote: > On Fri, Feb 21, 2014 at 08:50:43AM +0000, Ledda William EXT wrote: > > Which is the kernel version that include CLOCK_TAI? > > v3.10 But there was an early bug. Make sure you use the latest stable kernel. Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2014-02-21 09:11:42
|
On Fri, Feb 21, 2014 at 10:03:12AM +0100, Richard Cochran wrote: > On Fri, Feb 21, 2014 at 09:58:12AM +0100, Richard Cochran wrote: > > On Fri, Feb 21, 2014 at 08:50:43AM +0000, Ledda William EXT wrote: > > > Which is the kernel version that include CLOCK_TAI? > > > > v3.10 > > But there was an early bug. Make sure you use the latest stable > kernel. Hm, should we set the kernel TAI offset (ADJ_TAI) in ptp4l and phc2sys? -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2014-02-21 09:29:28
|
On Fri, Feb 21, 2014 at 10:11:33AM +0100, Miroslav Lichvar wrote: > > Hm, should we set the kernel TAI offset (ADJ_TAI) in ptp4l > and phc2sys? I think we should if: 1. the node is slaved to a GM 2. the GM timescale is PTP and is traceable 3. the reported TAI offset differs from the kernel's Thanks, 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