Re: [Linuxptp-devel] igb tsync int handler double acknowledge? (was: Re: [PATCH] PTP subsystem: implement POSIX timer interface)

[Keller, Jacob E]

On Tue, 2016-10-18 at 20:47 +0200, Richard Cochran wrote:
> On Tue, Oct 18, 2016 at 05:19:51PM +0100, Kieran Tyrrell wrote:
> > 
> > So reading the TSICR register acknowledges the interrupt and clears
> > the register. If another tsync interrupt occurs while in the
> > interrupt handler, the second interrupt could be acknowledged
> > without having been handled.
> > 
> 
> The igb driver is doing this on purpose.  See this thread:
> 
> https://www.spinics.net/lists/netdev/msg237642.html
> 
> The extra ack is a work around for the 82580.  Sounds like the i210
> doesn't have this problem.  If the double ack is causing missed
> interrupts, then it really should be fixed in mainline.
> 
> Thanks,
> Richard
> 

Agreed. I'll take a look at this and can probably have the driver
maintainer for igb get a fix in.

Regards,
Jake
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Planning release 1.8

[Keller, Jacob E]

On Tue, 2016-10-18 at 08:38 +0200, Richard Cochran wrote:
> On Mon, Oct 17, 2016 at 08:39:16PM +0000, Keller, Jacob E wrote:
> > 
> > Sounds good to me. I don't have any current issues, but being able
> > to
> > let people know that the RTNL link handling will be in 1.7 will be
> > nice. Thanks for all your work.
> 
> Maybe rtnl is not quite ready yet.  I'd like positive feedback that
> it
> really is working.
> 
> Thanks,
> Richard

I'll give them a whack tomorrow and see what I think. It seems Miroslav
is also testing them pretty well.

Thanks,
Jake
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/3] Optional prefix for ptp4l/phc2sys log messages

[Keller, Jacob E]

On Mon, 2016-10-17 at 16:33 +0200, Miroslav Lichvar wrote:
> When there are multiple instances of ptp4l or phc2sys running on the
> system, it's difficult to tell which message belongs to which
> instance. The first patch adds new options to ptp4l and phc2sys which
> can be used to specify a different prefix for each instance, so
> different instances can use different prefixes. One issue is that
> it's
> not possible to set the prefix in ptp4l config to its default value
> (empty string) and the setting can't be included in defaults.cfg.
> 

Is it possible to update configuration somehow to allow passing a
variable as "empty" which will assign it to empty string, and then
update your prefix code flow so that it correctly works and doesn't add
a " " when the string is actually empty? Not sure how easy it would be
to fix that or not.

Thanks,
Jake

> The second patch adds support for this feature to timemaster.
> 
> The third patch is an unrelated improvement in timemaster to exit
> early with an error message when an interface doesn't support neither
> HW nor SW timestamping. (The patch applies only with the second
> patch,
> so it's included here.)
> 
> Miroslav Lichvar (3):
>   Add options to prefix ptp4l and phc2sys log messages.
>   timemaster: prefix ptp4l and phc2sys messages.
>   timemaster: check support for SW time stamping.
> 
>  config.c |  1 +
>  phc2sys.8|  4 
>  phc2sys.c|  9 +++--
>  print.c  | 18 ++
>  print.h  |  1 +
>  ptp4l.8  | 10 ++
>  ptp4l.c  |  9 -
>  timemaster.c | 34 ++
>  8 files changed, 71 insertions(+), 15 deletions(-)
> 
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Planning release 1.8

[Keller, Jacob E]

On Sun, 2016-10-16 at 13:09 +0200, Richard Cochran wrote:
> Dear linuxptp users and developers,
> 
> I am planning to release version 1.8 in one week, without any major
> new features, in order to fix the regression in version 1.7.
> 
> [ Sound familiar?  The same thing happened to 1.6.  I don't have the
>   time to maintain stable branches, and so my policy is to push out a
>   new release in case of regressions.  Anyone sticking with older
>   versions who is affected by the regressions can easily pick up the
>   small fixes. ]
> 
> The one bug that needs fixing is the one-step mode.  This broke
> between 1.6 and 1.7.  I am also planning to include the RTNL link
> handling as a new feature.
> 

Sounds good to me. I don't have any current issues, but being able to
let people know that the RTNL link handling will be in 1.7 will be
nice. Thanks for all your work.

Regards,
Jake
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 2/2] port: Consider the source port identity when comparing announce messages.

[Keller, Jacob E]

On Wed, 2016-08-03 at 14:49 +0200, Richard Cochran wrote:
> Contrary to the letter of the standard, we do not throw a state
> decision
> event every announce interval, but only when the inputs to the
> algorithm
> have changed.  When a port on a BC forms a spanning tree by deciding
> between the MASTER and PASSIVE states, the identity of the port which
> sent
> the announce message acts as a tie breaker.
> 
> However, the current code ignores that field when deciding whether
> the
> inputs have changed or not.  This patch fixes the comparison to
> include
> the source port id.
> 

Makes sense to me, and code does what it says.

Acked-by: Jacob Keller 

> Signed-off-by: Richard Cochran 
> ---
>  port.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/port.c b/port.c
> index 5868983..b9f6497 100644
> --- a/port.c
> +++ b/port.c
> @@ -135,14 +135,20 @@ static void port_nrate_initialize(struct port
> *p);
>  static int announce_compare(struct ptp_message *m1, struct
> ptp_message *m2)
>  {
>   struct announce_msg *a = >announce, *b = >announce;
> - int len =
> + int diff, len =
>   sizeof(a->grandmasterPriority1) +
>   sizeof(a->grandmasterClockQuality) +
>   sizeof(a->grandmasterPriority2) +
>   sizeof(a->grandmasterIdentity) +
>   sizeof(a->stepsRemoved);
>  
> - return memcmp(>grandmasterPriority1, 
> >grandmasterPriority1, len);
> + diff = memcmp(>grandmasterPriority1, 
> >grandmasterPriority1, len);
> + if (diff) {
> + return diff;
> + }
> + return memcmp(>header.sourcePortIdentity,
> +   >header.sourcePortIdentity,
> +   sizeof(m1->header.sourcePortIdentity));
>  }
>  
>  static void announce_to_dataset(struct ptp_message *m, struct port
> *p,
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 7/7] Let the clock code figure the PHC index.

[Keller, Jacob E]

On Fri, 2016-04-15 at 18:50 +0200, Richard Cochran wrote:
> On Mon, Apr 11, 2016 at 05:31:49PM +0000, Keller, Jacob E wrote:
> > 
> > Would this make more logical sense as a separate function here?
> Yes, it might look cleaner in a helper function, but that would be a
> follow on patch.  I prefer not to change blocks of code when moving
> them, since it makes harder to figure out the history later on.
> 
> Thanks,
> Richard

Yes, I agree. Was just something I noticed.

Thanks,
Jake
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] ptp4l, multicast, and clearing Rx timestamp settings

[Keller, Jacob E]

Hi,

I am experiencing an interesting issue on some devices. I know the
following scenario is not really a real world setup but it will help
outline the issue and whether we ought to make a change to LinuxPTP.

Say you have 3 netdevices capable of performing hardware timestamping
connected to a switch.

You run ptp4l on the first two devices and begin syncing.

Then you start ptp4l on the 3rd device, and begin syncing. After a
while you kill ptp4l on the 3rd device, but leave the first two
syncing.

The result in my case is that the 3rd device's driver complains about
latched Rx timestamp registers and times out. This occurs, I believe,
because the hardware performs the Rx timestamp and puts it into RX
timestamp registers before deciding if it should drop the multicast
frame (as the multicast subscription should be cleared when the socket
goes away, if I understand correctly).

Thus, since the launch of ptp4l enabled Rx timestamp settings, the
hardware will now continuously trigger rx timestamp hang logic in the
driver until the PTP traffic on the other two ports is stopped.

My question for this list: Should ptp4l be updated to include a signal
handler to trap the exit signal(s) and reset the timestamp logic upon
exit? Or is there a better way this could be updated/handled in the
kernel? or is this not really an issue, and my driver should be fixed?

I don't know if it is really possible to fix my driver, since currently
it doesn't know when Rx timestamps have been disabled.

Regards,
Jake
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/6] Prepare for TC, Batch I

[Keller, Jacob E]

> -Original Message-
> From: Richard Cochran [mailto:richardcoch...@gmail.com]
> Sent: Sunday, April 03, 2016 6:12 AM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH RFC 0/6] Prepare for TC, Batch I
> 
> This series prepares the way for a Transparent Clock implementation.
> 
> Patches 1-4 are more or less trivial cleanups.
> 
> Patch 5 moves a large block of code from main() in ptp4l.c into
> clock_create().  Right now, much of the clock initialization logic is
> performed in main(), but that stuff really belongs in the clock
> instance.  Two more similar patches are coming in Batch II.
> 
> Patch 6 simplifies the clock_create() interface even more.
> 
> Review and comments are welcome.
> 
> Thanks,
> Richard

The series looks good to me. Several really simple and nice fixes, plus two 
changes to reduce the complexity of the clock_create API.

I didn't see anything obviously wrong yet.

Thanks,
Jake
 


--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Use of PTP on CentOS 6

[Keller, Jacob E]

PTPd was the original implementation. It had no support for real hardware 
timestamps. Some device drivers supplied “SW synchronized” hardware stamps that 
were fudged to be in the kernel clock time domain. This was driver specific and 
was not well documented or supported. Richard Cochran started trying to create 
and expose the kernel interface we used today, and the PTPd project wasn’t 
interested.

He wrote linuxptp at this time, and got the current hardware timestamp 
implementation upstream. It is possible at some point PTPd started implementing 
use of the PHC subsystem since then, I am not aware.

PTPd2 was started sometime after PTPd and was intended to support v2 of the 
protocol, which at the time PTPd did not support (I have no idea if it does 
now). I don’t think this version was maintained for very long. It also did not 
support hardware timestamping.

As Ledda mentioned, RedHat backported the interface into their RHEL6.4 kernel, 
which has allowed them to enable support LinuxPTP.

For Linux, I don’t think any other PTP daemon is as capable as LinuxPTP, though 
I could be mistaken as I have since stopped researching the alternatives.

If you have configured ptp4l and phc2sys correctly, they should synchronize 
fairly quickly. You’d have to show the configuration and output of these two 
commands for us to further help you.

Regards,
Jake

From: Claudio Scordino [mailto:clau...@evidence.eu.com]
Sent: Monday, January 18, 2016 1:22 AM
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] Use of PTP on CentOS 6


I need to create a reliable and accurate synchronization between two CentOS 6 
machines connected through a direct Ethernet connection.

I've seen that on Linux several implementation of the IEEE 1588 Precision Time 
Protocol (PTP) exist:

  *   PTPd:

 *   Apparently, this is the original implentation
 *   Apparently, it is still maintained

  *   PTPd2:

 *   A new version meant to supersede the previous implementation
 *   Apparently unmaintained
 *   For CentOS 6, available only in the EPEL repositories

  *   PTPv2d:

 *   A further implementation
 *   Unmaintained as well

  *   linuxptp:

 *   A specific implementation for Linux
 *   Maintained
 *   Available on the CentOS repositories
 *   Suggested by the RedHat documentation for both RedHat 
6
 and RedHat 
7

My questions follow:

  *   Why does the RedHat documentation suggest the use of 
linuxptp
 for RedHat 6 (based on Linux kernel 2.6) despite the linuxptp documentation 
says that a Linux kernel version 3.0 or newer is 
needed ?
  *   Which are differences between PTPd2 and Linuxptp in terms of reliability 
and timing accuracy ?
  *   Why when I run ptp4l and phc2sys, the machines do not synchronize 
immediately and often need me to start/stop the services several times or 
manually change system time through date to make the machine synchronize ?
Many thanks and best regards.
--
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=/4140___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Frequency offset computation

[Keller, Jacob E]

On Thu, 2015-11-12 at 14:37 -0600, Bassam Alsanie wrote:

I will be going over the PHC APIs and some of the kernel PHC modules to get 
deeper understand.
Just to let you know why my questions seem little bit weird. I am working on 
developing a user mode framework for to accessing the hardware (for rapid 
prototyping). I found its useful to develop a user mode code to access the 
custom clock (can take as low as one day of development time) then update the 
linuxptp (ptp4l) to adjust the frequency on the clock using the user-mode code, 
instead of calling into the PHC framework which require kernel support.
This is not permanent solution nor to replace the current PHC framework, its 
just to characterise the hardware and perform some initial tests in a very 
short time. Then after that move to follow the PHC model to make the final 
implementation.

Thank you
Bassam,




Just implement kernel mode stuff first, it's not that difficult, and there are 
usemode applications, Documentation/ptp/testptp.c for example which help 
perform tests on the device. I think you'll have a headache porting math if you 
go your route above.

Regards,
Jake
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Trying to use ptp4l

[Keller, Jacob E]

zOn Thu, 2015-11-05 at 17:42 -0600, Bassam Alsanie wrote:
> I have two machines each one has an i210 Ethernet (PTP Enabled)
> connect together via Ethernet cable. I run the ptp4l on both
> machines, but I don't see continues correction or any output messages
> that show the offsets , they are on the same output message for an
> hour! attached the command I used and the output.
> 
> I am I missing something here?
> 
> Thank you

You probably need to increase the log level

Regards,
Jake
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Offset Filters

[Keller, Jacob E]

On Wed, 2015-11-04 at 18:29 +0100, Richard Cochran wrote:
> On Wed, Nov 04, 2015 at 01:46:52PM +, Shlomi Tubul wrote:
> 
> > For some reason, I see spikes at clients, which are
> > unreasonable. Most of the time the offset is around +- 200ns,
> > but from time to time it jumps to more than 20 micro second.
> 
> You shouldn't have such spikes.
> 

Indeed, spikes like this are unexpected.

> > Looking at the code of ptp4l, I see that there are filters for
> > the delay but not for the offset.
> 
> That is because they are not needed.

Offset should be stable, while delay actually can jitter about for
various reasons.

> 
> > I updated the code a little it in my environment, just to see
> > if the offset is real.  For every offset greater than 1
> > microsecond, I updated it to 0. This caused the client to
> > synchronize better and not trying to adjust huge offsets.
> 
> You made a band aid, and this papers over the problem.  Why not find
> out the cause of those spikes?
> 
> > Both server and client are running Intel I210, RH 7.1, linux
> > ptp 1.6.
> 
> I have used the i210 quite a lot, and I have never seen such spikes.
> 
> Do you have a direct point to point connection?  If not, probably the
> equipment in between is to blame.

Yes likely the equipment between is an issue if there is any.

> 
> > The setup is running also other applications (Hadoop etc), so
> > I am not sure how much it affects.
> 
> The time stamps are taken in hardware at the MAC level, and so
> applications should have no effect.
> 

I do not believe that latency affects the actual timestamping equipment
in hardware. It could delay the overall timestamp return process, but
that doesn't actually add any latency to the timestamp itself since it
was already captured, only in how long it takes to return it. Note that
the i210 can only timestamp one Tx packet at a time, but the outcome
you are seeing is not dropped Tx timestamps, but just spikes in the
value?

Regards,
Jake

> Thanks,
> Richard
> 
> -
> -
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [announce] version 1.6 released

[Keller, Jacob E]

On Sat, 2015-09-19 at 21:12 +0200, Richard Cochran wrote:
> Dear linuxptp users and developers,
> 
> Nine months since the previous release, I announce version 1.6 of
> linuxptp.  I pushed out tag v1.6 and released a tar ball on SF. 

