linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] (no subject)

[Wolfgang W. <wol...@br...>]

-----Richard Cochran <ric...@gm...> schrieb: -----
> > I still get the same error (Error 403, Read access required).
> 
> Changed settings again.  Does it work for you now?

Yes, now it works fine (even without logging in to SourceForge).
Thanks for fixing this!

regards, Wolfgang

Re: [Linuxptp-users] (no subject)

[Richard C. <ric...@gm...>]

On Mon, Oct 31, 2016 at 03:49:39PM +0100, Wolfgang Wallner wrote:
> I still get the same error (Error 403, Read access required).

Changed settings again.  Does it work for you now?

Thanks,
Richard

Re: [Linuxptp-users] (no subject)

[Richard C. <ric...@gm...>]

On Mon, Oct 31, 2016 at 07:31:35PM +0100, Richard Cochran wrote:
> On Mon, Oct 31, 2016 at 05:29:30PM +0100, Delio Brignoli wrote:
> > 
> > Yes, but I stated as much in my previous message: the switch was not
> > compliant. However, linuxptp isn’t compliant either on the RX side
> > which is the reason for my patch.
> 
> The whole reason for the Path Trace is to avoid loops.

Having thought about it more, I would argue that we already are
compliant.  Let me explain.

The Path Trace TLV is meant to avoid loops, but according to the
standard it must be dropped if the clock list does not fit into the
MTU.  This is a property of the network, not of a particular node.  If
the TLV will be dropped in a switch, then there is no point for the
master to send one in the first place.

If a network cannot support the TLV, then the administrator must know
this, and he must have some other means to prevent loops, otherwise
the gPTP protocol will fail.

Our implementation doesn't have a simple AVB on/off option, but rather
each aspect can be configured individually.  In a non-Path-Trace
capable network, the admin simply sets "path_trace_enabled 0" in the
configuration file.

See?

Thanks,
Richard

Re: [Linuxptp-users] AVB transportSpecific and phc2sys

[Richard C. <ric...@gm...>]

On Mon, Oct 31, 2016 at 12:17:54PM +0100, Richard Cochran wrote:
> This is bug where the gloabl transportSpecific setting is being
> applied to the UDS interface.  I'll fix this soon.

I take this back.  I thought about it some more and decided not to
change this.  Here is why.

First of all, if you run AVB according to the standard, then you
should not run phc2sys in the first place.  The standard tells you to
leave the local clock free running and calculate the phase and
frequency numerically.  So strictly speaking, you would write a
program similar to phc2sys that queries TIME_STATUS_NP and uses that
information to tune the system clock.

[ Ok, so that is rather weak, since the end station can and should
  tune its PHC if it wants to.  Who cares what the standard says.  In
  fact, our gPTP.cfg doesn't even set the free_running option.  But
  the next reason is a better one. ]

Secondly, we already have UDS clients that expect the global
transportSpecific flag to appear in the UDS messages.  The pmc program
has a command line option for this.  If we change the UDS port to mask
the flag away, this will break existing management clients.

So I think the work around is a reasonable solution for phc2sys.  If
anything, phc2sys should also support the transportSpecific flag, but
this can wait until we can pass a config file to it.  We don't want
yet another command line option, IMHO.

Thanks,
Richard

Re: [Linuxptp-users] (no subject)

[Keller, J. E <jac...@in...>]

On Mon, 2016-10-31 at 08:58 +0100, Wolfgang Wallner wrote:
> 5) The PPS signal produced by the i210 seems to be unreliable
> 
> I know that the right place to discuss i210 problems would be LMKL, I
> just mention this here as I assume several of you might have
> experience with this chip.
> I observe that if I enable the PPS signal on the software definable
> pins of the i210 it initially works fine.
> But if there are state changes in the PTP stack because I
> unplug/replug other devices to the network, the PPS signal of the
> i210 can disappear.
> Calling the corresponding ioctls again (and thus setting the register
> of the i210 again) restores the signal.
> Does this match your experience?

What version of i210 driver are you using? An in-kernel version? What
kernel version? There have been some fixes to the upstream driver
recently which may have resolved this issue. The i210 driver was not
resetting the PTP signals when it changed link status, and I believe
this may have been fixed. If not, providing more detail may be useful
in forwarding this to the current driver owner.

Thanks,
Jake

> 
> -------------------------------------------------------------------
> -----------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive. 
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] (no subject)

[Richard C. <ric...@gm...>]

On Mon, Oct 31, 2016 at 05:29:30PM +0100, Delio Brignoli wrote:
> 
> Yes, but I stated as much in my previous message: the switch was not
> compliant. However, linuxptp isn’t compliant either on the RX side
> which is the reason for my patch.

The whole reason for the Path Trace is to avoid loops.  At face value,
this is not a bad idea.  But the exception means that really large
networks will not have the check.  Brilliant.  Just where the feature
make the most sense, they turn it off.

