linuxptp-users Mailing List for linuxptp (Page 136)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
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: 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: 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: 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: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:24:53
|
On Wed, Feb 19, 2014 at 02:08:14PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > With my kernel 3.2 there is no config option CONFIG_NO_HZ_IDLE. > I have only "CONFIG_NO_HZ". Is this also harmful? Yes, that is the old name. Use nohz=off as the others have suggested. Thanks, Richard |
|
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:16:46
|
Yes, disable it adding "nohz=off" at kernel command line and you can see the difference. Phc2sys will report more stable and very low delay (I see hundreds of nanoseconds on my platforms) -----Original Message----- From: Koehrer Mathias (ETAS/ESW5) [mailto:mat...@et...] Sent: 19 February 2014 15:08 To: Richard Cochran Cc: lin...@li... Subject: Re: [Linuxptp-users] Status file of achieved time synchronization Hi Richard! > BTW, in case you did not see the recent discussion about it, you > should know that the Linux kernel option CONFIG_NO_HZ_IDLE is harmful > to your use case. I recommend to either disable this at compile time > or to add "nohz=off" to your kernel command line. Thanks for the hint. With my kernel 3.2 there is no config option CONFIG_NO_HZ_IDLE. I have only "CONFIG_NO_HZ". Is this also harmful? 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: Julien H. <ju...@ya...> - 2014-02-19 14:16:11
|
HiMathias, Only by using the nohz=off option in the kernel command line, the delay in phc2sys dropped from several microseconds to a hundred nanoseconds. Julien. ________________________________ De : Koehrer Mathias (ETAS/ESW5) <mat...@et...> À : Richard Cochran <ric...@gm...> Cc : "lin...@li..." <lin...@li...> Envoyé le : Mercredi 19 février 2014 15h08 Objet : Re: [Linuxptp-users] Status file of achieved time synchronization Hi Richard! > BTW, in case you did not see the recent discussion about it, you > should know that the Linux kernel option CONFIG_NO_HZ_IDLE is harmful > to your use case. I recommend to either disable this at compile time > or to add "nohz=off" to your kernel command line. Thanks for the hint. With my kernel 3.2 there is no config option CONFIG_NO_HZ_IDLE. I have only "CONFIG_NO_HZ". Is this also harmful? 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: Koehrer M. (ETAS/ESW5) <mat...@et...> - 2014-02-19 14:08:34
|
Hi Richard! > BTW, in case you did not see the recent discussion about it, you > should know that the Linux kernel option CONFIG_NO_HZ_IDLE is harmful > to your use case. I recommend to either disable this at compile time > or to add "nohz=off" to your kernel command line. Thanks for the hint. With my kernel 3.2 there is no config option CONFIG_NO_HZ_IDLE. I have only "CONFIG_NO_HZ". Is this also harmful? Regards Mathias |
|
From: Richard C. <ric...@gm...> - 2014-02-18 17:38:36
|
On Thu, Feb 13, 2014 at 01:01:20PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > > What I do not see fully clear is the role of phc2sys. > It is used to synchronize the PTP clock from my Ethernet device to the Linux system clock. > There is likely a drift/offset between this PTP clock and the Linux system clock. > This drift/offset has to be corrected by the phc2sys tool. BTW, in case you did not see the recent discussion about it, you should know that the Linux kernel option CONFIG_NO_HZ_IDLE is harmful to your use case. I recommend to either disable this at compile time or to add "nohz=off" to your kernel command line. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2014-02-18 15:33:58
|
On Tue, Feb 18, 2014 at 02:48:08PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > Hi all, > > we want to synchronize a couple of PCs. These PCs have to run for a couple of hours in a synchronized way. > We do not have a proper grandmaster clock, one of the PCs plays this role. > We use suitable Ethernet adapters (Intel IGB driver) to use the hardware time stamping. > In this setup the usage of the separate PTP time scale (with the offset of 35s against UTC) is really confusing. > Is it possible to force ptp4l to use UTC also for hardware time stamping e.g. by using an option (in the config file)? I don't see an easy way to support this. Both the ptp4l and phc2sys programs have code handling UTC-TAI conversion, but only for the expected used cases. If you have a real PTP device, the assumption is that you are also using the PTP timescale. We only use UTC when absolutely required, for software time stamps. You *could* try and hack this in, but I think it would be easier just to maintain the PTP timescale in the PHC device. Recent Linux kernels offer CLOCK_TAI, so you might consider using that instead of CLOCK_REALTIME in your application. Sorry, Richard |
|
From: Koehrer M. (ETAS/ESW5) <mat...@et...> - 2014-02-18 14:48:26
|
Hi all, we want to synchronize a couple of PCs. These PCs have to run for a couple of hours in a synchronized way. We do not have a proper grandmaster clock, one of the PCs plays this role. We use suitable Ethernet adapters (Intel IGB driver) to use the hardware time stamping. In this setup the usage of the separate PTP time scale (with the offset of 35s against UTC) is really confusing. Is it possible to force ptp4l to use UTC also for hardware time stamping e.g. by using an option (in the config file)? That would ease everything dramatically! Thanks for any hints on that! Regards Mathias |
|
From: Richard C. <ric...@gm...> - 2014-02-17 17:44:45
|
On Mon, Feb 17, 2014 at 02:21:10PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > > You can simply do the same as in the slave case. > > > > phc2sys -s /dev/ptp -w > > > > The grand master node will adjust its system time to the free running > > PTP Hardware Clock. You will want to set the correct time in the PHC > > before doing this! > OK that makes sense! Which tool can I use to set the correct time in the PHC before starting phc2sys? > Can I use phc2sys or is there another tool required for this? > I assume, in this case I have to consider the 35s offset... One easy way would be to use the testptp program from Documentation/ptp in the Linux kernel sources. You could do testptp -s # set the ptp clock time from the system time followed by testptp -t val # shift the ptp clock time by 'val' seconds in order to set the correct UTC offset. If you need something more fancy than that, then you can always write a little C program. > phc2sys is responsible to adapt the system clock, thus I'd expected > phc2sys to deliver this information somehow. However I do not find > anything like that in the code or man page. The phc2sys does not have a management interface like ptp4l. It can place summary statistics in the syslog or on stdout/stderr. So you would have to grep/tail this from the syslog or redirect the output into a fifo. You could script a file like the one you first mentioned. For example: while [ 1 ]; do grep phc2sys /var/log/syslog | grep rms | tail -n 1 > /tmp/status sleep 2 done I don't know what your timing requirements are, but be beware that the phc2sys output is only an estimate, and there may be an additional offset between the Linux system time and the PHC. HTH, Richard |
|
From: Koehrer M. (ETAS/ESW5) <mat...@et...> - 2014-02-17 14:21:26
|
Hi Richard, thanks for the support! > From: Richard Cochran > Sent: Friday, February 14, 2014 9:35 PM > > Or how do I have to call "phc2sys" in the situation when I do not know if the > PC will be master or not? > > You can simply do the same as in the slave case. > > phc2sys -s /dev/ptp -w > > The grand master node will adjust its system time to the free running > PTP Hardware Clock. You will want to set the correct time in the PHC > before doing this! OK that makes sense! Which tool can I use to set the correct time in the PHC before starting phc2sys? Can I use phc2sys or is there another tool required for this? I assume, in this case I have to consider the 35s offset... One thing that is still not clear to me is how to get the accuracy of the local clock in relation to the PTP master clock. Using pmc I can get the drift/offset of my local PHC device in relation to the PTP master clock. However I did not understand yet how I can retrieve the current drift/offset of my system clock (CLOCK_REALTIME) in relation to the PTP master clock. As my application runs using the system clock I have to ensure that the offset/drift is small enough to be able to start the application. phc2sys is responsible to adapt the system clock, thus I'd expected phc2sys to deliver this information somehow. However I do not find anything like that in the code or man page. Thanks for some hints on that. Regards Mathias |
|
From: Keller, J. E <jac...@in...> - 2014-02-14 21:20:43
|
Excellent. Thanks Richard! Regards, Jake On Fri, 2014-02-14 at 21:09 +0100, Richard Cochran wrote: > Dear linuxptp users and developers, > > I am happy to announce the version 1.4 of linuxptp. This release comes > a good six months since the previous one. I have pushed out a v1.4 tag > and released a tar ball on SF. > > Once again, my thanks go out to the contributors, Delio, Jacob, Ken, > Miroslav, and Stephan. > > The short log is appended, below. > > Enjoy, > Richard > > > Delio Brignoli (4): > Do not qualify announce messages with stepsRemoved >= 255 > Set sync timeout only on port_synchronize() > Reset pdr_missing early in port_nrate_calculate(), implement ratio_valid flag > pmc: support retrieving neighborPropDelayThresh and asCapable using management interface > > Jacob Keller (2): > missing: add onestep sync to missing.h > sk: update error message for Tx timestamp polling > > Ken ICHIKAWA (1): > phc2sys: Fix lower bound value of update_rate > > Miroslav Lichvar (23): > Use freeifaddrs() to free data from getifaddrs(). > Fix port numbering in clock log messages. > Reset delay timer when switching to P2P delay mechanism. > Don't try to forward messages to faulty UDS port. > Ignore delay_resp messages from foreign masters. > Don't calculate delay with old master's sync time stamp. > Add reset function to servo. > Add clock sanity check. > Add random delay to announce timeout. > Drop tmtab module. > Make random() more random between machines. > Add modular filter interface. > Add median filter. > Add options to configure delay filter. > Adjust tick length with system clock. > Fix drift calculation in PI servo with large values. > Clarify c1, c2, c3 in negative path delay log message. > Change level of negative path delay messages to debug. > Print current frequency when PI servo is in unlocked state. > phc2sys: Mention that PPS output needs to be enabled without -s. > Clarify units used in clock stepping constants. > Set printf format attribute for print(). > Fix new -Wformat warnings. > > Richard Cochran (27): > Inhibit lost link recovery in P2P mode. > Enforce the absolute lower limit for the announce receipt timeout. > Rename the timer for sending sync messages. > Add a timer implementing the sync receive timeout. > Add a configuration file option for the sync receive timeout. > Announce master ambitions right away. > Add an optional extra check on sync and follow up message ordering. > Add a configuration file option for the extra sync-fup check. > Add missing semicolon to enumeration. > Merge the gPTP sync timeout branch. > Make the CFLAGS more robust. > Convert the hard coded UDS server path into a variable. > Introduce a configuration file option for the server's UDS address. > pmc: add a command line option to select the server's UDS address. > Extend the interface name length to allow any UDS address. > pmc: bring the man page more up to date. > Merge the configurable UDS server path branch. > Introduce the gmCapable flag for use with 802.1AS clocks. > Inhibit sync messages from unwilling 802.1AS ports. > Add a configuration file option for the 802.1AS gmCapable flag. > Merge Miroslav's random PTP timeout branch. > clock: add missing call to clockcheck_destroy. > Fix filter allocation failure on the UDS port. > Simplify the text of the driver support matrix in the readme file. > uds: take the interface data off the stack. > uds: disable the accidentally enabled announce timer. > Version 1.4 > > Stephan Gatzka (2): > Make udp_physical_addr() and udp_protocol_addr() static. > Make functions and structs dealing with string literals const correct. > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Linuxptp-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel |
|
From: Richard C. <ric...@gm...> - 2014-02-14 20:35:09
|
On Thu, Feb 13, 2014 at 01:01:20PM +0000, Koehrer Mathias (ETAS/ESW5) wrote:
> What kind of information do I get when I call the 'pmc" management client?
> Is it the drift/offset of the PTP clock (Ethernet) or is it the drift/offset of my Linux system clock?
It is the offset with respect to the PTP master. In the case of
software time stamping, this is also the drift of the Linux system
clock WRT the PTP master. Using hardware time stamping, this is the
drift of the PTP hardware clock.
> When I use a PC as PTP master, I have to call phc2sys like
> # phc2sys -c /dev/ptp -s CLOCK_REALTIME -w
I would only do this if you also have "free_running 1" in the
configuration file (and your system time is managed by NTP).
> Or how do I have to call "phc2sys" in the situation when I do not know if the PC will be master or not?
You can simply do the same as in the slave case.
phc2sys -s /dev/ptp -w
The grand master node will adjust its system time to the free running
PTP Hardware Clock. You will want to set the correct time in the PHC
before doing this!
HTH,
Richard
|
|
From: Richard C. <ric...@gm...> - 2014-02-14 20:10:08
|
Dear linuxptp users and developers,
I am happy to announce the version 1.4 of linuxptp. This release comes
a good six months since the previous one. I have pushed out a v1.4 tag
and released a tar ball on SF.
Once again, my thanks go out to the contributors, Delio, Jacob, Ken,
Miroslav, and Stephan.
The short log is appended, below.
Enjoy,
Richard
Delio Brignoli (4):
Do not qualify announce messages with stepsRemoved >= 255
Set sync timeout only on port_synchronize()
Reset pdr_missing early in port_nrate_calculate(), implement ratio_valid flag
pmc: support retrieving neighborPropDelayThresh and asCapable using management interface
Jacob Keller (2):
missing: add onestep sync to missing.h
sk: update error message for Tx timestamp polling
Ken ICHIKAWA (1):
phc2sys: Fix lower bound value of update_rate
Miroslav Lichvar (23):
Use freeifaddrs() to free data from getifaddrs().
Fix port numbering in clock log messages.
Reset delay timer when switching to P2P delay mechanism.
Don't try to forward messages to faulty UDS port.
Ignore delay_resp messages from foreign masters.
Don't calculate delay with old master's sync time stamp.
Add reset function to servo.
Add clock sanity check.
Add random delay to announce timeout.
Drop tmtab module.
Make random() more random between machines.
Add modular filter interface.
Add median filter.
Add options to configure delay filter.
Adjust tick length with system clock.
Fix drift calculation in PI servo with large values.
Clarify c1, c2, c3 in negative path delay log message.
Change level of negative path delay messages to debug.
Print current frequency when PI servo is in unlocked state.
phc2sys: Mention that PPS output needs to be enabled without -s.
Clarify units used in clock stepping constants.
Set printf format attribute for print().
Fix new -Wformat warnings.
Richard Cochran (27):
Inhibit lost link recovery in P2P mode.
Enforce the absolute lower limit for the announce receipt timeout.
Rename the timer for sending sync messages.
Add a timer implementing the sync receive timeout.
Add a configuration file option for the sync receive timeout.
Announce master ambitions right away.
Add an optional extra check on sync and follow up message ordering.
Add a configuration file option for the extra sync-fup check.
Add missing semicolon to enumeration.
Merge the gPTP sync timeout branch.
Make the CFLAGS more robust.
Convert the hard coded UDS server path into a variable.
Introduce a configuration file option for the server's UDS address.
pmc: add a command line option to select the server's UDS address.
Extend the interface name length to allow any UDS address.
pmc: bring the man page more up to date.
Merge the configurable UDS server path branch.
Introduce the gmCapable flag for use with 802.1AS clocks.
Inhibit sync messages from unwilling 802.1AS ports.
Add a configuration file option for the 802.1AS gmCapable flag.
Merge Miroslav's random PTP timeout branch.
clock: add missing call to clockcheck_destroy.
Fix filter allocation failure on the UDS port.
Simplify the text of the driver support matrix in the readme file.
uds: take the interface data off the stack.
uds: disable the accidentally enabled announce timer.
Version 1.4
Stephan Gatzka (2):
Make udp_physical_addr() and udp_protocol_addr() static.
Make functions and structs dealing with string literals const correct.
|
|
From: Koehrer M. (ETAS/ESW5) <mat...@et...> - 2014-02-13 13:01:41
|
> Sent: Wednesday, February 12, 2014 7:32 PM > > We don't have a file, but instead you can use the management > > interface. The 'pmc' management client can be used in a script, > > like in the example below. > > > > Probably you are interested in the CURRENT_DATA_SET, but for gPTP > > applications there is also TIME_STATUS_NP. Thanks for the information. That helps. What I do not see fully clear is the role of phc2sys. It is used to synchronize the PTP clock from my Ethernet device to the Linux system clock. There is likely a drift/offset between this PTP clock and the Linux system clock. This drift/offset has to be corrected by the phc2sys tool. What kind of information do I get when I call the 'pmc" management client? Is it the drift/offset of the PTP clock (Ethernet) or is it the drift/offset of my Linux system clock? One more question related to phc2sys. When I use a PC as PTP master, I have to call phc2sys like # phc2sys -c /dev/ptp -s CLOCK_REALTIME -w When I use a PC as PTP slave, I have to call it like # phc2sys -s /dev/ptp -w If I do not explicitly specify which of the PCs should run as master or slave, there is a negotiation between the available PCs. One of the PCs will be made the master. Is there a way to call phc2sys to distinguish automatically between master and slave operation mode? Or how do I have to call "phc2sys" in the situation when I do not know if the PC will be master or not? Thanks for any help on this! Regards Mathias |
|
From: Keller, J. E <jac...@in...> - 2014-02-12 18:35:05
|
On Wed, 2014-02-12 at 18:08 +0100, Richard Cochran wrote: > On Wed, Feb 12, 2014 at 03:55:21PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > > > Starting this application on the slaves is only allowed if the time-synchronization is stable (=the clock offset is below a certain limit and the drift is low). > > With "ptpd2" there is a status file /var/run/ptpd2.status" that will be re-written every second. > > Is anything like that available with linuxptp as well? > > We don't have a file, but instead you can use the management > interface. The 'pmc' management client can be used in a script, > like in the example below. > > Probably you are interested in the CURRENT_DATA_SET, but for gPTP > applications there is also TIME_STATUS_NP. > > HTH, > Richard > --- > #!/bin/bash > > while [ 1 ]; do > clear > ./pmc -u -b 0 "get CURRENT_DATA_SET" > sleep 1 > done You could also look at the pmc code and write your own program that directly requests the data on the management UDS socket, if you prefer not running it in a shell script. This is most likely good enough though. Regards, Jake |
|
From: Richard C. <ric...@gm...> - 2014-02-12 17:08:26
|
On Wed, Feb 12, 2014 at 03:55:21PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > Starting this application on the slaves is only allowed if the time-synchronization is stable (=the clock offset is below a certain limit and the drift is low). > With "ptpd2" there is a status file /var/run/ptpd2.status" that will be re-written every second. > Is anything like that available with linuxptp as well? We don't have a file, but instead you can use the management interface. The 'pmc' management client can be used in a script, like in the example below. Probably you are interested in the CURRENT_DATA_SET, but for gPTP applications there is also TIME_STATUS_NP. HTH, Richard --- #!/bin/bash while [ 1 ]; do clear ./pmc -u -b 0 "get CURRENT_DATA_SET" sleep 1 done |
|
From: Koehrer M. (ETAS/ESW5) <mat...@et...> - 2014-02-12 15:55:43
|
Hi all, I want to synchronize a couple of PCs using linuxptp. One of these PCs acts as a master the others are slaves. Is there a way to check the currently achieved synchronization offset on the slaves? Checking the syslog file is not really helpful as I want to do a scriptable check. On each of the PCs an application has to run. Starting this application on the slaves is only allowed if the time-synchronization is stable (=the clock offset is below a certain limit and the drift is low). With "ptpd2" there is a status file /var/run/ptpd2.status" that will be re-written every second. Is anything like that available with linuxptp as well? Thanks for any feedback on this! Regards Mathias |
|
From: Richard C. <ric...@gm...> - 2014-02-07 18:18:46
|
It has been six months since the last release, and activity has been
quiet for a while, so I plan to release v1.4 in about one week. If you
want to do any last minute testing (or you want to report a bug), now
is the time to do it.
After that, we can start on adding new requested features. Here is a
list from my notes.
- add push option on the uds
- Jiri's dynamic port work
- periodic (not one shot) sync and announce timers
- no adjust case, work out freq est interval verses summary interval
(in this case, it is hard to work out the message interval)
- so_timestamping and phc on vlan interfaces
(low priority for me, might involve kernel support)
Thanks,
Richard
|
|
From: Vick, M. <mat...@in...> - 2014-01-31 18:01:15
|
On 1/31/14, 5:18 AM, "Koehrer Mathias (ETAS/ESW5)" <mat...@et...> wrote: >Hi Matthew, > >thanks for the information. > >> Thanks for your report on this! We've had a few reports of this now and >> are investigating it internally. We currently believe we may have a >> hardware bug on 82574L where some reads of the device clock are >> corrupted. >> We are testing a workaround now and will be submitting the patch >>upstream >> once it has passed our internal validation. > >Is the Intel IGB (i350 controller) also affected or which Intel adapter >to you recommend for PTP? >We are fairly free in choosing a suitable adapter. > >Thanks for a short feedback. > >Best regards > >Mathias Mathias, You should be able to continue using the 82574L once we get the patch pushed upstream, which should be relatively soon. As far as other adapters are concerned, the Intel adapter I would recommend for PTP is the I210. Please do not hesitate to let us know if you continue having problems. Cheers, Matthew |
27 messages has been excluded from this view by a project administrator.