Thanks richard. I don't see the v1.6 tag..

Regards,
Jake
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v4 07/69] config: introduce a new API for reading configuration settings.

[Keller, Jacob E]

On Fri, 2015-08-21 at 10:38 +0200, Richard Cochran wrote:
 On Thu, Aug 20, 2015 at 10:25:23PM +, Keller, Jacob E wrote:
  If I understand this correctly, this means that a user passing a
  configuration file missing any option the program reads we will
  terminate the whole program instead of selecting the default?
 
 No, that is not how it works.

So, what happens in the case of a configuration file that is missing a
field? ie: a user provides a configuration file which doesn't have the
item in it?

Regards,
Jake
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v3 00/69] New configuration implementation

[Keller, Jacob E]

 -Original Message-
 From: Keller, Jacob E [mailto:jacob.e.kel...@intel.com]
 Sent: Monday, August 17, 2015 1:54 AM
 To: Richard Cochran
 Cc: linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] [PATCH RFC v3 00/69] New configuration
 implementation
 
  -Original Message-
  From: Richard Cochran [mailto:richardcoch...@gmail.com]
 
 
  You are right, Jake.  I forgot the config_get_dbl() calls.  It is hard
  to express how mind numbing this conversion work is.  On top of that,
  I must have rebased this series dozens of times, in order to refine
  the API. :S
 
  Did you check all of the other conversions, or did you give up?
 
  Thanks for the careful review,
 
  Richard
 
 I didn't notice any others missing, but I can't exactly say how carefully I
 checked. I think all of the PI options were missed, but nothing else appeared
 to be missing. Glad to catch this early. I can go take a quick look at the 
 final
 result you posted on github for any issues.
 
 Regards,
 Jake
 

With some clever use of ack and sed, I did a search for all uses of 
config_(double|int)_ that grabbed the various options. The only ones missing 
are:

pi_integral_exponent
pi_integral_norm_max
pi_integral_scale
pi_proportional_exponent
 pi_proportional_norm_max

Hope this helps.

Regards,
Jake

--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v3 00/69] New configuration implementation

[Keller, Jacob E]

 -Original Message-
 From: Richard Cochran [mailto:richardcoch...@gmail.com]
 Sent: Monday, August 17, 2015 8:44 AM
 To: Miroslav Lichvar
 Cc: linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] [PATCH RFC v3 00/69] New configuration
 implementation
 
 On Mon, Aug 17, 2015 at 05:14:18PM +0200, Miroslav Lichvar wrote:
  Nice. I like the design. I guess it won't be too difficult to add
  string to the supported types and convert the remaining old config
  code.
 
 Maybe, but I need to take breather from my conversion marathon!
 
 BTW, I ran your linuxptp-testsuite on this branch, and it brought:
 
   SUMMARY:
 TOTAL  21
 PASSED 3
 FAILED 18
 
 That is because of the missing PI constants.  I should have tested
 first, then published.  Oh well.
 
 Thanks,
 Richard
 

Where is the linuxptp-testsuite hosted?

Regards
Jake


--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v3 00/69] New configuration implementation

[Keller, Jacob E]

 -Original Message-
 From: Richard Cochran [mailto:richardcoch...@gmail.com]
 Sent: Monday, August 17, 2015 1:49 PM
 To: Keller, Jacob E
 Cc: Miroslav Lichvar; linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] [PATCH RFC v3 00/69] New configuration
 implementation
 
 On Mon, Aug 17, 2015 at 04:15:59PM +, Keller, Jacob E wrote:
  Where is the linuxptp-testsuite hosted?
 
   https://github.com/mlichvar/linuxptp-testsuite.git
 
 You also need:
 
   https://github.com/mlichvar/clknetsim.git
 
 Cheers,
 Richard

This is something probably worth documenting in a TESTING file for future 
developers :) I will play around with this and see what it would take to add a 
little docs to the linuxptp to point out such a useful tool :)

Regards,
Jake

--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v3 00/69] New configuration implementation

[Keller, Jacob E]

Hi Richard,

This series looks excellent with a few minor questions.

 -Original Message-
 From: Richard Cochran [mailto:richardcoch...@gmail.com]
 Sent: Sunday, August 16, 2015 1:15 PM
 To: linuxptp-devel@lists.sourceforge.net
 Subject: [Linuxptp-devel] [PATCH RFC v3 00/69] New configuration
 implementation
 
 Changes in V3:
 - Reduced interface to two types, double and int
   (enums are accessed like ints)
 - Converted almost everything
 

You converted the PI options, but I can't figure exactly how they were read. 
There doesn't appear to be any calls to config_get_int or config_get_dbl for 
them in their respective patches.

The only other interesting one was the options which took ASAP as a value. That 
definitely seemed a little hack, but it seems ok to support that option. I 
don't expect most options to need that sort of work-around.

Regards,
Jake


--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v3 23/69] config: convert 'pi_proportional_exponent' to the new scheme.