I am hoping that the next editions of 802.1AS and 1588 will remove
some of the brain farts and not add too many new ones. 

One can always hope...

Thanks,
Richard

Re: [Linuxptp-users] (no subject)

[Delio B. <dbr...@au...>]

> On 31 Oct 2016, at 16:06, Richard Cochran <ric...@gm...> wrote:
> 
> On Mon, Oct 31, 2016 at 02:07:01PM +0100, Delio Brignoli wrote:
>>> @Delio, I see you allow announce without the TLV:
>>> 
>>>  https://github.com/audioscience/linuxptp/commit/0b6d8ca73332391af9bddc25177df254b066d669
>>> 
>>> Can you tell us why?
>> 
>> This is tricky because in some places 802.1AS-2011 seems to imply a
>> TLV is mandatory but when you dig down into the implementation
>> details you find that: in 10.3.13.2.1 (f) txAnnounce() appends the
>> TLV *only if* it doesn’t exceed the transport’s MTU and in
>> 10.3.10.2.1 (c) and (d) qualifyAnnounce() accepts an announce
>> message without a TLV. So a TLV is present *if* it fits in the
>> transport’s MTU but a compliant implementation has to accept an
>> announce message without path trace TLV.
> 
> Those passages permit dropping the TLV when it would cause the message
> to exceed the frame size.  Let's do a little math.
[...]
> Was the switch you had operating in such a large network?

Or the MTU may be artificially restricted, who knows... but I am not saying linuxptp should be changed to conditionally drop the TLV.

> If the TLV is missing, chances are that the sender is out of
> compliance, don't you think?

Yes, but I stated as much in my previous message: the switch was not compliant. However, linuxptp isn’t compliant either on the RX side which is the reason for my patch.

Regards
—
Delio

Re: [Linuxptp-users] (no subject)

[Delio B. <dbr...@au...>]

Hi Richard, Wolfgang,

> On 31 Oct 2016, at 12:17, Richard Cochran <ric...@gm...> wrote:
> 
>   https://github.com/audioscience/linuxptp
> 
> I just briefly compared v1.4 with his asi1230-master, and nothing
> earth shaking stood out.

Yes, but there is number of things I’d like to contribute upstream and didn’t get a chance to. There may be a window of opportunity coming up when I’ll be able to try the the latest release with some patches applied and get (at least some of) them accepted upstream.

>> 2) Differences in the BMC algorithm
>> 
>> Is it possible to specify a different best master clock algorithm than that of the default PTP profile?
> 
> No, not yet.  I have some patches in the works for allowing different
> BMC variants, because some profiles will require it.
> 
> However, the AS mode should work fine with the default BMC…

I can confirm AS mode works with the default BMC. As Richard says below the differences result in extra delays but peers eventually “converge”.

>> 4) Path Trace TLV
>> 
>> Announce messages without a Path Trace TLV are ignored by my device if I set path_trace_enabled to 1.
>> I think in 802.1AS a Path Trace TLV should be attached to announce messages, but announce messages should not be dropped if a received message does not have one.
> 
> First you complain that we don't follow AS exactly, and then you
> complain that we *do* follow it exactly!

Actually we don’t follow it *exactly* :-P

> Path Trace is specified in 10.5.3, and there is no hint of it being
> optional.  In fact, this is required in the PICS.  Any master who
> sends an Announce must conform.  Look at page 240.
> 
>   MIMSTR-8   Does the Announce message body comply
>              with the requirements in 10.5.3.1 and
>              Table 10-7?
> 
> @Delio, I see you allow announce without the TLV:
> 
>   https://github.com/audioscience/linuxptp/commit/0b6d8ca73332391af9bddc25177df254b066d669
> 
> Can you tell us why?

This is tricky because in some places 802.1AS-2011 seems to imply a TLV is mandatory but when you dig down into the implementation details you find that: in 10.3.13.2.1 (f) txAnnounce() appends the TLV *only if* it doesn’t exceed the transport’s MTU and in 10.3.10.2.1 (c) and (d) qualifyAnnounce() accepts an announce message without a TLV. So a TLV is present *if* it fits in the transport’s MTU but a compliant implementation has to accept an announce message without path trace TLV. 

I found this out when we encountered a (not yet compliant) switch which didn’t append path trace TLVs. When I investigated the standard I was surprised to find out we weren’t compliant either.

Additionally the path trace TLV could be one of many TLVs appended to the announce message and it doesn’t have to be the first. Even with my patch applied linuxptp expects the path trace TLV to be the first one to appear. I would like to fix it but we considered it a non-urgent issue and had to shift focus to something else so it never got done.

Regards
—
Delio

[Linuxptp-users] 802.1AS discussion

[Richard C. <ric...@gm...>]

On Mon, Oct 31, 2016 at 03:49:39PM +0100, Wolfgang Wallner wrote:
> This leads to another point that I have not figured out yet.
> If I would like to get notified in another program about PTP state changes, what is the preferred interface?