[Keller, Jacob E]

 -Original Message-
 From: Richard Cochran [mailto:richardcoch...@gmail.com]
 Sent: Sunday, August 16, 2015 1:15 PM
 To: linuxptp-devel@lists.sourceforge.net
 Subject: [Linuxptp-devel] [PATCH RFC v3 23/69] config: convert
 'pi_proportional_exponent' to the new scheme.
 
 Signed-off-by: Richard Cochran richardcoch...@gmail.com
 ---
  config.c | 7 +--
  config.h | 1 -
  pi.c | 6 +++---
  pi.h | 7 ---
  ptp4l.c  | 1 -
  5 files changed, 4 insertions(+), 18 deletions(-)
 
 diff --git a/config.c b/config.c
 index 07cb016..43f96fe 100644
 --- a/config.c
 +++ b/config.c
 @@ -98,6 +98,7 @@ struct config_item config_tab[] = {
   GLOB_ITEM_INT(max_frequency, 9, 0, INT_MAX),
   GLOB_ITEM_DBL(pi_integral_const, 0.0, 0.0, DBL_MAX),
   GLOB_ITEM_DBL(pi_proportional_const, 0.0, 0.0, DBL_MAX),
 + GLOB_ITEM_DBL(pi_proportional_exponent, -0.3, -DBL_MAX,
 DBL_MAX),

Maybe I am missing something here, but where do we actually read these options 
out? Since we no longer set them in global variables, I don't quite understand 
how you're reading it now? I don't see any calls to read the option in this 
patch...

This applies to a few other patches as well...

Regards,
Jake

   GLOB_ITEM_DBL(pi_proportional_scale, 0.0, 0.0, DBL_MAX),
   GLOB_ITEM_DBL(step_threshold, 0.0, 0.0, DBL_MAX),
   GLOB_ITEM_INT(tx_timestamp_timeout, 1, 1, INT_MAX),
 @@ -544,12 +545,6 @@ static enum parser_result
 parse_global_setting(const char *option,
   cfg-dds.freq_est_interval = val;
   pod-freq_est_interval = val;
 
 - } else if (!strcmp(option, pi_proportional_exponent)) {
 - r = get_ranged_double(value, df, -DBL_MAX, DBL_MAX);
 - if (r != PARSED_OK)
 - return r;
 - *cfg-pi_proportional_exponent = df;
 -
   } else if (!strcmp(option, pi_proportional_norm_max)) {
   r = get_ranged_double(value, df, DBL_MIN, 1.0);
   if (r != PARSED_OK)
 diff --git a/config.h b/config.h
 index 4b8a4a2..afd7142 100644
 --- a/config.h
 +++ b/config.h
 @@ -69,7 +69,6 @@ struct config {
   struct port_defaults pod;
   enum servo_type clock_servo;
 
 - double *pi_proportional_exponent;
   double *pi_proportional_norm_max;
   double *pi_integral_scale;
   double *pi_integral_exponent;
 diff --git a/pi.c b/pi.c
 index 8fe847a..bf57789 100644
 --- a/pi.c
 +++ b/pi.c
 @@ -36,7 +36,6 @@
  #define FREQ_EST_MARGIN 0.001
 
  /* These take their values from the configuration file. (see ptp4l.c) */
 -double configured_pi_kp_exponent = -0.3;
  double configured_pi_kp_norm_max = 0.7;
  double configured_pi_ki_scale = 0.0;
  double configured_pi_ki_exponent = 0.4;
 @@ -55,6 +54,7 @@ struct pi_servo {
   double configured_pi_kp;
   double configured_pi_ki;
   double configured_pi_kp_scale;
 + double configured_pi_kp_exponent;
  };
 
  static void pi_destroy(struct servo *servo)
 @@ -160,7 +160,7 @@ static void pi_sync_interval(struct servo *servo,
 double interval)
  {
   struct pi_servo *s = container_of(servo, struct pi_servo, servo);
 
 - s-kp = s-configured_pi_kp_scale * pow(interval,
 configured_pi_kp_exponent);
 + s-kp = s-configured_pi_kp_scale * pow(interval, s-
 configured_pi_kp_exponent);
   if (s-kp  configured_pi_kp_norm_max / interval)
   s-kp = configured_pi_kp_norm_max / interval;
 
 @@ -205,7 +205,7 @@ struct servo *pi_servo_create(struct config *cfg, int
 fadj, int sw_ts)
  unstable. */
   s-configured_pi_kp_scale = s-configured_pi_kp;
   configured_pi_ki_scale = s-configured_pi_ki;
 - configured_pi_kp_exponent = 0.0;
 + s-configured_pi_kp_exponent = 0.0;
   configured_pi_ki_exponent = 0.0;
   configured_pi_kp_norm_max = MAX_KP_NORM_MAX;
   configured_pi_ki_norm_max = MAX_KI_NORM_MAX;
 diff --git a/pi.h b/pi.h
 index d3e541e..27a64b1 100644
 --- a/pi.h
 +++ b/pi.h
 @@ -22,13 +22,6 @@
  #include servo.h
 
  /**
 - * This variable determines the exponent in the formula used to set the
 - * proportional constant of the PI controller from the sync interval.
 - * kp = min(kp_scale * sync^kp_exponent, kp_norm_max / sync)
 - */
 -extern double configured_pi_kp_exponent;
 -
 -/**
   * This variable determines the normalized maximum in the formula used to
 set
   * the proportional constant of the PI controller from the sync interval.
   * kp = min(kp_scale * sync^kp_exponent, kp_norm_max / sync)
 diff --git a/ptp4l.c b/ptp4l.c
 index b96bee3..43dd977 100644
 --- a/ptp4l.c
 +++ b/ptp4l.c
 @@ -103,7 +103,6 @@ static struct config cfg_settings = {
   .transport = TRANS_UDP_IPV4,
   .clock_servo = CLOCK_SERVO_PI,
 
 - .pi_proportional_exponent = configured_pi_kp_exponent,
   .pi_proportional_norm_max = configured_pi_kp_norm_max,
   .pi_integral_scale = configured_pi_ki_scale,
   .pi_integral_exponent = 

Re: [Linuxptp-devel] [PATCH RFC v3 27/69] config: convert 'pi_integral_norm_max' to the new scheme.

[Keller, Jacob E]

 -Original Message-
 From: Richard Cochran [mailto:richardcoch...@gmail.com]
 Sent: Sunday, August 16, 2015 1:15 PM
 To: linuxptp-devel@lists.sourceforge.net
 Subject: [Linuxptp-devel] [PATCH RFC v3 27/69] config: convert
 'pi_integral_norm_max' to the new scheme.
 
 Signed-off-by: Richard Cochran richardcoch...@gmail.com
 ---

Same comment as most of the other PI options, it no longer looks like you're 
reading them, since the new API doesn't explicitely set these values..?

Regards,
Jake
 


--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v3 26/69] config: convert 'pi_integral_exponent' to the new scheme.

[Keller, Jacob E]

 -Original Message-
 From: Richard Cochran [mailto:richardcoch...@gmail.com]
 Sent: Sunday, August 16, 2015 1:15 PM
 To: linuxptp-devel@lists.sourceforge.net
 Subject: [Linuxptp-devel] [PATCH RFC v3 26/69] config: convert
 'pi_integral_exponent' to the new scheme.
 
 Signed-off-by: Richard Cochran richardcoch...@gmail.com
 ---

Same here, I can't figure out where you actually read the configuration option? 
Am I missing something or?

Regards,
Jake
 


--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v2 00/16] New configuration implementation

[Keller, Jacob E]

On Thu, 2015-08-13 at 08:20 +0200, Richard Cochran wrote:
 On Wed, Aug 12, 2015 at 09:12:57PM +, Keller, Jacob E wrote:
  General comments:
  
  it doesn't appear to enforce any specific change on configuration
  file
  format. I know my earlier proposal was maybe to at some point
  update
  the format. Specifically, change the per-port configurations to use
  port: or some prefix which might help ensure possible future
  expansion of sections. The primary reasoning being separating out
  options used by differing programs.
 
 Although I have port as an identifier, the new code does not care
 about the section names at all.  It would work with files that had:
 

Ok. What I meant was that we today have per-port via:

[enp2s0f0]
options

which indicates a port, and not a section. Maybe we should change this
to be:

[port:enp2s0f0] or something in the oddball case where someone uses
udev et.el to rename their device global or similar.. maybe we don't
really care about this though.

   [phc2sys]
   someOption 1
 
   [pmc]
   somethingElse 0
 
   [future-section]
   whatever 1
 
 It would be up to the caller to specify the desired section. For
 example:
 
   x = config_get_int(cfg, phc2sys, someOption);
 

That's fine, and makes sense to me.

 The only built in assumption is that every option can appear under
 [global] as a default.  It does *not* support options that can only
 appear in a non-global section.
 
 I will replace port with section in conifg.h and config.c.
 
  Are there any options you think might be more difficult to convert?
  I
  think some of the string options might not move as cleanly to the
  new
  API.. each call site would have to parse the string instead of
  parsing
  an enumeration. Maybe that can be solved by having a GLOB_ITEM_ENUM
  or
  something where the setup passes in a map of string-value that
  could
  be used instead, so that callsites get an enum/int of values
  instead of
  strings?
 
 Yes, I was thinking of ENUM options with little string tables
 attached, but I haven't yet worked out the details.
 

This seems the most straight forward way.

  Other comment is whether we want phc2sys and ptp4l to read from the
  same configuration file or should they just read separate ones.
 
 I am not sure what is better.  We had some discussion on this point
 that I should look up again.  The new code doesn't really care.
 

I think we probably can make them read from the same one.
 If we wanted distinct sets of legal options, then we would need
 separate config_tab[] instances and different config_init() functions
 (or one config_init(flavor) with switch/case inside).  That change
 will be easy to add, if we decide we need it later on.


Ya that's what I thought. I don't think we need to worry too much as
long as each option takes the same values for each configuration, as
this way you could use the same file and only the options each program
needs are read/used.

Regards,
Jake
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v2 00/16] New configuration implementation

[Keller, Jacob E]

Hi Richard,

On Wed, 2015-08-12 at 21:45 +0200, Richard Cochran wrote:
 Changes in V2:
 - API is much simpler to use
 - numerous details in the implementation have been improved
 - half dozen legacy options converted
 

Nice changes. Looks very straight forward to use.

 The config code was simplistic at first and has grown many warts over
 time.  The pointers to global variables are rather gross, and it is
 hard to add new options, especially port specific ones.  The number 
 of
 configuration options is sure to grow larger over time.
 

Yep.

 This series addresses the issues by implementing a hash table based
 implementation.  Adding a new option is as simple as placing the item
 into the config_tab[] table (one line), and then calling
 var=config_get_TYPE() at the usage site.

Nice. Super easy to add, and it looks like the various modes support
most of our current options.

 
 This series add one new option and converts six legacy options.  Many
 if not all of the remaining legacy options can be converted to the 
 new
 system.  Once this is done, the config code will be much more compact
 and maintainable.  In addition, the phc2sys and pmc programs will 
 also
 be able to use a configuration file.
 

Very useful. Will take some time to setup all the options for each
file.

 Patches 1-4 and 12 provide changes allowing passing of the 
 configuration.
 Patch 5 and 6 add a simple hash table.
 Patch 7 adds the bulk of the new implementation.
 Patch 8 lets the UDP transport use the new TTL option.
 Patches 9-11 and 14-16 convert some legacy options.
 Patch 13 adds a way to lock options from the command line.
 
 Review and comments are most welcome.

General comments:

it doesn't appear to enforce any specific change on configuration file
format. I know my earlier proposal was maybe to at some point update
the format. Specifically, change the per-port configurations to use
port: or some prefix which might help ensure possible future
expansion of sections. The primary reasoning being separating out
options used by differing programs.

It seems that is something we could handle in the future, though.

Are there any options you think might be more difficult to convert? I
think some of the string options might not move as cleanly to the new
API.. each call site would have to parse the string instead of parsing
an enumeration. Maybe that can be solved by having a GLOB_ITEM_ENUM or
something where the setup passes in a map of string-value that could
be used instead, so that callsites get an enum/int of values instead of
strings?

Other comment is whether we want phc2sys and ptp4l to read from the
same configuration file or should they just read separate ones.

Aside from my general comments, I looked over the series and it looks
great. Most of my comments here wouldn't sway me to say don't apply it
now. We can always continue to work towards moving all the options from
legacy into the new format.

Regards,
Jake
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v1 7/9] config: introduce a new API for reading configuration settings.

[Keller, Jacob E]

On Mon, 2015-08-10 at 23:12 +0200, Richard Cochran wrote:
 This patch adds method to initialize a configuration and look up 
 values.
 All port options are also global option, with the global option 
 giving the
 default value.  The port look up method first checks for a port 
 specific
 value, falling back to the global default when missing.
 
 Users are required to call 'config_init', and so this patch add that 
 into
 all three programs, ptp4l, phc2sys and pmc.
 
 Signed-off-by: Richard Cochran richardcoch...@gmail.com
 ---
  config.c  | 22 ++
  config.h  | 28 
  makefile  | 10 +-
  phc2sys.c |  3 +++
  pmc.c |  3 +++
  ptp4l.c   |  3 +++
  6 files changed, 64 insertions(+), 5 deletions(-)
 
 diff --git a/config.c b/config.c
 index 9ef8be1..f81ac83 100644
 --- a/config.c
 +++ b/config.c
 @@ -823,3 +823,25 @@ void config_destroy(struct config *cfg)
   }
   hash_destroy(cfg-htab, free);
  }
 +
 +struct config_item *config_global_item(struct config *cfg, const 
 char *name)
 +{
 + struct config_item *ci;
 + char buf[CONFIG_LABEL_SIZE + 8];
 + snprintf(buf, sizeof(buf), global.%s, name);
 + ci = hash_lookup(cfg-htab, buf);
 + return ci;
 +}
 +
 +struct config_item *config_port_item(struct config *cfg, const char 
 *port,
 +  const char *name)
 +{
 + struct config_item *ci;
 + char buf[CONFIG_LABEL_SIZE + MAX_IFNAME_SIZE];
 + snprintf(buf, sizeof(buf), %s.%s, port, name);
 + ci = hash_lookup(cfg-htab, buf);
 + if (ci) {
 + return ci;
 + }
 + return config_global_item(cfg, name);
 +}
 diff --git a/config.h b/config.h
 index 222883a..78c57df 100644
 --- a/config.h
 +++ b/config.h
 @@ -105,4 +105,32 @@ struct interface *config_create_interface(char 
 *name, struct config *cfg);
  void config_init_interface(struct interface *iface, struct config 
 *cfg);
  void config_destroy(struct config *cfg);
  
 +/* New, hash table based methods: */
 +
 +#define CONFIG_LABEL_SIZE 32
 +
 +enum config_type {
 + CFG_TYPE_INT,
 + CFG_TYPE_UINT,
 + CFG_TYPE_DOUBLE,
 +};
 +
 +typedef union {
 + int i;
 + unsigned int u;
 + double d;
 +} any_t;
 +
 +struct config_item {
 + char label[CONFIG_LABEL_SIZE];
 + enum config_type type;
 + any_t val;
 + any_t min;
 + any_t max;
 +};
 +
 +int config_init(struct config *cfg);
 +struct config_item *config_global_item(struct config *cfg, const 
 char *name);
 +struct config_item *config_port_item(struct config *cfg, const char 
 *port,
 +  const char *name);
  #endif
 diff --git a/makefile b/makefile
 index 922769b..bcdbb92 100644
 --- a/makefile
 +++ b/makefile
 @@ -46,13 +46,13 @@ all: $(PRG)
  
  ptp4l: $(OBJ)
  
 -pmc: msg.o pmc.o pmc_common.o print.o raw.o sk.o tlv.o transport.o 
 udp.o \
 - udp6.o uds.o util.o version.o
 -
 -phc2sys: clockadj.o clockcheck.o linreg.o msg.o ntpshm.o nullf.o 
 phc.o \
 - phc2sys.o pi.o pmc_common.o print.o raw.o servo.o sk.o stats.o 
 sysoff.o tlv.o \
 +pmc: config.o hash.o msg.o pmc.o pmc_common.o print.o raw.o sk.o 
 tlv.o \
   transport.o udp.o udp6.o uds.o util.o version.o
  
 +phc2sys: clockadj.o clockcheck.o config.o hash.o linreg.o msg.o 
 ntpshm.o \
 + nullf.o phc.o phc2sys.o pi.o pmc_common.o print.o raw.o servo.o 
 sk.o stats.o \
 + sysoff.o tlv.o transport.o udp.o udp6.o uds.o util.o version.o
 +
  hwstamp_ctl: hwstamp_ctl.o version.o
  
  phc_ctl: phc_ctl.o phc.o sk.o util.o clockadj.o sysoff.o print.o 
 version.o
 diff --git a/phc2sys.c b/phc2sys.c
 index 5ba99c3..c737142 100644
 --- a/phc2sys.c
 +++ b/phc2sys.c
 @@ -1369,6 +1369,9 @@ int main(int argc, char *argv[])
   }
   }
  
 + if (config_init(phc2sys_config)) {
 + return -1;
 + }

Is there a reason to not drop these extra parens? I don't recall if we
keep them for style reason in this codebase or not. (too used to kernel
style to drop unnecessary ones)

Regards,
Jake

   if (autocfg  (src_name || dst_name || pps_fd = 0 || 
 wait_sync || node.forced_sync_offset)) {
   fprintf(stderr,
   autoconfiguration cannot be mixed with 
 manual config options.\n);
 diff --git a/pmc.c b/pmc.c
 index 1fe8183..d26a87e 100644
 --- a/pmc.c
 +++ b/pmc.c
 @@ -800,6 +800,9 @@ int main(int argc, char *argv[])
   }
   }
  
 + if (config_init(pmc_config)) {
 + return -1;
 + }
   if (!iface_name) {
   if (transport_type == TRANS_UDS) {
   snprintf(uds_local, sizeof(uds_local),
 diff --git a/ptp4l.c b/ptp4l.c
 index 56cb8bd..6048eb6 100644
 --- a/ptp4l.c
 +++ b/ptp4l.c
 @@ -272,6 +272,9 @@ int main(int argc, char *argv[])
   }
   }
  
 + if (config_init(cfg_settings)) {
 + return -1;
 + }
   if (config  (c = config_read(config, cfg_settings))) {
   return c;
   }

Re: [Linuxptp-devel] unknown option ntpshm_segment at line 8 in eno1 section

[Keller, Jacob E]

On Sun, 2015-08-02 at 02:58 +, Gary E. Miller wrote:
 Yo Richard!
 
 On Sat, 1 Aug 2015 20:09:38 +0200
 Richard Cochran richardcoch...@gmail.com wrote:
 
  The configuration file scheme can't do what you want it to do, even
  without the ntpshm_segment option.
 
 Yeah, sadly... 
 
   [eno1]
   ntpshm_segment 0
   
   [eno2]
   ntpshm_segment 1
  
  is the same as entering
  
  ptp4l -i eno1 -i eno2
 
 Sadly, no.  When you do that ptp4l only uses one SHM, not two.  Now
 if ptp4l read the [eno1] and [eno2] sections it would work.
 

You mis-understand. Passing eno1, eno2 or putting them in the
configuration file is how you would set up boundary clock mode. This
appears to not be what you want, so neither of these things is going to
work.

  You can use one file per ptp4l instance.
 
Yeah, which sort of shows how the config file syntax is not really
 impleented as cleverly as it wass designed.
 

No it doesn't. ptp4l's one configuration file is designed to run one
instance of ptp4l.

   Another possibility is
  ptp4l -f -
  together with a HERE file in your shell script.
 
 Yeah, but then both instances try to grab ports 319 and 320.  I tried
 putting one instance on UDPv4 and one UDPv6, but the UDPv6 seems to 
 also
 grab the UDPv4 port.
 

You'd have to use something like L2 instead, so that it doesn't bind
ports. You could also network namespace the sections, but that sounds
like overkill.

Regards,
Jake

 RGDS
 GARY
 -
 --
 Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
   g...@rellim.com  Tel:+1(541)382-8588
 -
 -
 ___
 Linuxptp-devel mailing list
 Linuxptp-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add options to configure TTL/hop limit for UDP/UDP6 transports.

[Keller, Jacob E]

On Mon, 2015-08-03 at 22:02 +0200, Richard Cochran wrote:
 I have no problem with adding these options.
 
 On Mon, Aug 03, 2015 at 03:49:43PM +0200, Miroslav Lichvar wrote:
  +unsigned char udp_ttl = 1;
 ...
 
  +   if (setsockopt(fd, IPPROTO_IP, IP_MULTICAST_TTL, udp_ttl,
  +  sizeof(udp_ttl))) {
  +   pr_err(setsockopt IP_MULTICAST_TTL failed: %m);
  +   goto no_option;
  +   }
 
 This would be better it it were a per-port option, no?
 
 I want to start reworking the config API to make it easier and 
 cleaner
 to add and make use of options.  (Jake and I discussed this a bit
 off-list.)  I'll hold on this patch until we have something.  In 
 fact,
 I might just use this change as a guinea pig, if you don't mind!
 
 Thanks,
 Richard


Yea. We discussed some ideas, but I have not had any more time to work
on the ideas myself. One option I've recently considered is maybe
porting some library inline to our code that might make it easier than
re-writing all the bits ourselves.. May not be worth it at all but
worth considering ie: static inline a (GPL) library that does what we
need, rather than write our own.. but do so in a way that doesn't
require users to actually install the library themselves.. It's an
option we might want to consider.

Regards,
Jake
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] unknown option ntpshm_segment at line 8 in eno1 section

[Keller, Jacob E]

On Fri, 2015-07-31 at 18:16 +, Gary E. Miller wrote:
 Yo All!
 
 I'd like a config file change to the ptp4l config file.  
 
 In this case I have a server with two ethernet segments, and I want 
 each
 one to be on its own SHM.  I would like to be able to do this:
 
 [global]
 uds_address /var/run/ptp4l
 
 clock_servo ntpshm
 
 [eno1]
 ntpshm_segment 0
 
 [eno2]
 ntpshm_segment 1
 
 But that gives me this rror:
 
 unknown option ntpshm_segment at line 8 in eno1 section
 
 So now I am back to having to use 2 config files which sorta makes 
 the
 global config file concept.
 
 Any thing I missed?  Or can this be fixed?

I don't believe this is currently supportable, since we only create one
clock for each instance of ptp4l, and that clock would be the one
generating the ntpshm_segment. The per-port configuration is only
useful when running the boundary clock mode, not for configuring
different settings depending on what device is loaded.

Regards,
Jake
--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] clock_adjtime() function

[Keller, Jacob E]

On Tue, 2015-06-23 at 22:06 +, Daniel Le wrote:
 My Linux kernel version is 2.6.35.7 and it doesn't seem to have the 
 implementation of syscall for __NR_clock_adjtime. In which kernel 
 version was it initially introduced?
 
 I changed the function clock_adjtime() to use adjtimex() as shown in 
 the following. Would that work fine when it's called to perform a 
 clock step (with the modes ADJ_SETOFFSET bit set) and slewing? Is it 
 better to use settimeofday() to step the clock? My system runs ptp4l 
 in software timestamping mode.
 
 #ifndef HAVE_CLOCK_ADJTIME
 static inline int clock_adjtime(clockid_t id, struct timex *tx)
 {
 // return syscall(__NR_clock_adjtime, id, tx);
 return adjtimex(tx);
 }
 #endif
 
 The adjtimex() function does not have the clock id parameter. I'm 
 unclear how to deal with it. In my debugging messages, I've only seen 
 CLOCK_REALTIME whose Id is 0 which is the clock that adjtimex() 
 applies to. Is clock_adjtime() executed in some case for other clock 
 id such as CLOCK_MONOTONIC?
 

In hardware timestamping mode it is executed on the PHC clocks exposed
by the PTP infrastructure, which is why clockid is needed. Your kernel
does not (fully?) support the PTP core infrastructure which is the
intended use of ptp4l.

Regards,
Jake

 Thanks,
 Daniel

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 1/2] fixed spelling: MANAGEMENT

[Keller, Jacob E]

Hi,

Patch looks fine. We generally include a Signed-off-by as is similar to
kernel style, but I'm sure that could be fixed up post-apply by Richard.

Thanks for the fix :)

Regards,
Jake

On Wed, 2015-06-03 at 09:20 +0200, zmoel...@iem.at wrote:
 From: IOhannes m zmölnig zmoel...@umlautq.umlaeute.mur.at
 
 rather than MANAGMENT
 ---
  pmc.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/pmc.c b/pmc.c
 index d58e190..366c093 100644
 --- a/pmc.c
 +++ b/pmc.c
 @@ -211,9 +211,9 @@ static void pmc_show(struct ptp_message *msg, FILE *fp)
   }
   tlv = (struct TLV *) msg-management.suffix;
   if (tlv-type == TLV_MANAGEMENT) {
 - fprintf(fp, MANAGMENT );
 + fprintf(fp, MANAGEMENT );
   } else if (tlv-type == TLV_MANAGEMENT_ERROR_STATUS) {
 - fprintf(fp, MANAGMENT_ERROR_STATUS );
 + fprintf(fp, MANAGEMENT_ERROR_STATUS );
   goto out;
   } else {
   fprintf(fp, unknown-tlv );

--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] expected filters listed in ethtool -T

[Keller, Jacob E]

Hi,

I am wondering what the expected filters listed in the ethtool -T ioctl
are supposed to be? Precisely, what if we support FILTER_ALL. This means
(by definition) that we support any filter since we can support it as
upscaled to FILTER_ALL

Should a driver report that it supports any particular filter if it will
upscale to a more generic filter that timestamps more packets?

Or should it only list the actual filters it upscales to and not the
more restrictive filters that will still work in the hwtstamp ioctl but
will end up reporting a more general filter?

There are some drivers I have seen do either way, and I think some
clarification on this would be quite useful.