We use the management interface from 1588.  Remote programs can query
the status.  In addition, local programs can open a UNIX Domain Socket
to both query status and reconfigure the ptp4l program.

We have a utility program called pmc, and you can use that in your
control scripts.  If you need more direct control, then you can send
management pakets from your program directly.  The phc2sys is an
example of that method.

> Should we change the subject to something meaningful like "802.1AS discussion" now or would that cause trouble with the e.g. the thread view in mailing list archives?

Done!

Thanks,
Richard

Re: [Linuxptp-users] (no subject)

[Richard C. <ric...@gm...>]

On Mon, Oct 31, 2016 at 02:07:01PM +0100, Delio Brignoli wrote:
> > @Delio, I see you allow announce without the TLV:
> > 
> >   https://github.com/audioscience/linuxptp/commit/0b6d8ca73332391af9bddc25177df254b066d669
> > 
> > Can you tell us why?
> 
> This is tricky because in some places 802.1AS-2011 seems to imply a
> TLV is mandatory but when you dig down into the implementation
> details you find that: in 10.3.13.2.1 (f) txAnnounce() appends the
> TLV *only if* it doesn’t exceed the transport’s MTU and in
> 10.3.10.2.1 (c) and (d) qualifyAnnounce() accepts an announce
> message without a TLV. So a TLV is present *if* it fits in the
> transport’s MTU but a compliant implementation has to accept an
> announce message without path trace TLV.

Those passages permit dropping the TLV when it would cause the message
to exceed the frame size.  Let's do a little math.

The Announce message takes 78 bytes, the TLV takes 4 + 8N bytes, and
an Ethernet frame can be as large as 1500 bytes.  So the gPTP network
would have to have 177 hops before dropping the TLV is allowed.

Was the switch you had operating in such a large network?

If the TLV is missing, chances are that the sender is out of
compliance, don't you think?

> Additionally the path trace TLV could be one of many TLVs appended
> to the announce message and it doesn’t have to be the first. Even
> with my patch applied linuxptp expects the path trace TLV to be the
> first one to appear. I would like to fix it but we considered it a
> non-urgent issue and had to shift focus to something else so it
> never got done.

You are right, in the presence of multiple TLVs, the Path Trace TLV
could come appear at another position, and you are right that it is a
non-issue.

When we come to the place where 177 switch AVB networks are common and
many more TLVs are defined, then we'll have to fix these points.

Thanks,
Richard

Re: [Linuxptp-users] (no subject)

[Wolfgang W. <wol...@br...>]

Hi Delio,

> >> 2) Differences in the BMC algorithm
> >> 
> >> Is it possible to specify a different best master clock algorithm than that of the default PTP profile?
> > 
> > No, not yet.  I have some patches in the works for allowing different
> > BMC variants, because some profiles will require it.
> > 
> > However, the AS mode should work fine with the default BMC…
> 
> I can confirm AS mode works with the default BMC. As Richard says below the differences result in extra delays but peers eventually “converge”.

Ok, thanks for the clarification.

> >> 4) Path Trace TLV
> > @Delio, I see you allow announce without the TLV:
> > 
> >   https://github.com/audioscience/linuxptp/commit/0b6d8ca73332391af9bddc25177df254b066d669
> > 
> > Can you tell us why?
> 
> This is tricky because in some places 802.1AS-2011 seems to imply a TLV is mandatory but when you dig down into the implementation details you find that: in 10.3.13.2.1 (f) txAnnounce() appends the TLV *only if* it doesn’t exceed the transport’s MTU and in 10.3.10.2.1 (c) and (d) qualifyAnnounce() accepts an announce message without a TLV. So a TLV is present *if* it fits in the transport’s MTU but a compliant implementation has to accept an announce message without path trace TLV. 

I haven't studied the 802.1AS specification in detail yet, but your description matches my current understanding of how the path trace TLVs work.

regards, Wolfgang

Re: [Linuxptp-users] (no subject)

[Wolfgang W. <wol...@br...>]

Hello Richard,

> > Do I need any further permissions for my sourceforge account to view the archives?
> 
> I just fiddled with the SF settings for the lists.  Can you see it now?
>  
> (I have been recommending gmane instead, but that site went down.)

I still get the same error (Error 403, Read access required).

> > LinuxPTP 802.1AS issues:
> > 
> > 1) phc2sys does not work if transportSpecific is set to 1
> > 
> > When I set transportSpecific to 1 (as required by 802.1AS) in my config file, the phc2sys tool does not work.
> > My test config file looks as follows:
> > 
> > $ cat TestConfig.cfg
> > 
> > [global]
> > transportSpecific           1
> > 
> > When I call ptp4l with "sudo ptp4l -f TestConfig.cfg -i enp2s0 -p
> > /dev/ptp0 -m" (without that config file) and phc2sys with "sudo
> > phc2sys -a -r -r -m -S 0.2 -F 0.2" it only prints
> > "phc2sys[5236.261]: Waiting for ptp4l..." every second. If I start
> > ptp4l without that config file or comment out that one line, phc2sys
> > works as expected.
> 
> Can you try this instead?
> 
> 	[global]
> 	[enp2s0]
> 	#
> 	# Not in the global section!
> 	#
> 	transportSpecific	1
> 
> This is bug where the gloabl transportSpecific setting is being
> applied to the UDS interface.  I'll fix this soon.

Thanks for the hint, with this configuration it works as expected.

> > 2) Differences in the BMC algorithm
> > 
> > Is it possible to specify a different best master clock algorithm than that of the default PTP profile?
> 
> No, not yet.  I have some patches in the works for allowing different
> BMC variants, because some profiles will require it.
> 
> However, the AS mode should work fine with the default BMC...
> 

Ok, thanks for the clarification.

> > The BMCA of the default PTP profile and 802.1AS are similar, but not the same.
> > Noticable differences are:
> > 
> > *) There is no pre-master state in 802.1AS
> 
> This only causes a master to wait an additional announce period before
> sending the first announce and sync messages.  It doesn't affect how
> we inter-operate in a gPTP network.
> 
> > *) There is no foreign master qualification in 802.1AS
> 
> Again, this doesn't affect correctness WRT how we inter-operate.  This
> only affects the slave, causing a short delay before starting
> (internal) synchronization.
> 
> > *) If a master stops sending sync messages but still sends announce messages, this should trigger a state change in the slave according to 802.1AS (configured via syncReceiptTimeoutTime), while it is fine in default PTP.
> 
> This is implemented.  Did you test this?

Sorry, this is my fault.
I just checked my config and syncReceiptTimeout is set to 0.
I thought I had already changed it on my test device.

> > 3) PDelay uses wrong clock
> > 
> > 802.1AS specifies in 11.1.2 the following:
> > 
> > "In practice, t1 and t4 are measured relative to the LocalClock entity of the initiator time-aware system, and t2 and t3 are measured relative to the LocalClock entity of the responder time-aware system."
> > 
> > The LocalClock in 802.1AS is a local free running oscillator, in contrast to the recovered clock that is created via PTP.
> > However, I see in the t2 and t3 timestamps of my LinuxPTP instances times refering to the time that is transfered via PTP.
> 
> No, the interval T3-T2 is converted into the local time base.
> See get_raw_delay().

I will have a lock at it.

> > 4) Path Trace TLV
> > 
> > Announce messages without a Path Trace TLV are ignored by my device if I set path_trace_enabled to 1.
> > I think in 802.1AS a Path Trace TLV should be attached to announce messages, but announce messages should not be dropped if a received message does not have one.
> 
> First you complain that we don't follow AS exactly, and then you
> complain that we *do* follow it exactly!

Please don't get me wrong, I'm not complaining :)
I just want to discuss what seemed non-compliant.

> Path Trace is specified in 10.5.3, and there is no hint of it being
> optional.  In fact, this is required in the PICS.  Any master who
> sends an Announce must conform.  Look at page 240.
> 
>    MIMSTR-8   Does the Announce message body comply
>               with the requirements in 10.5.3.1 and
>               Table 10-7?
> 
> @Delio, I see you allow announce without the TLV:
> 
>    https://github.com/audioscience/linuxptp/commit/0b6d8ca73332391af9bddc25177df254b066d669
> 
> Can you tell us why?
> 
> > 5) The PPS signal produced by the i210 seems to be unreliable
> > 
> > I know that the right place to discuss i210 problems would be LMKL, I just mention this here as I assume several of you might have experience with this chip.
> > I observe that if I enable the PPS signal on the software definable pins of the i210 it initially works fine.
> > But if there are state changes in the PTP stack because I unplug/replug other devices to the network, the PPS signal of the i210 can disappear.
> > Calling the corresponding ioctls again (and thus setting the register of the i210 again) restores the signal.
> > Does this match your experience?
> 
> Yes.  You must stop and restart again whenever the time jumps.  You
> should write a script to monitor ptp4l and restart when needed.

Ok, thanks for the information!

This leads to another point that I have not figured out yet.
If I would like to get notified in another program about PTP state changes, what is the preferred interface?

regards, Wolfgang

PS: I forgot to set the mail subject in my initial mailing list post in the morning.
Should we change the subject to something meaningful like "802.1AS discussion" now or would that cause trouble with the e.g. the thread view in mailing list archives?

Re: [Linuxptp-users] (no subject)

[Richard C. <ric...@gm...>]

Wolfgang,

In general I am not aware of any issues regarding AS compatibility.
We tried very had to follow the standard as closely as possible.
Delio (on CC) might have more to say about this.  He maintains his own
AS branch on github.

   https://github.com/audioscience/linuxptp

I just briefly compared v1.4 with his asi1230-master, and nothing
earth shaking stood out.