Regards,
Jake
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] expected filters listed in ethtool -T

[Keller, Jacob E]

Hi,

On Fri, 2015-04-17 at 23:14 +0200, Richard Cochran wrote:
 On Fri, Apr 17, 2015 at 06:45:56PM +, Keller, Jacob E wrote:
  Or should it only list the actual filters it upscales to and not the
  more restrictive filters that will still work in the hwtstamp ioctl but
  will end up reporting a more general filter?
 
 This variant is the most useful one, IMHO.  The ioctl should tell us
 what the HW can do.

Ok this is what I've tended towards.

  
  There are some drivers I have seen do either way, and I think some
  clarification on this would be quite useful.
 
 I still think the multitude of filters is just noise and not
 practical.  From the user's point of view only V2_L2_EVENT,
 V2_L4_EVENT, V2_EVENT, or ALL make any sense.
 

Alright. So only report the most general configuration in ethtool.

I'll see about what other drivers do and posting a patch to bring
everyone in line with this for consistency.

Thanks for the input.

 Thanks,
 Richard
 
 

Regards,
Jake
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] timecounter mask for non-bitwise overflowing?

[Keller, Jacob E]

 -Original Message-
 From: Richard Cochran [mailto:richardcoch...@gmail.com]
 Sent: Saturday, April 04, 2015 1:27 PM
 To: Keller, Jacob E
 Cc: linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] timecounter mask for non-bitwise
 overflowing?
 
 On Sat, Apr 04, 2015 at 12:47:15AM +, Keller, Jacob E wrote:
  Hey Richard, and others,
 
  I am currently implementing a timecounter setup for a device which
  (nominally) represents time as
 
  Field1: 32bits, Seconds
  Field2: 32bits, Nanoseconds (never  999,999,999)
 
  I do the math to convert this to u64 nanoseconds, and provide this to a
  cycle counter.
 
 So, I guess you want to do this because your HW has this split
 representation, but you cannot adjust the frequency?

Several reasons:

1) consistency with the rest of the hardware in the driver
2) atomic time increments (I have a patch I want to propose that will enable 
atomic time increment for timecounters by just adding or subtracting from the 
offset)
3) hardware may have to change the frequency of the clock driving the system 
timer, so even though it was supposed to represent nominal seconds and 
nanoseconds, it won't actually, since the underlying clock won't be running at 
the right frequency).
4) support the gettime64/settime64 routines via the timecounter.

 
  I think the timecounter code is actually incorrect, because it doesn't
  allow for arbitrary overflow points
 
 I think the timecounter is okay.  Your problem is that the timecounter
 uses base-2 counting, but your clock counts 10^9 nanoseconds (base-10).
 
  Any suggestions or thoughts on the timecounter stuff?
 
 32 bits of seconds gives you 136 years of uptime (assuming the counter
 starts at zero).  You can just use a 64 bit mask and forget about the
 overflow, since it can never happen in practice.
 

Ok. That's what I was thinking. I would prefer that it not happen at all, but 
it really is a non-issue as you said.

 
 HTH,
 Richard

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] how to measure frequency offset without correcting?

[Keller, Jacob E]

Hey,

I am attempting to use phc2sys and debug some new hardware, and I want
to be able to sort of free-running mode measure the difference clock
offset and frequency offset, but without actually passing corrections.

Is there a way to do this? The reason for this is that I believe that my
adjfreq function is not correct, so I don't want it to be run, and I
would like to be able to see if software can get some sort of measure of
how fast my clock is running. I think it's possible my base frequency is
incorrect right now.

Regards,
Jake
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Limited success with hardware PTP

[Keller, Jacob E]

On Mon, 2015-03-02 at 15:39 -0800, Gary E. Miller wrote:
 Yo Matthew!
 
 On Thu, 26 Feb 2015 21:16:21 +
 Vick, Matthew matthew.v...@intel.com wrote:
 
  One other tidbit is that I210 supports EEE, which can affect jitter,
  although I wouldn't expect it on that level. You can try turning this
  off via ethtool (ethtool --set-eee ethX eee off) to see if that helps.
 
 Ding-ding-ding, I think we might have a winner.  That instantly dropped
 my offset from -400 mSec to around 1 mSec.  That 1 mSec is well within
 the confusion that the ntpd PLLs just took.  Jitter went to 1 uSec.
 Time to hook the PPS back up and get serious.
 
 RGDS
 GARY

Excellent news! :) I had forgotten about EEE

Thanks,
Jake
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] ntp SHMs

[Keller, Jacob E]