On Mon, Oct 31, 2016 at 08:58:57AM +0100, Wolfgang Wallner wrote:
> Do I need any further permissions for my sourceforge account to view the archives?

I just fiddled with the SF settings for the lists.  Can you see it now?

(I have been recommending gmane instead, but that site went down.)

> LinuxPTP 802.1AS issues:
> 
> 1) phc2sys does not work if transportSpecific is set to 1
> 
> When I set transportSpecific to 1 (as required by 802.1AS) in my config file, the phc2sys tool does not work.
> My test config file looks as follows:
> 
> $ cat TestConfig.cfg
> 
> [global]
> transportSpecific           1
> 
> When I call ptp4l with "sudo ptp4l -f TestConfig.cfg -i enp2s0 -p
> /dev/ptp0 -m" (without that config file) and phc2sys with "sudo
> phc2sys -a -r -r -m -S 0.2 -F 0.2" it only prints
> "phc2sys[5236.261]: Waiting for ptp4l..." every second. If I start
> ptp4l without that config file or comment out that one line, phc2sys
> works as expected.

Can you try this instead?

	[global]
	[enp2s0]
	#
	# Not in the global section!
	#
	transportSpecific	1

This is bug where the gloabl transportSpecific setting is being
applied to the UDS interface.  I'll fix this soon.

> 2) Differences in the BMC algorithm
> 
> Is it possible to specify a different best master clock algorithm than that of the default PTP profile?

No, not yet.  I have some patches in the works for allowing different
BMC variants, because some profiles will require it.

However, the AS mode should work fine with the default BMC...

> The BMCA of the default PTP profile and 802.1AS are similar, but not the same.
> Noticable differences are:
> 
> *) There is no pre-master state in 802.1AS

This only causes a master to wait an additional announce period before
sending the first announce and sync messages.  It doesn't affect how
we inter-operate in a gPTP network.

> *) There is no foreign master qualification in 802.1AS

Again, this doesn't affect correctness WRT how we inter-operate.  This
only affects the slave, causing a short delay before starting
(internal) synchronization.

> *) If a master stops sending sync messages but still sends announce messages, this should trigger a state change in the slave according to 802.1AS (configured via syncReceiptTimeoutTime), while it is fine in default PTP.

This is implemented.  Did you test this?
 
> 3) PDelay uses wrong clock
> 
> 802.1AS specifies in 11.1.2 the following:
> 
> "In practice, t1 and t4 are measured relative to the LocalClock entity of the initiator time-aware system, and t2 and t3 are measured relative to the LocalClock entity of the responder time-aware system."
> 
> The LocalClock in 802.1AS is a local free running oscillator, in contrast to the recovered clock that is created via PTP.
> However, I see in the t2 and t3 timestamps of my LinuxPTP instances times refering to the time that is transfered via PTP.

No, the interval T3-T2 is converted into the local time base.
See get_raw_delay().
 
> 4) Path Trace TLV
> 
> Announce messages without a Path Trace TLV are ignored by my device if I set path_trace_enabled to 1.
> I think in 802.1AS a Path Trace TLV should be attached to announce messages, but announce messages should not be dropped if a received message does not have one.

First you complain that we don't follow AS exactly, and then you
complain that we *do* follow it exactly!

Path Trace is specified in 10.5.3, and there is no hint of it being
optional.  In fact, this is required in the PICS.  Any master who
sends an Announce must conform.  Look at page 240.

   MIMSTR-8   Does the Announce message body comply
              with the requirements in 10.5.3.1 and
              Table 10-7?

@Delio, I see you allow announce without the TLV:

   https://github.com/audioscience/linuxptp/commit/0b6d8ca73332391af9bddc25177df254b066d669

Can you tell us why?

> 5) The PPS signal produced by the i210 seems to be unreliable
> 
> I know that the right place to discuss i210 problems would be LMKL, I just mention this here as I assume several of you might have experience with this chip.
> I observe that if I enable the PPS signal on the software definable pins of the i210 it initially works fine.
> But if there are state changes in the PTP stack because I unplug/replug other devices to the network, the PPS signal of the i210 can disappear.
> Calling the corresponding ioctls again (and thus setting the register of the i210 again) restores the signal.
> Does this match your experience?

Yes.  You must stop and restart again whenever the time jumps.  You
should write a script to monitor ptp4l and restart when needed.

Thanks,
Richard

[Linuxptp-users] (no subject)

[Wolfgang W. <wol...@br...>]

Hello LinuxPTP community,

We (B&R) are currently evaluating the available open-source PTP implementations (LinxPTP, PTPd, OpenAVB) for the usage as IEEE 802.1AS stacks.
As part of this effort, I have spent some time to test LinuxPTP on a B&R industrial PC with an Intel i210 NIC.
LinuxPTP already supports most of 802.1AS, but I have also found some issues, which I would like to discuss with you.
I have listed the individual issues below, feedback on any of these issues would be welcome.
Especially if they are already known, if someone is working on them, or if the LinuxPTP community would be interested in contributions for these issues. 

kind regards,
Wolfgang Wallner

PS: I tried to scan the archives before posting this message.
Unfortunately I always get "Error 403: Read access required" when I try to access https://sourceforge.net/p/linuxptp/mailman/linuxptp-users/
Do I need any further permissions for my sourceforge account to view the archives?


LinuxPTP 802.1AS issues:

1) phc2sys does not work if transportSpecific is set to 1

When I set transportSpecific to 1 (as required by 802.1AS) in my config file, the phc2sys tool does not work.
My test config file looks as follows:

$ cat TestConfig.cfg

[global]
transportSpecific           1

When I call ptp4l with "sudo ptp4l -f TestConfig.cfg -i enp2s0 -p /dev/ptp0 -m" (without that config file) and phc2sys with "sudo phc2sys -a -r -r -m -S 0.2 -F 0.2" it only prints "phc2sys[5236.261]: Waiting for ptp4l..." every second. If I start ptp4l without that config file or comment out that one line, phc2sys works as expected.

2) Differences in the BMC algorithm

Is it possible to specify a different best master clock algorithm than that of the default PTP profile?
I could not find any such option, please correct me if I have overlooked something.

The BMCA of the default PTP profile and 802.1AS are similar, but not the same.
Noticable differences are:

*) There is no pre-master state in 802.1AS
*) There is no foreign master qualification in 802.1AS
*) If a master stops sending sync messages but still sends announce messages, this should trigger a state change in the slave according to 802.1AS (configured via syncReceiptTimeoutTime), while it is fine in default PTP.

3) PDelay uses wrong clock

802.1AS specifies in 11.1.2 the following:

"In practice, t1 and t4 are measured relative to the LocalClock entity of the initiator time-aware system, and t2 and t3 are measured relative to the LocalClock entity of the responder time-aware system."

The LocalClock in 802.1AS is a local free running oscillator, in contrast to the recovered clock that is created via PTP.
However, I see in the t2 and t3 timestamps of my LinuxPTP instances times refering to the time that is transfered via PTP.

4) Path Trace TLV

Announce messages without a Path Trace TLV are ignored by my device if I set path_trace_enabled to 1.
I think in 802.1AS a Path Trace TLV should be attached to announce messages, but announce messages should not be dropped if a received message does not have one.

5) The PPS signal produced by the i210 seems to be unreliable

I know that the right place to discuss i210 problems would be LMKL, I just mention this here as I assume several of you might have experience with this chip.
I observe that if I enable the PPS signal on the software definable pins of the i210 it initially works fine.
But if there are state changes in the PTP stack because I unplug/replug other devices to the network, the PPS signal of the i210 can disappear.
Calling the corresponding ioctls again (and thus setting the register of the i210 again) restores the signal.
Does this match your experience?

Re: [Linuxptp-users] [Linuxptp-devel] Planning release 1.8

[Richard C. <ric...@gm...>]

On Tue, Oct 18, 2016 at 04:25:48PM +0200, Tino Mettler wrote:
> How about a git branch "experimental" or similar?

FYI, I just pushed out the rtnl work.  The log prefix stuff will have
to wait until I have a chance to try it out myself...

Thanks,
Richard

Re: [Linuxptp-users] [Linuxptp-devel] Planning release 1.8

[Keller, J. E <jac...@in...>]

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

Re: [Linuxptp-users] [Linuxptp-devel] Planning release 1.8

[Tino M. <tin...@al...>]

On Tue, 2016-10-18 at 14:23 +0200, Richard Cochran wrote:
> On Tue, Oct 18, 2016 at 12:43:39PM +0200, Tino Mettler wrote:
> > I'd like to test, but I don't see any commits since the 1.7
> > release,
> > except for one commit from August. I'm
> > using git://git.code.sf.net/p/linuxptp/code. Is this intended?
> 
> 
> Yes, I don't push out anything unless the patches have been reviewed
> or at least had a chance (at least one week) to be reviewed.

How about a git branch "experimental" or similar?

Regards,
Tino

Re: [Linuxptp-users] [Linuxptp-devel] Planning release 1.8

[Richard C. <ric...@gm...>]

On Tue, Oct 18, 2016 at 12:43:39PM +0200, Tino Mettler wrote:
> I'd like to test, but I don't see any commits since the 1.7 release,
> except for one commit from August. I'm
> using git://git.code.sf.net/p/linuxptp/code. Is this intended?

Yes, I don't push out anything unless the patches have been reviewed
or at least had a chance (at least one week) to be reviewed.  Are you
able to apply patches from the list?

The patches in question are:

   16.Oct'16 To linuxptp-dev      [PATCH RFC 0/2] Fix one-step regression
   16.Oct'16 To linuxptp-dev      ├─>[PATCH RFC 1/2] Fix regression in one-step configuration.
   16.Oct'16 To linuxptp-dev      └─>[PATCH RFC 2/2] clock: Remove cruft from the creation method.

   16.Oct'16 To linuxptp-dev      [PATCH V3 0/7] Link state tracking
   16.Oct'16 To linuxptp-dev      ├─>[PATCH V3 1/7] rtnl: Introduce RT netlink sockets.
   16.Oct'16 To linuxptp-dev      ├─>[PATCH V3 2/7] sk: Add a method to obtain a socket for utility purposes.
   16.Oct'16 To linuxptp-dev      ├─>[PATCH V3 3/7] clock: Remove stray semicolon.
   16.Oct'16 To linuxptp-dev      ├─>[PATCH V3 4/7] clock: Fix coding style within a helper function.
   16.Oct'16 To linuxptp-dev      ├─>[PATCH V3 5/7] clock: Remember each port's interface index.
   16.Oct'16 To linuxptp-dev      ├─>[PATCH V3 6/7] port: Provide methods to set and get the link status.
   16.Oct'16 To linuxptp-dev      └─>[PATCH V3 7/7] clock: Monitor the link status using a RT netlink socket.

   17.Oct'16 Miroslav Lichva      [Linuxptp-devel] [PATCH RFC 0/3] Optional prefix for ptp4l/phc2sys log messages
   17.Oct'16 Miroslav Lichva      ├─>[Linuxptp-devel] [PATCH RFC 1/3] Add options to prefix ptp4l and phc2sys log messages.
   17.Oct'16 Miroslav Lichva      ├─>[Linuxptp-devel] [PATCH RFC 2/3] timemaster: prefix ptp4l and phc2sys messages.
   17.Oct'16 Miroslav Lichva      ├─>[Linuxptp-devel] [PATCH RFC 3/3] timemaster: check support for SW time stamping.

If you can't test them easily, then I can delay the release until
about one week after pushing them out.  The "link state tracking"
series will be changed once more as Miroslav suggested.

Thanks,
Richard

Re: [Linuxptp-users] [Linuxptp-devel] Planning release 1.8

[Tino M. <tin...@al...>]

On Sun, 2016-10-16 at 13:09 +0200, Richard Cochran wrote:

> If you know of any other problems with 1.7 or in the current git
> head,
> please let me know right away.


Hi Richard,

I'd like to test, but I don't see any commits since the 1.7 release,
except for one commit from August. I'm
using git://git.code.sf.net/p/linuxptp/code. Is this intended?

Regards,
Tino

Re: [Linuxptp-users] [Linuxptp-devel] Planning release 1.8

[Tino M. <tin...@al...>]

On Sun, 2016-10-16 at 13:09 +0200, Richard Cochran wrote:

> If you know of any other problems with 1.7 or in the current git
> head,
> please let me know right away.

Hi Richard,

I'd like to test, but I don't see any commits since the 1.7 release,
except for one commit from August. I'm
using git://git.code.sf.net/p/linuxptp/code. Is this intended?

Regards,
Tino

Re: [Linuxptp-users] [Linuxptp-devel] Planning release 1.8

[Richard C. <ric...@gm...>]

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

Re: [Linuxptp-users] [Linuxptp-devel] Planning release 1.8

[Keller, J. E <jac...@in...>]

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

[Linuxptp-users] Planning release 1.8

[Richard C. <ric...@gm...>]

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.

If you know of any other problems with 1.7 or in the current git head,
please let me know right away.

Thanks,
Richard

Re: [Linuxptp-users] issue with NetXtreme II BCM57810

[Luke B. <luk...@lm...>]

----- Original Message -----
> From: "Luke Bigum" <luk...@lm...>
> To: "linuxptp-users" <lin...@li...>
> Sent: Tuesday, 4 October, 2016 15:18:05
> Subject: Re: [Linuxptp-users] issue with NetXtreme II BCM57810

> ----- Original Message -----
>> From: "Richard Cochran" <ric...@gm...>
>> To: "Luke Bigum" <luk...@lm...>
>> Cc: "linuxptp-users" <lin...@li...>
>> Sent: Tuesday, 4 October, 2016 14:28:39
>> Subject: Re: [Linuxptp-users] issue with NetXtreme II BCM57810
> 
>> I don't have this card nor was I involved in reviewing the driver.
>> The file, drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c, contains
>> the PHC stuff.
>> 
>> Looking at bnx2x_init_cyclecounter(), they have mult = shift = 1.
>> That implies that
>> 
>>  nanoseconds = ticks / 2
>> 
>> and that their internal clock runs at 2 GHz!
>> 
>> Maybe they meant to have shift=0, or maybe your card has a (model
>> specific 1 GHz clock).
>> 
>> Anyhow, the testptp result is clear enough.  You should take this up
>> with the driver maintainers.
>> 
>> Thanks,
>> Richard
> 
> Thanks Richard, that's helpful. I'll track it down.