Hey,

 -Original Message-
 From: Gary E. Miller [mailto:g...@rellim.com]
 Sent: Monday, February 23, 2015 6:49 PM
 To: Keller, Jacob E
 Cc: linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] ntp SHMs
 
 Yo Jacob!
 
 Just to summarize what I just tried, that failed.  I repeated several times,
 similar results, it just took varying times before going crazy, usually
 10 to 90 seconds.
 
 Here is my hardware:
 
 kong ~ # ethtool -T eth0
 Time stamping parameters for eth0:
 Capabilities:
   hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
   software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
   hardware-receive  (SOF_TIMESTAMPING_RX_HARDWARE)
   software-receive  (SOF_TIMESTAMPING_RX_SOFTWARE)
   software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
   hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE)
 PTP Hardware Clock: 0
 Hardware Transmit Timestamp Modes:
   off   (HWTSTAMP_TX_OFF)
   on(HWTSTAMP_TX_ON)
 Hardware Receive Filter Modes:
   none  (HWTSTAMP_FILTER_NONE)
   all   (HWTSTAMP_FILTER_ALL)
   ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
   ptpv1-l4-delay-req
 (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
   ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
   ptpv2-l4-delay-req
 (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
   ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
   ptpv2-l2-delay-req
 (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
   ptpv2-event   (HWTSTAMP_FILTER_PTP_V2_EVENT)
   ptpv2-sync(HWTSTAMP_FILTER_PTP_V2_SYNC)
   ptpv2-delay-req   (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
 
 Here I make sure no conflicting daemons:
 
 kong ~ # killall ptp4l phc2sys
 ptp4l: no process found
 phc2sys: no process found
 kong ~ # killall ptp4l phc2sys
 ptp4l: no process found
 phc2sys: no process found
 
 Here is my config:
 
 kong ~ # cat ptp.conf
 [global]
 clock_servo   linreg
 
 Start ptp4l:
 
 kong ~ # ptp4l -i eth0 -l 7 -m -f ptp.conf 
 
 And drop the bomb:
 
 kong ~ # phc2sys -a -r -E ntpshm -m -M 2
 phc2sys[354.145]: uds: sendto failed: No such file or directory
 

Apparently it recovers, because you seem to have it working. The default should 
be fine. I am going to assume this is a transient problem due to timing between 
when you start ptp4l and phc2sys, where the us address isn't up yet.

 This one is odd, is uds_address not defaulted as documented?
 
 Sadly, add uds_address/var/run/ptp4l  to my ptp.conf does not change
 anything.
 
 ptp4l[354.146]: selected /dev/ptp0 as PTP clock
 ptp4l[354.183]: port 1: INITIALIZING to LISTENING on INITIALIZE
 ptp4l[354.183]: port 0: INITIALIZING to LISTENING on INITIALIZE
 ptp4l[354.570]: port 1: setting asCapable
 phc2sys[355.146]: Waiting for ptp4l...
 ptp4l[355.197]: port 0: setting asCapable
 ptp4l[355.674]: port 1: new foreign master 003048.fffe.345fe2-1
 phc2sys[356.198]: reconfiguring after port state change
 phc2sys[356.198]: selecting eth0 for synchronization
 phc2sys[356.198]: nothing to synchronize
 ptp4l[359.341]: selected best master clock 003048.fffe.345fe2
 ptp4l[359.341]: foreign master not using PTP timescale
 ptp4l[359.341]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
 ptp4l[359.361]: port 1: delay timeout
 ptp4l[359.526]: port 1: delay timeout
 phc2sys[360.198]: port 002590.fffe.f355da-1 changed state
 phc2sys[360.198]: reconfiguring after port state change
 phc2sys[360.198]: master clock not ready, waiting...
 ptp4l[360.352]: port 1: delay timeout
 ptp4l[360.353]: path delay 58263  58263
 ptp4l[360.987]: master offset 16506354212 s0 freq  -0 path delay
 58263
 ptp4l[361.746]: port 1: delay timeout
 ptp4l[361.746]: path delay 59135  60008
 ptp4l[361.904]: master offset 16506344102 s0 freq  -0 path delay
 59135
 ptp4l[362.820]: master offset 16506334623 s0 freq  -0 path delay
 59135
 ptp4l[363.681]: port 1: delay timeout
 ptp4l[363.681]: path delay 58263  47033
 ptp4l[363.737]: linreg: points 4 slope 1.08825 intercept -
 16506326986 err 0
 ptp4l[363.737]: master offset 16506327955 s1 freq   -9794 path delay
 58263
 ptp4l[364.654]: linreg: points 4 slope 1.08873 intercept 613 err 1412
 ptp4l[364.654]: master offset  -1412 s2 freq   -9485 path delay 
 58263
 ptp4l[364.654]: port 1: UNCALIBRATED to SLAVE on
 MASTER_CLOCK_SELECTED
 phc2sys[365.199]: port 002590.fffe.f355da-1 changed state
 phc2sys[365.199]: reconfiguring after port state change
 phc2sys[365.199]: selecting CLOCK_REALTIME for synchronization
 phc2sys[365.199]: selecting eth0 as the master clock
 phc2sys[365.199

Re: [Linuxptp-devel] ntp SHMs

[Keller, Jacob E]

Hi,

Hopefully you can provide the ptp4l results alone without phc2sys or the 
chronyd interfering. Like I mentioned use the testptp program from the kernel 
Documentation to sanity check the device's clock. I have a few more comments 
below.

 -Original Message-
 From: Gary E. Miller [mailto:g...@rellim.com]
 Sent: Tuesday, February 24, 2015 2:13 PM
 To: Keller, Jacob E
 Cc: Jiri Benc; linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] ntp SHMs
 
 Yo Jacob E!
 
 On Tue, 24 Feb 2015 21:33:49 +
 Keller, Jacob E jacob.e.kel...@intel.com wrote:
 
   No, I am not.  As noted in the test procedure dump I did this first:
 # killall ptp4l phc2sys
  
 
  This is probably the root of your problem. Nothing else *should* be
  writing the clock but any software that has privileges and access
  to /dev/ptpX could write to it..
 
 What else *could* be writing /dev/ptpX.  I have never installed ptpd or
 anything similar.
 
  Also your driver can do it in case of a reset.
 
 I've not noticed any port resets.
 
  Could you post your dmesg log? This is an Intel part that I have some
  driver experience with so maybe I can spot any inconsistency there.
 
 Here you go, first the debug output:
 
 
 kong ~ # killall ptp4l phc2sys
 ptp4l: no process found
 phc2sys: no process found
 kong ~ # killall ptp4l phc2sys
 ptp4l: no process found
 phc2sys: no process found
 kong ~ # cat ptp.conf
 [global]
 clock_servo   linreg
 uds_address   /var/run/ptp4l
 
 kong ~ # ptp4l -i eth0 -l 7 -m -f ptp.conf 

I recommend that you run with -l 6 ,since l7 prints a ton of debug information 
that is nearly always not helpful and clutters reading the time log output.

 kong ~ # sleep 3
 ptp4l[48368.046]: selected /dev/ptp0 as PTP clock
 ptp4l[48368.046]: port 1: INITIALIZING to LISTENING on INITIALIZE
 ptp4l[48368.046]: port 0: INITIALIZING to LISTENING on INITIALIZE
 ptp4l[48368.406]: port 1: setting asCapable
 ptp4l[48368.406]: port 1: new foreign master 003048.fffe.345fe2-1
 kong ~ # phc2sys -a -r -E ntpshm -m -M 2
 ptp4l[48371.047]: port 0: setting asCapable
 phc2sys[48372.047]: reconfiguring after port state change
 phc2sys[48372.047]: selecting eth0 for synchronization
 phc2sys[48372.047]: nothing to synchronize
 ptp4l[48372.406]: selected best master clock 003048.fffe.345fe2
 ptp4l[48372.406]: foreign master not using PTP timescale
 ptp4l[48372.406]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
 phc2sys[48373.048]: port 002590.fffe.f355da-1 changed state
 phc2sys[48373.048]: reconfiguring after port state change
 phc2sys[48373.048]: master clock not ready, waiting...
 ptp4l[48373.473]: port 1: delay timeout
 ptp4l[48373.474]: path delay 54411  54411
 ptp4l[48374.419]: master offset  328777253 s0 freq   -8900 path delay
 54411
 ptp4l[48374.911]: port 1: delay timeout
 ptp4l[48374.912]: path delay 54730  55049
 ptp4l[48375.419]: master offset  328777178 s0 freq   -8900 path delay
 54730
 ptp4l[48375.518]: port 1: delay timeout
 ptp4l[48375.519]: path delay 55049  64001
 ptp4l[48376.419]: master offset  328775902 s0 freq   -8900 path delay
 55049
 ptp4l[48376.912]: port 1: delay timeout
 ptp4l[48376.912]: path delay 55455  55862
 ptp4l[48377.419]: linreg: points 4 slope 1.09562 intercept -328775458
 err 0
 ptp4l[48377.419]: master offset  328775472 s1 freq   -9576 path delay
 55455
 ptp4l[48377.508]: port 1: delay timeout
 ptp4l[48378.129]: port 1: delay timeout
 ptp4l[48378.419]: linreg: points 4 slope 1.09634 intercept 41 err 78
 ptp4l[48378.419]: master offset 78 s2 freq   -9675 path delay 
 55455

So here it seems to be corrected

 ptp4l[48378.419]: port 1: UNCALIBRATED to SLAVE on
 MASTER_CLOCK_SELECTED
 phc2sys[48379.049]: port 002590.fffe.f355da-1 changed state
 phc2sys[48379.049]: reconfiguring after port state change
 phc2sys[48379.049]: selecting CLOCK_REALTIME for synchronization
 phc2sys[48379.049]: selecting eth0 as the master clock
 phc2sys[48379.049]: phc offset 328806192 s0 freq  +0 delay   1516
 ptp4l[48379.419]: linreg: points 4 slope 1.09343 intercept -533 err 341
 ptp4l[48379.419]: master offset604 s2 freq   -8810 path delay 
 55455
 phc2sys[48380.049]: phc offset 328806161 s0 freq  +0 delay   1516
 ptp4l[48380.205]: port 1: delay timeout
 ptp4l[48380.205]: path delay 55049  47086
 ptp4l[48380.419]: linreg: points 4 slope 1.09269 intercept -159 err 298
 ptp4l[48380.419]: master offset213 s2 freq   -9110 path delay 
 55049
 ptp4l[48380.637]: port 1: delay timeout
 ptp4l[48380.638]: path delay 54730  43799
 phc2sys[48381.049]: phc offset 328806265 s0 freq  +0 delay   1517
 ptp4l[48381.419]: linreg: points 4 slope 1.09081 intercept -376 err 341
 ptp4l[48381.419]: master offset470 s2 freq   -8705 path delay 
 54730
 phc2sys[48382.049]: phc offset 328806509 s0 freq  +0 delay   1515
 ptp4l[48382.373]: port 1: delay timeout
 ptp4l[48382.373

Re: [Linuxptp-devel] ntp SHMs

[Keller, Jacob E]

 -Original Message-
 From: Gary E. Miller [mailto:g...@rellim.com]
 Sent: Tuesday, February 24, 2015 2:55 PM
 To: Keller, Jacob E
 Cc: linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] ntp SHMs
 
 Yo Jacob E!
 
 On Tue, 24 Feb 2015 22:32:40 +
 Keller, Jacob E jacob.e.kel...@intel.com wrote:
 
This is telling you that your clock time (CLOCK_REALTIME) is off
by 70,000 seconds. That's not happy.
  
   Except my clock time is off by about 60 uSec.  At least until
   phc2sys tries to 'fix' the problem.
  
 
  No. That is a mis-understanding. Your internal NIC clock is off by 60
  uSec.
 
 No misunderstanding.  My slave is NTP connected, so I KNOW the
 system clock is off by 60 uSec from the clock master.
 
  Your REALTIME clock is not the NIC clock, but actually the
  kernel time,
 
 Never thought otherwise.
 
  and *that* is what phc2sys offset is for.
 
 Hmm, I see the confusion, I never mentioned my phc2sys offest.  Until
 it goes to 70,000 seconds
 

Correct. I was not assuming that you had another way to measure system time 
offset from the master.

So this looks quit suspicious as a driver bug. Especially as it
appears to be toggling between a large positive and negative
value I am recalling something similar.
  
   Ouch.  I am on an Intel I217-LM  with the e1000e driver.
 
  Ya. I looked at the driver for this, but nothing was obvious. The
  issue I thought might be related appears to be fine in the 3.19
  kernel.
 
 Another dead end...
 
   Got a suggested config and procedure for that?
 
  Please just run your setup without running phc2sys, and use -l6 on
  ptp4l instead of -l7.
 
 So, to be clear. is this exactly what you want me to try:
 
 The ptp.conf:
 
 [global]
 clock_servo linreg
 uds_address /var/run/ptp4l
 
 
 # killall ptp4l phc2sys
 # killall ptp4l phc2sys
 # ptp4l -i eth0 -l 6 -m -f ptp.conf 
 
  See if you get the same clock jump issue or not.
 
 Since my ptp4l is in linreg mode, it can not jump my system clock.

To be clear, linreg is just a linear regression servo which could control the 
system clock, if you were doing software timestamping. In this case linreg is 
controlling the hardware MAC clock.

 
 So what should I look for?
 
 I just did that, looks ugly, but I really have no idea:
 

This doesn't look ugly, you just likely mis-understand the output.

 # killall ptp4l phc2sys
 ptp4l: no process found
 phc2sys: no process found
 # ptp4l -i eth0 -l 6 -m -f ptp.conf
 ptp4l[52360.386]: selected /dev/ptp0 as PTP clock
 ptp4l[52360.386]: port 1: INITIALIZING to LISTENING on INITIALIZE
 ptp4l[52360.386]: port 0: INITIALIZING to LISTENING on INITIALIZE
 ptp4l[52362.144]: port 1: new foreign master 003048.fffe.345fe2-1
 ptp4l[52366.144]: selected best master clock 003048.fffe.345fe2
 ptp4l[52366.144]: foreign master not using PTP timescale
 ptp4l[52366.144]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE

So it starts in uncalibrated mode, to prime the servo.

 ptp4l[52367.211]: master offset -99132 s0 freq +59998 path delay
 46363
 ptp4l[52368.211]: master offset-107849 s0 freq +59998 path delay
 46363
 ptp4l[52369.211]: master offset-125869 s0 freq +59998 path delay
 55328
 ptp4l[52370.211]: master offset-134962 s1 freq +54160 path delay
 55306
 ptp4l[52371.211]: master offset -599870879 s2 freq +186802553 path delay
 55306
 ptp4l[52371.211]: port 1: UNCALIBRATED to SLAVE on
 MASTER_CLOCK_SELECTED
 ptp4l[52372.211]: master offset -786797418 s2 freq -149872567 path delay
 55306
 ptp4l[52373.211]: master offset -637009628 s2 freq -5 path delay
 58203
 ptp4l[52374.211]: master offset  -37092094 s2 freq -37208915 path delay
 60342
 ptp4l[52375.211]: master offset 244012 s2 freq +177926 path delay
 58203
 
 Strangely a kill and restart looks reasonable:
 

You didn't let it run long enough to stabilize but restarting is probably fine.

 kong linuxptp #  ptp4l -i eth0 -l 6 -m -f ptp.conf
 ptp4l[52498.377]: selected /dev/ptp0 as PTP clock
 ptp4l[52498.378]: port 1: INITIALIZING to LISTENING on INITIALIZE
 ptp4l[52498.378]: port 0: INITIALIZING to LISTENING on INITIALIZE
 ptp4l[52500.147]: port 1: new foreign master 003048.fffe.345fe2-1
 ptp4l[52504.147]: selected best master clock 003048.fffe.345fe2
 ptp4l[52504.147]: foreign master not using PTP timescale
 ptp4l[52504.147]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
 ptp4l[52506.215]: master offset-125996 s0 freq +177925 path delay
 66149
 ptp4l[52507.215]: master offset-114049 s0 freq +177925 path delay
 46374
 ptp4l[52508.215]: master offset-126964 s0 freq +177925 path delay
 49315
 ptp4l[52509.215]: master offset-136826 s1 freq +177442 path delay
 52187
 ptp4l[52510.215]: master offset-188068 s2 freq  -21513 path delay
 52187
 ptp4l[52510.215]: port 1: UNCALIBRATED to SLAVE on
 MASTER_CLOCK_SELECTED
 ptp4l[52511.216]: master offset-176435 s2 freq  -97696 path delay
 52187
 ptp4l[52512.215]: master

Re: [Linuxptp-devel] ntp SHMs

[Keller, Jacob E]

Hi,

 -Original Message-
 From: Gary E. Miller [mailto:g...@rellim.com]
 Sent: Tuesday, February 24, 2015 2:25 PM
 To: Keller, Jacob E
 Cc: linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] ntp SHMs
 
 Yo Jacob E!
 
 On Tue, 24 Feb 2015 21:41:52 +
 Keller, Jacob E jacob.e.kel...@intel.com wrote:
 
   And drop the bomb:
  
   kong ~ # phc2sys -a -r -E ntpshm -m -M 2
   phc2sys[354.145]: uds: sendto failed: No such file or directory
  
 
  Apparently it recovers, because you seem to have it working. The
  default should be fine. I am going to assume this is a transient
  problem due to timing between when you start ptp4l and phc2sys, where
  the us address isn't up yet.
 
 Confirmed.  Adding a 'sleep 3' to my test script fixes it.  I would
 suggest the error message make some mention of what it was trying
 to send where for debug purposes.
 
   phc2sys[365.199]: phc offset -70353239245525 s0 freq  +0
   delay   1348
  
   WTF was that???
 
  This is telling you that your clock time (CLOCK_REALTIME) is off by
  70,000 seconds. That's not happy.
 
 Except my clock time is off by about 60 uSec.  At least until phc2sys
 tries to 'fix' the problem.
 

No. That is a mis-understanding. Your internal NIC clock is off by 60 uSec. 
Your REALTIME clock is not the NIC clock, but actually the kernel time, and 
*that* is what phc2sys offset is for.
 
   I stopped it here as it tried to step my good clock by -70356s.
  
 
  So this looks quit suspicious as a driver bug. Especially as it
  appears to be toggling between a large positive and negative value I
  am recalling something similar.
 
 Ouch.  I am on an Intel I217-LM  with the e1000e driver.

Ya. I looked at the driver for this, but nothing was obvious. The issue I 
thought might be related appears to be fine in the 3.19 kernel.

 
 Maybe time for me to try another NIC.
 
  What happens if you just run ptp4l without running phc2sys and
  without running chronyd etc? I want to see ptp4l running stable with
  hardware timestamping before adding extra messages.
 
 Got a suggested config and procedure for that?

Please just run your setup without running phc2sys, and use -l6 on ptp4l 
instead of -l7. See if you get the same clock jump issue or not.

Also if you have the kernel documentation installed, you can use 
Documentation/ptp/testptp.c in order to read the PTP hardware clock directly.

Try building that and running

./testptp -g -d /dev/ptpX

Where ptpX is your device's ptp device, which you can see via ethtool -T

You can use that to sanity check whether the PTP device is being set correctly. 
It should match your remote PTP master's time.

 
 Since in the present config my ptp4l is in linreg mode, is it just a
 matter of starting ptp4l in linreg mode, not runnning phc2sys, and
 looking at the ptp4l debug output?
 

Yes.

  Also what is your
  dmesg output here, so that we can see if there is any kernel message
  related to this.
 
 Nothing at all in dmesg.

Ok so it's not the result of a tx hang causing a reset on the clock device. 
That's good.

Regards,
Jake

 
 RGDS
 GARY
 ---
 Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
   g...@rellim.com  Tel:+1(541)382-8588

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Limited success with hardware PTP

[Keller, Jacob E]

Hi,

On Wed, 2015-02-25 at 16:48 -0800, Gary E. Miller wrote:
 Yo Jacob E!
 
 On Thu, 26 Feb 2015 00:32:27 +
 Keller, Jacob E jacob.e.kel...@intel.com wrote:
 
  Yea, in general all you really want is HWTSTAMP_FILTER_ALL, it's a
  much better implementation.
 
 So what is the minimmum for hardware mode timestamping?  Like this?
 
 HWTSTAMP_TX_OFF
 HWTSTAMP_TX_ON
 HWTSTAMP_FILTER_ALL
 
 

HWTSTAMP_TX_OFF is always supported. HWTSTAMP_TX_ON is required for
Hardware Tx timestamps.

HWTSTAMP_FILTER_ALL is best, otherwise you need the requisite modes for
your configuration.

Mostly for V2 layer4, with End to end, you need
HWTSTAMP_FILTER_V2_SYNC and
HWTSTAMP_FILTER_V2_DELAY_REQ

For P2P delay protocol you need to be able to timestamp PDELAY_REQ and
PDELAY_RESPONSE messages,

and for L2 mode you have to be able to timestamp L2 equivalents of
these. The most general non-timestamp-all mode is

HWTSTAMP_FILTER_V2_EVENT

ptp4l will try HWTSTAMP_FILTER_ALL if its available and degrade to more
general filters until it finds either a working combination or exits
saying required mode isn't supported.

  At any rate, I would love to see the full output of just ptp4l running
  on the i217-LM without phc2sys and so forth interfering. Mostly I
  would like to get enough information to see if we can rootcause why
  that particular hardware was failing.
 
 That was in my email to linuxptp and you yesterday at 14:54.
 
 Want me to forward a copy?
 

The output you had there didn't showcase the actual failure with the
clockcheck showing a massive change in the clock. Either it didn't run
long enough or the failure case was triggered by phc2sys or some other
setup.

  You might try the out of tree sourceforge module for e1000e on the
  Intel e1000e sourceforge page, because it may (or may not) have bug
  fixes compared to upstream. I honestly don't know what state upstream
  e1000e is vs the source forge driver.
 
 No commits to e1000e n sourceforge since June 2014.  The 3.19 kernel
 files are Dec 2014.
 
 Many NIC choices in the world, I'm not gonna waste my time on any one of 
 them.
 

Yep. Well, I'll try to forward what we do have to validation for that
part here. Thanks for the effort so far at least :) I understand that it
isn't worth too much effort on your end.

I am glad that you were able to get to at least a somewhat sane setup
finally.

Regards,
Jake

 RGDS
 GARY
 ---
 Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
   g...@rellim.com  Tel:+1(541)382-8588


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] ntp SHMs

[Keller, Jacob E]

Hi,

On Mon, 2015-02-23 at 13:48 -0800, Gary E. Miller wrote:
 Yo Jacob E!
 
 On Mon, 23 Feb 2015 21:09:01 +
 Keller, Jacob E jacob.e.kel...@intel.com wrote:
 
   Ouch...  But I guess pure theory until a WiFi driver has real
   support.
   
  
  NTP and PTP are generally considered solutions to different but
  related problems, so this shouldn't really be an issue.
 
 As a gpsd maintainer and longtime chronyd/ntpd user I 100% disagree!
 
 Not having chronyd or ntpd in the loop is a total non-starter for me.
 

I think I was mis-leading in my original comment here. I meant to say
that accuracy of PTP vs NTP over WiFi could very well be different
simply because they are very different algorithms with somewhat related
but differing goals. I did not mean to say that a full solution would
not use ntpd or chronyd or similar.

   Odd, so automatic configuration not so automatic.  I told ptp4l to
   use ntpshm, that should be passed along.
   
  
  ptp4l in hardware timestamp mode controls a hardware clock, which is
  completely unrelated to the system time clock.
 
 Understood.
 
  Then, phc2sys controls
  the system clock based on the hardware clock which is set by ptp4l
 
 Gack, maybe that is one way, but not a good way.  Certainly not the
 only way.
 
 Since ptp4l can control the ntpshm in software timestamping mode why
 can it not do so in hardware timestamping mode?  Does ptp4l in hardware
 mode ignore ntpsm in hardware mode, or does it continue to post parallel
 software mode timing?
 

This is a complex problem. Hardware timestamping is done by varying
hardware at the MAC (or PHY) level. Each hardware has its own internal
clock to do this. These clocks are in *no* way driven by or in sync with
the kernel clocks. Thus, the ptp kernel core exposes these each as their
own clock device /dev/ptpX

ptp4l in hardware mode completely ignores anything related to the
software kernel clock world. This is because hardware NICs have their
own internal clocks for doing hardware timestamping. Thus all timestamps
are relative to the clock on the MAC, not to any clock on the
motherboard.

There have been attempts in the past for hardware to sync to the
kernel clock but these were almost all faulty for various reasons
including that they can't run a full servo in the kernel.

There really doesn't make any sense for ptp4l to attempt to relate them
to the software kernel clock at all. Thus, ptp4l will drive the ptp
hardware clock from PTP on the network. Then a separate program (phc2sys
or other) drives the software-hardware sync.

*however* when in software timestamp mode the origin of the timestamps
*is* the kernel clock, so thus we drive the kernel timer from ptp4l
directly.

In hardware mode we are not driving the clock directly but only
indirectly.

I hope this makes sense?

  This is sort of the flow.
  
  network - ptp4l - NIC hardware clock - phc2sys - system clock
 
 So how do I get ntpshm in there?
 

I assume you tell phc2sys to use ntpshm?

 And not valid for a local PPS based PTP master, maybe mmore like:
 
 PPS - ntpd - local sysclock - ptp4l - NIC hardware clock - phc2sys - 
 ntpshm
 
 And it has to be a loop, so when PPS is lost that host can feed the hardware
 clock back into ntpd.
 
  Telling ptp4l to use the ntpshm doesn't work unless ptp4l is in
  software mode because ptp4l doesn't control teh software clock in
  hardware timestamp mode.
 
 Weird.  Why are not ptp4l and phc2sys one program?  They are certainly
 deeply intertwined.  And ptp4l in software mode already does most of what 
 phc2sys does in hardware mode.

I'll leave Richard and others to answer this question, though I suspect
because ptp4l controls only the one clock which is handling
timestamping. It just happens that in software mode this is the kernel
clock.

 
   kong ~ #  phc2sys -a -r -i eth0 -m -q
   '-i' has been deprecated. please use '-s' instead.
   autoconfiguration cannot be mixed with manual config options.
  Yea, I think you just need to drop the -i eth0 part.
 
 With no -i phc2sys complains it has not port to connect to
 
 And not replace with the -s?  A bug in the error message?
 

I am unsure, but... it should be connecting to the ptp4l Unix socket to
get its configuration from the ptp4l daemon. I'll defer to someone who
is more familiar with automatic mode.

   Which will not start for me:
   
   kong ~ # ptp4l
   no interface specified
  
  
  ptp4l does not by default look up any configuration file.
 
 Understood.  Another reason why I have only been runnning in default
 mode when asked to do that, to prove that default mode does not work.
 

I only mentioned you had to pass -f because you said you ran ptp4l on
its own without passing the -f parameter. This means anything in your
configuration wouldn't be applied.

  default.cfg
  is provided to show the default settings. You must specify the
  configuration file via -f option.
 
 Yup, if you look at my incomplete HOWTO you see I do

Re: [Linuxptp-devel] [PATCH RFC 0/6] Improve accuracy with software timestamping

[Keller, Jacob E]

On Tue, 2015-02-17 at 20:25 +0100, Richard Cochran wrote:
 On Tue, Feb 17, 2015 at 12:31:44PM +0100, Miroslav Lichvar wrote:
  The delay message doesn't have to be delayed for the sample to have a
  smaller weight. The delay calculated from the four timestamps will be
  larger than the average when the sync message is delayed, the delay
  message is delayed, or both are delayed. Let's make some ASCII art,
  maybe it can explain it better :).
 
 Nice chart.  (Looks just like one I made recently to explain PTP in a
 private email ;)
 
  time ---
   syncdelay  sync  delay   sync
t1'' t4'   t1'   t4  t1
  master   --++-+-+---+---
  \  /   \   /  \
   \/ \ / \
\  /   \   /\
  slave--++-+-+---+---
   t2''  t3'   t2'   t3  t2
 
  In the current code the filtered path delay is updated from samples
  t1''t2''t3't4' and t1't2't3t4. The offset is calculated from t1t2,
  t1't2' and the current filtered value of the path delay. The problem
  is this can't detect that the sync message was delayed. The extra
  delay will be included in the following update of the path delay,
  after the offset was used to update the clock.
 
 The extra delay is included in the path delay, yes, but the median
 filter should remove it again.
 
  With the change I'm proposing, the offsets/delays of t1't2't3't4' and
  t1t2t3t4 samples are used directly to update the clock and the
  filtered value is used just to determine the weight of the sample.
 
 But in the case where the delay measurement has an error, you penalize
 a perfectly good sync measurement?
 
  Dropping samples completely could be a nice feature too. The problem
  is that the servos are currently not ready to have missed updates and
  it's tricky to determine the right value of the delay at which the
  samples should be dropped. If it's too large, there will be too few
  servo updates, if it's too small, too many bad samples will get in.
 
 Let the end user decide, just like with PI weights.
  
  It can, but it would duplicate the code. That's how I tried to do it
  originally. The servo sample function would need to get the offset
  from the filtered delay, the sync/delay rate and t1, t2, t3, t4 (or
  the sample offset and delay).
 
 You mean that you would duplicate pi.c for example?  I would prefer
 that to having the weight filter hard coded in line.  Possibly you
 could stack the filter on top of the servos?
 
 Thanks,
 Richard

You could have a weighted-pi and weighted-linreg. Then the
weighted.c module would pick pi or linreg based on name but stack it
with weighted mode. Then change the api for servos to take enough data
to do weighted mode.

Then the weighted servo would simply call out to another servo under the
hood.

Regards,
Jake
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 0/5] Add configuration file support to phc2sys

[Keller, Jacob E]

On Mon, 2015-01-19 at 20:15 +0100, Richard Cochran wrote:
 On Mon, Jan 19, 2015 at 06:05:07PM +, Keller, Jacob E wrote:
  On Thu, 2015-01-15 at 12:42 +0100, Richard Cochran wrote:
   On Mon, Jan 12, 2015 at 10:03:42PM +, Keller, Jacob E wrote:
What about section settings for things like the per-adapter stuff? This
is where it got really complicated.
   
   Yup, also for per-port defaults, we need to put on our thinking caps,
   but it shouldn't mean rocket science.

  
  Ya. I think I have a solution for this.
 
 Here is an idea that I have been thinking over (but not coding ;)
 
 An config has a list for sections and a hash table for config items.
 
   struct config {
   list *sections;
   struct hash *table;
   };
 
 A new config has 'sections' and 'table' initially empty. A 'section'
 has a string name and nothing else (that I can think of now).
 
 In addition to the other field I sketched before, the config_item also
 has a pointer to the 'section' to which it belongs.
 
 The items are hashed into the table using section_name:item_name.
 
 There is method to add a section, and there are methods to add, query,
 and change items.
 
   config_add_section(cfg, name);
   config_add_item(cfg, section, name, default_val, range, type, ...);
   config_get_item(cfg, section, name);
   config_set_item(cfg, section, name, val); /* called by file/cmdline 
 parser */
 
 In addition, the file parser needs to know what to scan:
 
   config_item_type(cfg, name); /* called by file parser */
 
 The add/get/set methods can either work with a polymorphic union, or
 they become a family of calls, with one flavor for each of int,
 double, etc.
 
 Now adding a new option just becomes adding two lines, one default
 with ranges config_add_item() and one call to actually use the option
 somewhere.
 
 Thoughts?
 
 Thanks,
 Richard

I like this approach. I'll probably avoid the polymorphic union being
passed around, as I dislike that it makes it too easy for client of
config code to mis-use the types. They should request the type they
want, and if the configuration option doesn't have that type it should
simply error out.

Then we can simply define the default values and available values in the
config block, and the file parser can simply set.

If nothing is set then it gets the standard default value :)

I really like this approach.

Hopefully I can get to actually coding it soon ;)

Is there a standard implementation of a HASH similar to STAIL_QUEUE?

Regards,
Jake
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 4/5] config: add global options check function

[Keller, Jacob E]

On Sun, 2015-01-11 at 12:06 +0100, Richard Cochran wrote:
 On Fri, Jan 09, 2015 at 04:16:32PM -0800, Jacob Keller wrote:
  +static const char *all_global_options[] = {
  +   delayAsymmetry,
  +   logAnnounceInterval,
  +   logSyncInterval,
 
 ...
 
  +   NULL,
  +};
  +
  +/* used by phc2sys to ignore global options meant strictly for ptp4l */
  +enum parser_result parse_known_global_options(const char *option)
  +{
  +   const char **item = all_global_options[0];
  +
  +   while (*item != NULL) {
  +   if (!strcmp(option, *item))
  +   return PARSED_OK;
  +
  +   item++;
  +   }
  +
  +   /* we didn't find option in the list */
  +   return NOT_PARSED;
  +}
 
 So keeping lists of strings to ignore seems gross to me.  It really
 points to the fact that the config code needs some TLC.  For example,
 if we had the struct config_item, then this could be implemented in
 a straightforward, unified way, as a field in the struct.
 
 Thanks,
 Richard

This was just the most straight forward way, however

Agreed, your outline of design seems a lot more straight forward, and
would resolve most of the ugly that is in this series (or pre-existing).

Regards,
Jake
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
www.gigenet.com
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Feature enhancement request

[Keller, Jacob E]

Hi,

I would prefer a mode of programmatically obtaining clock data possibly via our 
private management bus? This way no string processing would have to be done, as 
we could obtain this data in a structured format via the management interface 
possibly..

I don’t want to remove labels, as when reading by a human you have to either 
memorize the order, or go back and read the labels if its only printed one time.

I agree that we should update the temporal vortex method, such as Richard 
suggested as “foreign master’s UTC offset is invalid”

Regards,
Jake

From: Rich Schmidt [mailto:schmidt.r...@gmail.com]
Sent: Monday, December 22, 2014 1:05 PM
To: Richard Cochran
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] Feature enhancement request

The comments by Richard are all well taken.  My history is that I have been 
running tests of various hardware for the past year and have actually stripped 
out ALL the labels in the pr_info()s to make plotting data simpler. I also 
stripped out the [ ] brackets from the time and otherwise economized on the 
output. Once one gets familiar with the output  the labels are not needed; I  
suggest them as a one-time header line instead.  However, for newbies they are 
of course helpful.   So I agree let us not disturb parsing operations at this 
time.

As regards Star Trek, and Dr. Who, I note that according to NASA's Gravity 
Probe-B as announced in 2011 the Earth is indeed in a (tiny) Temporal Vortex, 
and so I assumed that the running in a temporal vortex message simply meant 
that all is well; it was only by reading the code that I figured out why I kept 
getting this message and was able to progress beyond.

Rich

On Mon, Dec 22, 2014 at 3:23 PM, Richard Cochran 
richardcoch...@gmail.commailto:richardcoch...@gmail.com wrote:
Rich,

On Sun, Dec 21, 2014 at 08:38:28PM -0500, Rich Schmidt wrote:
 I find it useful to output offset_stats.mean along with
 offset_stats.stddev in clock_stats_update()  in file clock.c,

While I am not really opposed to this change, still it might break
people's scripts that parse the logging output. We can take this idea
one step further by making the output configurable. That way we can
have our cake and eat it too. But that will have to wait for the next
release.

 also I
 suggest we replace the reference to temporal vortex... See attached diff.

(Don't you like star trek? ;)

Comments follow...

 --- clock.c   2014-12-21 22:09:18.867186011 +
 +++ clock2.c  2014-12-21 21:59:46.252315374 +
 @@ -354,15 +354,17 @@ static void clock_stats_update(struct cl

   /* Path delay stats are updated separately, they may be empty. */
   if (!stats_get_result(s-delay, delay_stats)) {
 - pr_info(rms %4.0f max %4.0f 
 + pr_info(offset %+6.0f +/- rms %4.0f  max %4.0f 
   freq %+6.0f +/- %3.0f 
   delay %5.0f +/- %3.0f,
 - offset_stats.rms, offset_stats.max_abs,
 + offset_stats.mean,
 + offset_stats.stddev, offset_stats.max_abs,

Before we had (rms, max), and you have here (mean, stddev, max).
Did you mean to have (mean, rms, max) instead, or did you forget to
change the label?

   freq_stats.mean, freq_stats.stddev,
   delay_stats.mean, delay_stats.stddev);
   } else {
 - pr_info(rms %4.0f max %4.0f 
 + pr_info(offset %+6.0f +/- rms %4.0f  max %4.0f 
   freq %+6.0f +/- %3.0f,
 + offset_stats.mean,
   offset_stats.rms, offset_stats.max_abs,
   freq_stats.mean, freq_stats.stddev);
   }
 @@ -478,7 +480,7 @@ static void clock_update_slave(struct cl
   pr_warning(foreign master not using PTP timescale);
   }
   if (c-tds.currentUtcOffset  CURRENT_UTC_OFFSET) {
 - pr_warning(running in a temporal vortex);
 + pr_warning(tds.currentUtcOffset  CURRENT_UTC_OFFSET);

Hm. So I guess that you object to this message because it really does
not say what the problem is. The inequality might not make sense
either, to people unfamiliar with C programming cliches. Maybe it
would be better to say something like, foreign master's UTC offset is
invalid, or similar.

Thoughts?

   }
  }

Thanks,
Richard

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp asymmetry correction

[Keller, Jacob E]

 -Original Message-
 From: Christian Riesch [mailto:christian.rie...@omicron.at]
 Sent: Tuesday, December 09, 2014 11:37 PM
 To: Keller, Jacob E; Richard Cochran; linuxptp-
 de...@lists.sourceforge.net
 Subject: RE: [Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp asymmetry
 correction
 
 Jake,
 
 -Original Message-
 From: Keller, Jacob E [mailto:jacob.e.kel...@intel.com]
 Sent: Wednesday, December 10, 2014 1:00 AM
 To: Richard Cochran; linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp
 asymmetry
 correction
 
 In regards to the comment about whether a negative value should be
 acceptable, I think it should not. The reason is because I can't think of
 any
 scenario in which hardware timestamps the packet *before* it arrives...
 That
 is, there should never be a hardware which negative latency as that is
 physically not possible.
 
 We did a few measurements of egress and ingress timestamping delays
 (see [1]). We actually measured negative delays for some hardware (see
 Table III in [1]). Our conclusion was that this hardware must already be
 (over)compensating PHY delays, however I did not yet manage to ask
 this question to the manufacturer. But it shows that there are cases
 where one wants to compensate a negative egress or ingress latency.
 
 Regards,
 Christian
 

Fair enough. I had not thought of over-compensated delays. I think we can just 
modify the configs code to allow negative numbers, as the scanf function should 
already do it. Just treat numbers which have no sign indicator as positive.

Regards,
Jake


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/4] Time stamp asymmetry correction

[Keller, Jacob E]

 -Original Message-
 From: Jiri Benc [mailto:jb...@redhat.com]
 Sent: Wednesday, December 10, 2014 12:11 AM
 To: Delio Brignoli
 Cc: linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] [PATCH RFC 0/4] Time stamp asymmetry
 correction
 
 On Mon, 8 Dec 2014 14:04:56 +0100, Delio Brignoli wrote:
  Yes, I was thinking it would allow to query if the driver supports this
  feature and get/set current offsets.
 
 I agree. That way, with correctly implemented drivers the user will
 get the right correction for free but will be still able to overrule
 the values.
 
 What I'm thinking of is having an ethtool operation to get/set
 ingress/egress correction. This will be handled in the kernel (i.e. not
 propagated to the drivers to prevent misuse). The driver provides
 initial correction values (or zero if they're unknown) but user space
 is free to alter them or reset them to the initial values. It is
 obviously per-interface setting.
 
 A nice bonus is this will work with all program using the time stamping
 interface, not just linuxptp.
 
 This is compatible with Richard's patchset, only the config options
 would call the ethtool op instead of doing the correction in ptp4l.
 
  Jiri
 
 --

I really like this idea. Done in the kernel, but allow driver to initiate 
correct values if necessary. It does need to support link speeds somehow so 
that change in link speed gets the correct values.

Not 100% sure the best way to handle link speeds, but definitely would be 
better to do this in kernel.

Regards,
Jake
 


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/4] Time stamp asymmetry correction

[Keller, Jacob E]

 -Original Message-
 From: Richard Cochran [mailto:richardcoch...@gmail.com]
 Sent: Wednesday, December 10, 2014 7:54 AM
 To: Jiri Benc
 Cc: linuxptp-devel@lists.sourceforge.net
 Subject: Re: [Linuxptp-devel] [PATCH RFC 0/4] Time stamp asymmetry
 correction
 
 On Wed, Dec 10, 2014 at 10:20:06AM +0100, Jiri Benc wrote:
  actual addition/subtraction should be indeed done in ptp4l. It also
  seems that ptp4l will need to listen for link change events.
 
 Or this can be done by a helper program.
 
 Thanks,
 Richard
 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and
 Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/os
 tg.clktrk
 

A helper program which queries link speed changes,  (or any other possible 
changes which affect latency) and uses an ethtool (or ptp maybe?) ioctl to get 
the suggested latency with 0 being the default for unimplemented.

Then it can suggest the value and user can override it if necessary.

This seems like the simplest solution.

Thanks,
Jake


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp asymmetry correction

[Keller, Jacob E]

In regards to the comment about whether a negative value should be acceptable, 
I think it should not. The reason is because I can't think of any scenario in 
which hardware timestamps the packet *before* it arrives... That is, there 
should never be a hardware which negative latency as that is physically not 
possible.

Regards,
Jake

 -Original Message-
 From: Richard Cochran [mailto:richardcoch...@gmail.com]
 Sent: Tuesday, December 09, 2014 12:55 PM
 To: linuxptp-devel@lists.sourceforge.net
 Subject: [Linuxptp-devel] [PATCH RFC V2 0/4] Time stamp asymmetry
 correction
 
 * ChangeLog
 ** V2
- rename the configuration options to match those in the standards
 
 Most (or all?) hardware provides time stamps that are offset from the
 actual point at the reference plane. The amount of delay is asymmetrical
 between ingress and egress, and depending on the particular technology,
 MAC or PHY, and link speed, there can be jitter in the delay.
 
 Sometimes the manufacturer specifies the amount of expected delay. This
 patch series provides a way for the user to correct the delays based on
 values from the data sheet or based on empirical data.
 
 This series was tested with an i210 paired with a dp83640 using a short
 cable. These devices have their delay values listed in the data sheet.
 PPS signals in both directions showed a remaining offset of about 120
 nanoseconds, which matches the sum of uncertainties (40 and 80) given
 for the i210 card at the 100 MBit link speed.
 
 Comments are welcome.
 
 Thanks,
 Richard
 
 
 Richard Cochran (4):
   Introduce a helper function to identify valid (non-zero) time stamps.
   Invoke the clock check even if the time stamp nanoseconds field is
 zero.
   config: Introduce options for correcting transmit and receive delays.
   port: correct transmit and receive time stamps for their calibrated
 delays.
 
  config.c|   12 
  default.cfg |2 ++
  ds.h|2 ++
  gPTP.cfg|2 ++
  msg.c   |2 +-
  msg.h   |   10 ++
  port.c  |   35 ---
  ptp4l.8 |   12 
  ptp4l.c |2 ++
  9 files changed, 75 insertions(+), 4 deletions(-)
 
 --
 1.7.10.4
 
 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.
 clktrk
 ___
 Linuxptp-devel mailing list
 Linuxptp-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC 0/3] Poor man's boundary clock

[Keller, Jacob E]

On Sat, 2014-11-01 at 20:00 +0100, Richard Cochran wrote:
 Before releasing v1.5, I wanted to test phc2sys's new automatic mode
 in order to run a BC using a bunch of PCIe cards, but I found it did
 not quite work. First of all, the port logic bails out when the PHC
 device don't match, and secondly phc2sys has one line bug.
 
 After hacking those two problems away, the BC worked okay. With a
 GM-BC-slave setup, the slave had about an additional 9 usec offset.
 
 I made the jbod a non-default option, so that users who want this
 really know not to expect perfect performance.
 
 After this series and the SO_SELECT_ERR_QUEUE get settled, I will
 release the 1.5 version.
 
 Feedback is most welcome.
 
 Thanks,
 Richard

This looks great. Hopefully in a few days I will be able to set this up
and see how it works with one of the Intel NICs.

Thanks,
Jake

 
 
 Richard Cochran (3):
   config: add a option to enable a poor man's boundary clock.
   port: allow running a boundary clock with multiple clock devices.
   phc2sys: make automatic mode actually work.
 
  config.c|   13 +
  config.h|1 +
  default.cfg |1 +
  ds.h|1 +
  gPTP.cfg|1 +
  phc2sys.c   |1 -
  port.c  |6 +-
  ptp4l.8 |   12 +++-
  ptp4l.c |1 +
  9 files changed, 34 insertions(+), 3 deletions(-)
 


--
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v4] linuxptp: add phc_ctl program to help debug PHC devices