For the Internet record, Qlogic have fixed this in version 7.14.05 of their 10Gig driver pack. I've compiled this bnx2x driver against a 3.18 kernel and the PHC advances at regular speed. The source and some binaries are available here:

http://driverdownloads.qlogic.com/QLogicDriverDownloads_UI/SearchByProduct.aspx?ProductCategory=322&Product=1249&Os=65

I don't know when they will be added to the mainline kernel.



-Luke

---

LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/

Recognised by the most prestigious business and technology awards
 
2016 Best Trading & Execution, HFM US Technology Awards
2016, 2015, 2014, 2013 Best FX Trading Venue - ECN/MTF, WSL Institutional Trading Awards

2015 Winner, Deloitte UK Technology Fast 50
2015, 2014, 2013, One of the UK's fastest growing technology firms, The Sunday Times Tech Track 100
2015 Winner, Deloitte EMEA Technology Fast 500
2015, 2014, 2013 Best Margin Sector Platform, Profit & Loss Readers' Choice Awards

---

FX and CFDs are leveraged products that can result in losses exceeding your deposit. They are not suitable for everyone so please ensure you fully understand the risks involved.

This message and its attachments are confidential, may not be disclosed or used by any person other than the addressee and are intended only for the named recipient(s). This message is not intended for any recipient(s) who based on their nationality, place of business, domicile or for any other reason, is/are subject to local laws or regulations which prohibit the provision of such products and services. This message is subject to the following terms (http://lmax.com/pdf/general-disclaimers.pdf), if you cannot access these, please notify us by replying to this email and we will send you the terms. If you are not the intended recipient, please notify the sender immediately and delete any copies of this message.

LMAX Exchange is the trading name of LMAX Limited. LMAX Limited operates a multilateral trading facility. LMAX Limited is authorised and regulated by the Financial Conduct Authority (firm registration number 509778) and is a company registered in England and Wales (number 6505809).

LMAX Hong Kong Limited is a wholly-owned subsidiary of LMAX Limited. LMAX Hong Kong is licensed by the Securities and Futures Commission in Hong Kong to conduct Type 3 (leveraged foreign exchange trading) regulated activity with CE Number BDV088.

Re: [Linuxptp-users] issue with NetXtreme II BCM57810

[Luke B. <luk...@lm...>]

----- Original Message -----
> From: "Richard Cochran" <ric...@gm...>
> To: "Luke Bigum" <luk...@lm...>
> Cc: "linuxptp-users" <lin...@li...>
> Sent: Tuesday, 4 October, 2016 14:28:39
> Subject: Re: [Linuxptp-users] issue with NetXtreme II BCM57810

> I don't have this card nor was I involved in reviewing the driver.
> The file, drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c, contains
> the PHC stuff.
> 
> Looking at bnx2x_init_cyclecounter(), they have mult = shift = 1.
> That implies that
> 
>  nanoseconds = ticks / 2
> 
> and that their internal clock runs at 2 GHz!
> 
> Maybe they meant to have shift=0, or maybe your card has a (model
> specific 1 GHz clock).
> 
> Anyhow, the testptp result is clear enough.  You should take this up
> with the driver maintainers.
> 
> Thanks,
> Richard

Thanks Richard, that's helpful. I'll track it down.
---

LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/

Recognised by the most prestigious business and technology awards
 
2016 Best Trading & Execution, HFM US Technology Awards
2016, 2015, 2014, 2013 Best FX Trading Venue - ECN/MTF, WSL Institutional Trading Awards

2015 Winner, Deloitte UK Technology Fast 50
2015, 2014, 2013, One of the UK's fastest growing technology firms, The Sunday Times Tech Track 100
2015 Winner, Deloitte EMEA Technology Fast 500
2015, 2014, 2013 Best Margin Sector Platform, Profit & Loss Readers' Choice Awards

---

FX and CFDs are leveraged products that can result in losses exceeding your deposit. They are not suitable for everyone so please ensure you fully understand the risks involved.

This message and its attachments are confidential, may not be disclosed or used by any person other than the addressee and are intended only for the named recipient(s). This message is not intended for any recipient(s) who based on their nationality, place of business, domicile or for any other reason, is/are subject to local laws or regulations which prohibit the provision of such products and services. This message is subject to the following terms (http://lmax.com/pdf/general-disclaimers.pdf), if you cannot access these, please notify us by replying to this email and we will send you the terms. If you are not the intended recipient, please notify the sender immediately and delete any copies of this message.

LMAX Exchange is the trading name of LMAX Limited. LMAX Limited operates a multilateral trading facility. LMAX Limited is authorised and regulated by the Financial Conduct Authority (firm registration number 509778) and is a company registered in England and Wales (number 6505809).

LMAX Hong Kong Limited is a wholly-owned subsidiary of LMAX Limited. LMAX Hong Kong is licensed by the Securities and Futures Commission in Hong Kong to conduct Type 3 (leveraged foreign exchange trading) regulated activity with CE Number BDV088.