[Keller, Jacob E]

On Fri, 2014-07-18 at 19:23 +0200, Richard Cochran wrote:
 Jacob,
 
 I tried this program out, and ...
 
 On Thu, Jul 10, 2014 at 03:49:30PM -0700, Jacob Keller wrote:
  +.BI caps
  +Display the device capabiltiies. This is the default command if no 
  commands are
  +provided.
 
 With no command, nothing is displayed.
 

Oops!

  +Quickly sanity check frequency slewing by setting slewing frequency by 
  positive
  +10%, resetting clock to 0.0 time, waiting for 10 seconds, and then reading
  +time. The time read back should be (roughly) 11 seconds, since the clock 
  was
  +slewed 10% faster.
  +.RS
  +\f(CWphc_ctl /dev/ptp0 freq 1000 set 0.0 wait 10.0 get
 
 This is only 1 % not 10 %.
 

Yep missed a zero :) I'll get these fixed.

Thanks,
Jake

 
 Thanks,
 Richard


--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 3/5] Move signal handling to util.c.

[Keller, Jacob E]

On Thu, 2014-07-10 at 11:35 +0200, Miroslav Lichvar wrote:
 On Wed, Jul 09, 2014 at 06:55:23PM +, Keller, Jacob E wrote:
  On Wed, 2014-07-09 at 10:21 +0200, Miroslav Lichvar wrote:
   I'm not sure I understand your question. Would you prefer to export
   the running variable and use it in other modules directly instead of
   the is_running fuction?
   
  
  Oh nope. I see now you use the variable inside the module, and function
  outside.
  
  I was just thinking for consistency to just always use the function.
 
 I think that's what the patch does, or not? The running variable is
 used only in is_running() in util.c and everything else uses
 is_running().
 

Ah yes, you are right, I saw the - line and misread the patch.

Thanks,
Jake
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v3] linuxptp: add phc_ctl program to help debug PHC devices

[Keller, Jacob E]

On Wed, 2014-07-09 at 06:51 +0200, Richard Cochran wrote:
 The man page has an issue...
 
 On Mon, Jun 30, 2014 at 02:19:34PM -0700, Jacob Keller wrote:
 
  +.TP
  +.BI cmp
  +Compare the PHC clock device to CLOCK_REALTIME, using the best method 
  available.
  +.TP caps
  +Display the device capabiltiies. This is the default command if no 
  commands are
  +provided.
  +.TP wait  seconds
 
 Do you need .BI for 'caps' and 'wait' here?
 
 man -l phc_ctl.8  /tmp/out
 standard input:67: warning: numeric expression expected (got `c')
 standard input:70: warning: numeric expression expected (got `w')
 
 Thanks,
 Richard

Hmm. I'm not really sure, but possibly the .BI isn't necessary?

Thanks,
Jake
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 0/5] Allow running multiple pmc or phc2sys instances

[Keller, Jacob E]

On Tue, 2014-07-08 at 16:14 +0200, Miroslav Lichvar wrote:
 The first patch allows using phc2sys with non-default server UDS path.
 The next three patches add signal handling to pmc/phc2sys and remove
 the UDS socket before exit. The last patch appends the process ID to
 the local UDS path so each pmc or phc2sys process has its own socket.
 
 Miroslav Lichvar (5):
   phc2sys: Add option to set path to ptp4l UDS.
   Remove socket when closing UDS transport.
   Move signal handling to util.c.
   Close client UDS transport before exit.
   Append PID to client UDS paths.
 
  phc2sys.8 |  4 
  phc2sys.c | 49 -
  pmc.8 |  2 +-
  pmc.c | 22 --
  ptp4l.c   | 23 ++-
  uds.c |  8 
  util.c| 32 
  util.h| 14 ++
  8 files changed, 113 insertions(+), 41 deletions(-)
 

Aside from my one nit regarding use if while(running) vs maintaining
the use of while(is_running()), the series looks great.

Thanks,
Jake
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] linuxptp on ubuntu 14.04

[Keller, Jacob E]

On Thu, 2014-06-19 at 09:23 +0100, Andrei Perietanu wrote:
  now, when this happened, I noticed my system clock went rogue - for
 some
  reason it thinks it's July 11th 12:00 am (it's configured toget time
  automatically from the internet)
 
 That is strange. You must be sure to turn off NTP first, if you want
 to use phc2sys (or ptp4l with SW time stamping). Otherwise, the two
 programs will fight each other.
 
 I don't think I have ntp running:
 
 sudo /etc/init.d/ntp stop
 sudo: /etc/init.d/ntp: command not found
 

sudo /etc/init.d/ntpd stop
sudo /etc/init.d/ntpdate stop

 sudo service ntp stop
 ntp: unrecognized service
 
 
 that's what I found online about stopping ntp at least; is there some
 other command I'm supposed to run?
 
  2. why did my system clock decide to change tu such an awkward
  value?
 
 Are you perhaps still using SW time stamping? That would explain it.
 

It certainly appears like you are using software timestamps.

 
 I'm actually using HW timestamping and can't find anything on the
 internet about this problem...
 
 
 Thanks,
 Andrei
 
  
 

Thanks,
Jake

 
 
 On Wed, Jun 18, 2014 at 5:10 PM, Richard Cochran
 richardcoch...@gmail.com wrote:
 On Wed, Jun 18, 2014 at 04:49:38PM +0100, Andrei Perietanu
 wrote:
  I tried the easy option *run ptp4l with the '-2' (L2
 transport) flag* but
  that changed nothing... so I tried something different: I
 changed
  tx_timestamp_timeout  from 1000 to 100 and now I get some
 output on the
  slave node.
 
 
 That is really very suspicious. I think this must be a red
 herring,
 and something *else* changed.
 
  The output of the master node:
 
  ptp4l[622024.340]: selected /dev/ptp1 as PTP clock
  ptp4l[622024.340]: port 1: INITIALIZING to LISTENING on
 INITIALIZE
  ptp4l[622024.340]: port 0: INITIALIZING to LISTENING on
 INITIALIZE
  ptp4l[622026.448]: port 1: new foreign master
 00e04b.fffe.3b5762-1
  ptp4l[622030.527]: selected best master clock
 00e04b.fffe.3b5762
  ptp4l[622030.527]: assuming the grand master role
  ptp4l[622030.527]: port 1: LISTENING to GRAND_MASTER on
 RS_GRAND_MASTER
 
  and that's it..stops at that
 
 
 Normal for a master node.
 
  The output of the slave node:
 
  ptp4l[459942.424]: selected /dev/ptp0 as PTP clock
  ptp4l[459942.425]: port 1: INITIALIZING to LISTENING on
 INITIALIZE
  ptp4l[459942.425]: port 0: INITIALIZING to LISTENING on
 INITIALIZE
  ptp4l[459949.497]: port 1: LISTENING to MASTER on
  ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
  ptp4l[459949.497]: selected best master clock
 00e04b.fffe.3b5762
  ptp4l[459949.497]: assuming the grand master role
  ptp4l[459953.600]: port 1: new foreign master
 002590.fffe.f2c1e4-1
  ptp4l[459957.700]: selected best master clock
 002590.fffe.f2c1e4
  ptp4l[459957.700]: port 1: MASTER to UNCALIBRATED on
 RS_SLAVE
 
 ...
  ptp4l[459976.701]: master offset145 s2 freq  +16538
 path delay 16238
 
 
 This is also working.
 
  now, when this happened, I noticed my system clock went
 rogue - for some
  reason it thinks it's July 11th 12:00 am (it's configured
 toget time
  automatically from the internet)
 
 
 That is strange. You must be sure to turn off NTP first, if
 you want
 to use phc2sys (or ptp4l with SW time stamping). Otherwise,
 the two
 programs will fight each other.
 
  So, two questions come to mind:
  1. is ptp working correcly now? O sould I see some messages
 on the master's
  console as well
 
 
 Yes, looks like it.
 
  2. why did my system clock decide to change tu such an
 awkward  value?
 
 
 Are you perhaps still using SW time stamping? That would
 explain it.
 
 Thanks,
 Richard
 
 
 
 
 
 The information transmitted is intended only for the person or entity
 to which it is addressed and may contain confidential and/or
 privileged material. Any review, retransmission, dissemination or
 other use of or taking of any action in reliance upon this information
 by persons or entities other than the intended recipient is
 prohibited. If you receive this in error please contact the sender and
 delete the material from any computer immediately. It is the policy of
 Klas  Limited to disavow the sending of offensive material and should
 you consider that the material contained in the message is offensive
 you should contact the sender 

Re: [Linuxptp-devel] phc2sys detecting ptp4l exit (was: Re: [PATCH v2 00/27] automatic phc2sys configuration)

[Keller, Jacob E]

On Thu, 2014-06-19 at 16:18 +0200, Jiri Benc wrote:
 On Thu, 3 Apr 2014 11:53:40 +0200, Miroslav Lichvar wrote:
  As a future improvement, I think it would be nice if ptp4l sent a
  notification when exiting so phc2sys could stop its synchronization
  and wait until ptp4l is running again.
 
 I was thinking about how to implement this. In particular, I'd like
 this to be more robust and detect also ptp4l being killed.
 
 The most obvious option, detecting whether other side closed its part
 of the unix socket, would require changing it from SOCK_DGRAM to
 SOCK_SEQPACKET. Which means ptp4l would have to keep track of all
 uds clients, deal with accept calls, etc., and most importantly, poll
 these additional file descriptors. That would require quite substantial
 changes throughout the whole code. But then, uds is treated specially
 in most places, perhaps stopping pretending it's another transport
 wouldn't be bad.


That seems like a whole lot of work, though it does sound like the most
robust solution. Especially difficult since we would be un-abstracting
uds as a transport type..

 
 Other option is polling from phc2sys every phc_interval. That's ugly,
 consuming unnecessary resources and unreliable anyway.
 

This is probably not good.

 Better option would be asking ptp4l about its PID and monitoring it.
 That would be reliable enough but still polling, although rather cheap
 polling.
 

This is most likely the best compromise, and easiest to implement..

Thanks,
Jake

 Thoughts? Different ideas?
 
 Thanks,
 
  Jiri
 


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] linuxptp on ubuntu 14.04

[Keller, Jacob E]

On Tue, 2014-06-17 at 16:45 +0100, Andrei Perietanu wrote:
 anyway running the command with -l7 option *sudo ptp4l -i eth1 -l7
 -f /etc/ptp4l.conf -m -q*
 
 
 I get:
 ptp4l[535940.417]: selected /dev/ptp1 as PTP clock
 ptp4l[535940.417]: PI servo: sync interval 1.000 kp 0.700 ki 0.30
 ptp4l[535940.417]: port 1: INITIALIZING to LISTENING on INITIALIZE
 ptp4l[535940.417]: port 0: INITIALIZING to LISTENING on INITIALIZE
 ptp4l[535942.634]: port 1: setting asCapable
 ptp4l[535942.634]: port 1: new foreign master 00e04b.fffe.3b5762-1
 ptp4l[535946.639]: selected best master clock 00e04b.fffe.3b5762
 ptp4l[535946.639]: assuming the grand master role
 ptp4l[535946.639]: port 1: LISTENING to GRAND_MASTER on
 RS_GRAND_MASTER
 ptp4l[535946.640]: port 1: master tx announce timeout
 ptp4l[535947.639]: port 1: master sync timeout
 ptp4l[535948.640]: port 1: master tx announce timeout
 ptp4l[535948.641]: port 1: master sync timeout
 ptp4l[535949.641]: port 1: master sync timeout
 ptp4l[535950.641]: port 1: master tx announce timeout
 ptp4l[535950.641]: port 1: master sync timeout
 ptp4l[535951.641]: port 1: master sync timeout
 ptp4l[535952.642]: port 1: master tx announce timeout
 ptp4l[535952.642]: port 1: master sync timeout
 ptp4l[535953.642]: port 1: master sync timeout
 ptp4l[535954.643]: port 1: master tx announce timeout
 ptp4l[535954.643]: port 1: master sync timeout
 ptp4l[535955.644]: port 1: master sync timeout
 

I suggest using:

sudo ptp4l -i eth1 -l6 -f /etc/ptp4l.conf -m -q


The l7 output displays a bunch of much less useful output, which can
clutter the display.

Hopefully this helps,
Jake
 
 
 
 and the other node prints out port1: delay timeout   repeatedly
 
 
 So something is still no right...
 
 
 Thanks for any suggestions,
 
 Andrei 
 
 
 
 
 
 
 
 
 On Tue, Jun 17, 2014 at 4:39 PM, Andrei Perietanu
 andrei.periet...@klastelecom.com wrote:
 On Tue, Jun 17, 2014 at 04:00:36PM +0100, Andrei Perietanu
 wrote:
  I tried now  *sudo ptp4l -i eth1 -i9 -f /etc/ptp4l.conf -m
 -q* on both
  machines
  and I still don't see too much output:
 
 
 I think that should be -l9, not -i9.
 
 
 Well that's what I initially thought but there is no -l9 (1-7
 are valid values)
 
 
 
 
 
 On Tue, Jun 17, 2014 at 4:33 PM, Miroslav Lichvar
 mlich...@redhat.com wrote:
 On Tue, Jun 17, 2014 at 04:00:36PM +0100, Andrei
 Perietanu wrote:
  I tried now  *sudo ptp4l -i eth1 -i9
 -f /etc/ptp4l.conf -m -q* on both
  machines
  and I still don't see too much output:
 
 
 I think that should be -l9, not -i9.
 
 --
 Miroslav Lichvar
 
 
 
 
 
 
 
 The information transmitted is intended only for the person or entity
 to which it is addressed and may contain confidential and/or
 privileged material. Any review, retransmission, dissemination or
 other use of or taking of any action in reliance upon this information
 by persons or entities other than the intended recipient is
 prohibited. If you receive this in error please contact the sender and
 delete the material from any computer immediately. It is the policy of
 Klas  Limited to disavow the sending of offensive material and should
 you consider that the material contained in the message is offensive
 you should contact the sender immediately and also your I.T. Manager.
 
 Klas Telecom Inc., a Virginia Corporation with offices at 1101
 30th St. NW, Washington, DC 20007.
 
 Klas Limited (Company Number 163303) trading as Klas Telecom, an Irish
 Limited Liability Company, with its registered office at Fourth Floor,
 One Kilmainham Square, Inchicore Road, Kilmainham, Dublin 8, Ireland.
 
 --
 HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
 Find What Matters Most in Your Big Data with HPCC Systems
 Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
 Leverages Graph Analysis for Fast Processing  Easy Data Exploration
 http://p.sf.net/sfu/hpccsystems
 ___
 Linuxptp-devel mailing list
 Linuxptp-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net

Re: [Linuxptp-devel] addition of a get frequency op?

[Keller, Jacob E]

On Sat, 2014-06-07 at 17:39 +0200, Richard Cochran wrote:
 On Fri, Jun 06, 2014 at 06:29:56PM +, Keller, Jacob E wrote:
  Hi Richard (and anyone else who might care),
  
  I have thinking it might be worth adding an extra (optional) operation
  for ptp devices which allows querying the current adjusted frequency
  value. This could be useful for debugging purposes, since there is no
  way today to obtain this information from the device.
 
 But we already have this. Calling clock_adjtime with a cleared struct
 timex will return this in the 'freq' field. Linuxptp uses a wrapper
 function, clockadj_get_freq.
 
 Or did you mean something else?
 
 Thanks,
 Richard

Can this be done on the ptp clock device? If so, this would be fine :)

Thanks,
Jake
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] addition of a get frequency op?

[Keller, Jacob E]

Hi Richard (and anyone else who might care),

I have thinking it might be worth adding an extra (optional) operation
for ptp devices which allows querying the current adjusted frequency
value. This could be useful for debugging purposes, since there is no
way today to obtain this information from the device.

I was thinking about hacking up a patch for this, but wanted to see if
you thought this was a good idea first. I also wasn't sure exactly where
best to provide the operation, since there is no equivalent get
frequency on the clock.

Thanks,
Jake
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH 2/2] hwtstamp_ctl: use SIOCGHWTSTAMP ioctl before destructively setting policy

[Keller, Jacob E]

On Tue, 2014-06-03 at 09:26 +0200, Richard Cochran wrote:
 On Mon, Jun 02, 2014 at 08:59:27PM +, Keller, Jacob E wrote:
  
  Too long of a line? I usually try to follow the Linux practice which
  allows long lines if they only contain print statement, so that it's
  easier to grep the source for where the error came from..
 
 Linux has way more lines of code to grep through than we do.
  
  I can change it though. I don't think the message itself is too long
  though.
 
 Yes, the text is fine. I don't mind having string constants divided
 into two chunks.
 
  I can break these onto their own lines, I suppose.
 
 Yes, please.
 
 Thanks,
 Richard

Alright, I'll go ahead and do that.

Thanks,
Jake

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] linuxptp in kernel 2.6.30+?

[Keller, Jacob E]

Hi,

Regarding changes to the ptp4l protocol stack, you would have to change
this if you changed the API in any way, there would need to be
modifications to the ptp4l end.

I think someone from Redhat may be able to answer your question about
the backport of the PHC subsystem better.

You might try searching for CentOS, as that may have been the source of
the kernel. I don't know if we had an explicit conversation about
backporting, but as Richard said, it is not as trivial as you might
think.

Thanks,
Jake

On Tue, 2014-06-03 at 19:25 +, Daniel Le wrote:
 I browsed both the linuxptp devel and user mail archives, but couldn't see 
 any email thread about RHEL back porting of linuxptp and ethtool. Perhaps I 
 didn't look at the right places or missed it. Does someone know where the 
 relevant information is located? I would much appreciate to learn about the 
 specific issues of back porting in the past and how they were solved or still 
 remain unsolved? Does 'buggy' refer to the PTP protocol itself or accuracy 
 achievement or both?
 
 For deployment with software timestamping, there is no need to back port the 
 PHC and to run the phc2sys program. Is that correct? And changes to PTP 
 protocol stack in the user space are necessary if an implementation does not 
 make use of SO_TIMESTAMPING socket, but have instead some non-generic TX/RX 
 FPGA-based hardware timestamping.
 
 Thanks!
 Daniel
 
 
 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their 
 applications. Written by three acclaimed leaders in the field, 
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Linuxptp-devel mailing list
 Linuxptp-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH v4] hwtstamp_ctl: use SIOCGHWTSTAMP ioctl before destructively setting policy

[Keller, Jacob E]

On Tue, 2014-06-03 at 14:03 -0700, Jacob Keller wrote:
 This patch modifies the hwtstamp_ctl program, so that it will (attempt
 to) use the SIOCGHWTSTAMP ioctl to non-destructively read the current
 hardware timestamping policy, prior to setting it with SIOCSHWTSTAMP.
 
 This change has 3 primary advantages:
 
 1) It allows reading the current settings of the device, which was
previously not possible since SIOCSHWTSTAMP is destructive.
 2) The default behavior without rx-filter or tx-type selected on the
command line is no longer destructive, since it does not attempt to
set the values to 0. The user must explicitly request to disable the
settings, by using the provided options.
 3) It allows only modifying tx-type or rx-filter separately, without
destroying the other setting.
 
 This patch supersedes a previous submission which added a -g flag. This
 new method of getting first is more advantageous and doesn't require
 adding an additional option flag.
 
 - v4
 * only display results if command succeeds, as the contents are otherwise
   expected to be identical to what we passed in.
 
 Signed-off-by: Jacob Keller jacob.e.kel...@intel.com


Sorry for the thrash, this is the correct patch. The previous versions
had minor issues with them, including spacing issue, and displaying
meaningless output from the IOCTL if it failed.

Thanks,
Jake

 ---
  hwstamp_ctl.8 | 11 ++-
  hwstamp_ctl.c | 55 ---
  2 files changed, 58 insertions(+), 8 deletions(-)
 
 diff --git a/hwstamp_ctl.8 b/hwstamp_ctl.8
 index cece74f61866..0ae4c4a6a456 100644
 --- a/hwstamp_ctl.8
 +++ b/hwstamp_ctl.8
 @@ -15,7 +15,7 @@ hwstamp_ctl \- set time stamping policy at the driver level
  
  .SH DESCRIPTION
  .B hwstamp_ctl
 -is a program used to set the hardware time stamping policy at the network
 +is a program used to set and get the hardware time stamping policy at the 
 network
  driver level with the
  .B SIOCSHWTSTAMP
  .BR ioctl (2).
 @@ -27,6 +27,15 @@ values are hints to the driver what it is expected to do. 
 If the requested
  fine-grained filtering for incoming packets is not supported, the driver may
  time stamp more than just the requested types of packets.
  
 +If neither
 +.I tx-type
 +nor
 +.I rx-filter
 +values are passed to the program, it will use the
 +.B SIOCGHWTSTAMP
 +.BR ioctl(2)
 +to non-destructively read the current hardware time stamping policy.
 +
  This program is a debugging tool. The
  .BR ptp4l (8)
  program does not need this program to function, it will set the policy
 diff --git a/hwstamp_ctl.c b/hwstamp_ctl.c
 index 456d96b09147..ec5dd6df1dca 100644
 --- a/hwstamp_ctl.c
 +++ b/hwstamp_ctl.c
 @@ -30,6 +30,7 @@
  #include net/if.h
  
  #include version.h
 +#include missing.h
  
  static void usage(char *progname)
  {
 @@ -84,6 +85,7 @@ int main(int argc, char *argv[])
   struct hwtstamp_config cfg;
   char *device = NULL, *progname;
   int c, err, fd, rxopt = HWTSTAMP_FILTER_NONE, txopt = HWTSTAMP_TX_OFF;
 + int setrx = 0, settx = 0;
  
   /* Process the command line arguments. */
   progname = strrchr(argv[0], '/');
 @@ -94,9 +96,11 @@ int main(int argc, char *argv[])
   device = optarg;
   break;
   case 'r':
 + setrx = 1;
   rxopt = atoi(optarg);
   break;
   case 't':
 + settx = 1;
   txopt = atoi(optarg);
   break;
   case 'v':
 @@ -116,6 +120,7 @@ int main(int argc, char *argv[])
   usage(progname);
   return -1;
   }
 +
   if (rxopt  HWTSTAMP_FILTER_NONE ||
   rxopt  HWTSTAMP_FILTER_PTP_V2_DELAY_REQ ||
   txopt  HWTSTAMP_TX_OFF || txopt  HWTSTAMP_TX_ON) {
 @@ -129,8 +134,6 @@ int main(int argc, char *argv[])
   strncpy(ifreq.ifr_name, device, sizeof(ifreq.ifr_name));
  
   ifreq.ifr_data = (void *) cfg;
 - cfg.tx_type= txopt;
 - cfg.rx_filter  = rxopt;
  
   fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
   if (fd  0) {
 @@ -138,15 +141,53 @@ int main(int argc, char *argv[])
   return -1;
   }
  
 - err = ioctl(fd, SIOCSHWTSTAMP, ifreq);
 + /* First, attempt to get the current settings. */
 + err = ioctl(fd, SIOCGHWTSTAMP, ifreq);
   if (err  0) {
   err = errno;
 - perror(SIOCSHWTSTAMP failed);
 - if (err == ERANGE)
 - fprintf(stderr, The requested time stamping mode is 
 not supported by the hardware.\n);
 + if (err == ENOTTY)
 + fprintf(stderr,
 + Kernel does not have support 
 + for non-destructive SIOCGHWTSTAMP.\n);
 + else if (err == EOPNOTSUPP)
 + fprintf(stderr,
 + Device driver does not 

Re: [Linuxptp-devel] [PATCH 2/4] Change level of negative path delay messages to debug.

[Keller, Jacob E]

Hooray! I was always annoyed by this output.

Thanks Miroslav,
Jake

On Wed, 2014-01-08 at 14:23 +0100, Miroslav Lichvar wrote:
 Negative path delay measurements are expected with E2E, the user doesn't
 need to know when that happens.
 
 Signed-off-by: Miroslav Lichvar mlich...@redhat.com
 ---
  clock.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)
 
 diff --git a/clock.c b/clock.c
 index 9d5a937..063155b 100644
 --- a/clock.c
 +++ b/clock.c
 @@ -997,13 +997,13 @@ void clock_path_delay(struct clock *c, struct timespec 
 req, struct timestamp rx,
   pd = tmv_div(pd, 2);
  
   if (pd  0) {
 - pr_warning(negative path delay %10lld, pd);
 - pr_warning(path_delay = (t2 - t3) + (t4 - t1) - (c1 + c2 + 
 c3));
 - pr_warning(t2 - t3 = %+10lld, t2 - t3);
 - pr_warning(t4 - t1 = %+10lld, t4 - t1);
 - pr_warning(c1 %10lld, c1);
 - pr_warning(c2 %10lld, c2);
 - pr_warning(c3 %10lld, c3);
 + pr_debug(negative path delay %10lld, pd);
 + pr_debug(path_delay = (t2 - t3) + (t4 - t1) - (c1 + c2 + c3));
 + pr_debug(t2 - t3 = %+10lld, t2 - t3);
 + pr_debug(t4 - t1 = %+10lld, t4 - t1);
 + pr_debug(c1 %10lld, c1);
 + pr_debug(c2 %10lld, c2);
 + pr_debug(c3 %10lld, c3);
   }
  
   c-path_delay = filter_sample(c-delay_filter, pd);


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] ptp4l push notifications

[Keller, Jacob E]

On Sat, 2013-12-07 at 08:13 +0100, Richard Cochran wrote:
 On Fri, Dec 06, 2013 at 05:11:48PM +, Keller, Jacob E wrote:
  
  What do you think about having an extended message which indicates I am
  ready to receive.. then once ptp4l gets this, it then starts pushing a
  set of notifications on events.
  
  I like this better than a configuration option, since it means ptp4l
  only sends messages on the uds when some management interface has
  requested it...
  
  Thoughts?
 
 I think this should be configurable at run time, *not* as a
 configuration file option. I imagine having a custom management
 message that allows the client to request different kinds of status
 information, like port state, BMC result, and so on. (Or maybe the
 client can specify management ID values.)  Whenever any of the
 watched status bits change value, then ptp4l will push RESPONSE
 messages as if replying to a GET.
 
 How does that sound to you?
 

That's exactly what I was imagining with my post above.

I also dislike the idea of static configured at start. This seems the
most useful.

How would this work with multiple management interfaces? Is that even
possible?

IE: multiple programs connected? Does the management interface properly
only send to a single client? If so we can use the client-request
details to send the data across to only that client. This way only
clients which perform the proper request message get the result.

Thanks,
Jake

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] ptp4l push notifications

[Keller, Jacob E]

On Wed, 2013-12-04 at 18:40 +0100, Richard Cochran wrote:
 On Tue, Dec 03, 2013 at 09:33:21PM +, Keller, Jacob E wrote:
 
  I like this idea. I also think if we supported the push updates from
  ptp4l, where ptp4l sends data over the management interface it would
  enable the phc2sys to update it's internal state without requiring
  polling as it could update whenever it receives data on the management
  socket.
 
 Right, I like the push idea too, and for me it has higher priority
 than removing the static port array.

I was thinking about ways to implement push-based messages...

What do you think about having an extended message which indicates I am
ready to receive.. then once ptp4l gets this, it then starts pushing a
set of notifications on events.

I like this better than a configuration option, since it means ptp4l
only sends messages on the uds when some management interface has
requested it...

Thoughts?

It also doesn't seem too difficult to implement.. I haven't had time yet
to try my hand at something, but I just wanted to see if we could hash
out implementation that we think is right. 

Regards,
Jake
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel