linuxptp-users

[Linuxptp-users] (no subject)

[Baya O. <bay...@gm...>]

Hallo Dear linuxptp-users,

Please could any one from you help me answer this question.

For our Project Needs,  I would like to have the possibility of doing the
following :

I would like to run two demons of ptp4l on one machine as a slave , that is
slave 1 and slave 2

and two demons of ptp4l on the second machine with two master:  master1
,master 2.

I would like to have : slave1 synchronising with master1 and
                                  slave2 synchronising with master2.


Is this that possible?

Thank you in advance for your help,

Baya

[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] (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

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?

[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 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)

[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)

[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

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] 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)

[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)

[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)

[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)

[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] (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

[Linuxptp-users] (no subject)

[Tomek K. <tto...@gm...>]

I've been following this post:
https://sourceforge.net/p/linuxptp/mailman/message/35980617/
But when I try the following command I obtain 2 interface with grandmaster
role and I don't think this working well.

ubuntu@tk-vm:~$ sudo ptp4l -i eth0 -i ens7 -S -m
sudo: unable to resolve host tomasz-koziak-vm
ptp4l[523036.385]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[523036.385]: port 2: INITIALIZING to LISTENING on INITIALIZE
ptp4l[523036.386]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[523043.190]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[523043.190]: selected best master clock fa163e.fffe.fdf714
ptp4l[523043.190]: assuming the grand master role
ptp4l[523044.123]: port 2: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[523044.123]: selected best master clock fa163e.fffe.fdf714
ptp4l[523044.123]: assuming the grand master role
ptp4l[523044.123]: assuming the grand master role

Do you have any ideas what could be wrong?

Thanks,
Tom

[Linuxptp-users] (no subject)

[Kelly, M. <Mar...@as...>]

I'd like to be able to submit bugs to linuxptp-users mailing lists.

Thanks,

Marcus Kelly
Senior Software Engineer
Astronics Custom Control Concepts Inc.
6020 S. 190th St. Kent, WA 98032
P: 206.575.0933
C: 206-910-0727


[cid:image001.jpg@01D519FD.41210140]

www.astronics.com<http://www.astronics.com/>


This E-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return E-mail.

Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.

Re: [Linuxptp-users] (no subject)

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

On Mon, Jun 08, 2020 at 07:00:14PM +0000, Kelly, Marcus wrote:
> I'd like to be able to submit bugs to linuxptp-users mailing lists.

Yes, please do.  That is what the list is for!

Thanks,
Richard

[Linuxptp-users] (no subject)

[Sebastian P. <seb...@gm...>]

As you mentioned i stopped systemd-timesyncd,and now the statement clock
jumped forward isnt there,but the clock isnt still synchronized.
*Master clock Machine*
 command 1: sudo ptp4l -i enp0s3  -S -m -2  //S indicates software stamping
and -2 indicates that it's an ethernet connection to the slave Cock and -m
is just a flag to print to the stdout.
o/p:
ptp4l[1316.449]: port 1 (enp0s3): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1316.449]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on
INIT_COMPLETE
ptp4l[1316.449]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on
INIT_COMPLETE
ptp4l[1322.645]: port 1 (enp0s3): LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1322.645]: selected local clock 080027.fffe.14e74e as best master
ptp4l[1322.645]: port 1 (enp0s3): assuming the grand master role

*Slave clock Machine(THIS IS THE NEW OUTPUT)*
command 1: sudo ptp4l -i enp0s3 -s -S -m -2  //The -s indicates that it's
in Slave mode and -S indicates software stamping and -2 indicates that it's
an ethernet connection to the Master Cock and -m is just a flag to print to
the stdout.
o/p:
ptp4l[510.041]: port 1 (enp0s3): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[510.041]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on
INIT_COMPLETE
ptp4l[510.041]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on
INIT_COMPLETE
ptp4l[510.338]: port 1 (enp0s3): new foreign master 080027.fffe.16a902-1
ptp4l[514.339]: selected best master clock 080027.fffe.16a902
ptp4l[514.339]: foreign master not using PTP timescale
ptp4l[514.339]: port 1 (enp0s3): LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[515.340]: master offset  818267741 s0 freq      +0 path delay
 213342
ptp4l[516.340]: master offset  818259799 s0 freq      +0 path delay
 213342
ptp4l[517.341]: master offset  818296757 s0 freq      +0 path delay
 208455
ptp4l[518.341]: master offset  818236702 s0 freq      +0 path delay
 208455
ptp4l[519.342]: master offset  818213183 s0 freq      +0 path delay
 208089
ptp4l[520.342]: master offset  818273117 s0 freq      +0 path delay
 208089
ptp4l[521.343]: master offset  818296810 s0 freq      +0 path delay
 206482
ptp4l[522.343]: master offset  818252446 s0 freq      +0 path delay
 208089
ptp4l[523.344]: master offset  818277096 s0 freq      +0 path delay
 208455
ptp4l[524.344]: master offset  818273641 s0 freq      +0 path delay
 208455
ptp4l[525.345]: master offset  818254296 s0 freq      +0 path delay
 206848
ptp4l[526.345]: master offset  818304213 s0 freq      +0 path delay
 203334
ptp4l[527.346]: master offset  818321689 s0 freq      +0 path delay
 207354
ptp4l[528.346]: master offset  818140793 s0 freq      +0 path delay
 215306
ptp4l[529.346]: master offset  818254038 s0 freq      +0 path delay
 199070
ptp4l[530.346]: master offset  818234623 s0 freq      +0 path delay
 199070
ptp4l[531.347]: master offset  818314654 s1 freq   +2931 path delay
 196700
ptp4l[532.347]: master offset     -37772 s2 freq    -884 path delay
 196700
ptp4l[532.347]: port 1 (enp0s3): UNCALIBRATED to SLAVE on
MASTER_CLOCK_SELECTED
ptp4l[533.348]: master offset     -55051 s2 freq   -2667 path delay
 194795
ptp4l[534.349]: master offset      10365 s2 freq   +3885 path delay
 198547
ptp4l[535.349]: master offset    -136118 s2 freq  -10900 path delay
 198547
ptp4l[536.349]: master offset     -34907 s2 freq    -813 path delay
 198547
ptp4l[537.350]: master offset      10849 s2 freq   +3773 path delay
 198547
ptp4l[538.350]: master offset     -24837 s2 freq    +180 path delay
 198547
ptp4l[539.351]: master offset     -13187 s2 freq   +1331 path delay
 206847
ptp4l[540.351]: master offset    -130846 s2 freq  -10565 path delay
 215448
ptp4l[541.351]: master offset     -22999 s2 freq    +196 path delay
 215448
ptp4l[542.352]: master offset     -64400 s2 freq   -4008 path delay
 227289
ptp4l[543.352]: master offset     -16492 s2 freq    +766 path delay
 227289
ptp4l[544.353]: master offset     -41060 s2 freq   -1732 path delay
 221984
ptp4l[545.353]: master offset      -1444 s2 freq   +2229 path delay
 215448
ptp4l[546.354]: master offset     -31729 s2 freq    -832 path delay
 221984
ptp4l[547.354]: master offset      31516 s2 freq   +5524 path delay
 221244
ptp4l[548.354]: master offset     -41403 s2 freq   -1809 path delay
 225986
ptp4l[549.355]: master offset     -93473 s2 freq   -7109 path delay
 225986
ptp4l[550.356]: master offset     -15520 s2 freq    +670 path delay
 225986
ptp4l[551.356]: master offset     -58722 s2 freq   -3709 path delay
 218859
ptp4l[552.357]: master offset      -9513 s2 freq   +1203 path delay
 210622
ptp4l[553.357]: master offset    -125638 s2 freq  -10535 path delay
 218859
ptp4l[554.357]: master offset     -90944 s2 freq   -7157 path delay
 210622
ptp4l[555.358]: master offset        -59 s2 freq   +1932 path delay
 206239
ptp4l[556.359]: master offset      -2549 s2 freq   +1680 path delay
 206239
ptp4l[557.359]: master offset      17616 s2 freq   +3714 path delay
 206239
ptp4l[558.359]: master offset      -7706 s2 freq   +1174 path delay
 206468
ptp4l[559.360]: master offset      22034 s2 freq   +4170 path delay
 206468
ptp4l[560.360]: master offset     -13768 s2 freq    +576 path delay
 208807
ptp4l[561.360]: master offset     -46091 s2 freq   -2702 path delay
 208505
ptp4l[562.361]: master offset      -3289 s2 freq   +1575 path delay
 208505
ptp4l[563.361]: master offset     -33924 s2 freq   -1523 path delay
 208505
ptp4l[564.362]: master offset      -8924 s2 freq    +968 path delay
 208807
ptp4l[565.362]: master offset      18769 s2 freq   +3756 path delay
 208807
ptp4l[566.362]: master offset        849 s2 freq   +1965 path delay
 221132
ptp4l[567.363]: master offset      -9102 s2 freq    +961 path delay
 221132
ptp4l[568.363]: master offset     -41455 s2 freq   -2316 path delay
 233443
ptp4l[569.363]: master offset     -22946 s2 freq    -488 path delay
 233443
ptp4l[570.364]: master offset     -34039 s2 freq   -1631 path delay
 221132
ptp4l[571.364]: master offset    -112986 s2 freq   -9639 path delay
 214205
ptp4l[572.365]: master offset      15250 s2 freq   +3200 path delay
 208170
ptp4l[573.365]: master offset     -78993 s2 freq   -6303 path delay
 208170
ptp4l[574.365]: master offset     -30322 s2 freq   -1466 path delay
 214205
ptp4l[575.366]: master offset      19787 s2 freq   +3564 path delay
 214205
ptp4l[576.366]: master offset      37785 s2 freq   +5402 path delay
 214205
ptp4l[577.367]: master offset     -44422 s2 freq   -2863 path delay
 226516
ptp4l[578.367]: master offset      24438 s2 freq   +4047 path delay
 213817
ptp4l[579.367]: master offset     -17260 s2 freq    -140 path delay
 213817
ptp4l[580.368]: master offset     144709 s2 freq  +16202 path delay
 206874
ptp4l[581.368]: master offset    -130482 s2 freq  -11448 path delay
 206874
ptp4l[582.369]: master offset     -27075 s2 freq   -1134 path delay
 206874
ptp4l[583.369]: master offset      18380 s2 freq   +3430 path delay
 213817
ptp4l[584.369]: master offset     -21558 s2 freq    -586 path delay
 219323
ptp4l[585.370]: master offset      72428 s2 freq   +8885 path delay
 219323
ptp4l[586.370]: master offset     -94392 s2 freq   -7891 path delay
 219323
ptp4l[587.370]: master offset       1414 s2 freq   +1691 path delay
 219323
ptp4l[588.371]: master offset      -4486 s2 freq   +1097 path delay
 222641
ptp4l[589.371]: master offset       8537 s2 freq   +2407 path delay
 211807
ptp4l[590.372]: master offset     -27351 s2 freq   -1209 path delay
 214028
ptp4l[591.372]: master offset     -45545 s2 freq   -3074 path delay
 214028
ptp4l[592.372]: master offset      -7033 s2 freq    +770 path delay
 214028
ptp4l[593.373]: master offset     -29825 s2 freq   -1539 path delay
 217984
ptp4l[594.373]: master offset     -24963 s2 freq   -1077 path delay
 217984
ptp4l[595.373]: master offset     -10210 s2 freq    +388 path delay
 214028
ptp4l[596.374]: master offset     -22873 s2 freq    -901 path delay
 206371
ptp4l[597.374]: master offset      53411 s2 freq   +6780 path delay
 191157
ptp4l[598.375]: master offset      -2951 s2 freq   +1141 path delay
 191157
ptp4l[599.375]: master offset      10300 s2 freq   +2477 path delay
 191157
ptp4l[600.375]: master offset    -102576 s2 freq   -8914 path delay
 191157


Note:*I am getting very high offset ,and it's not geting synchronized,also
since its software timestamping,system clock should be updated,but it is
not getting update,please help,*

[Linuxptp-users] (no subject)

[Ray V. <ree...@gm...>]

Hi all,

I seem to run into increasing offsets constantly when running ptp4l or
phc2sys in various combinations and with various options.

New to PTP, I am trying to implement it on a Fedora Core 25 image (I know,
rather old...) on a I210 network chip which supports hardware time stamping.
Initially, I installed with dnf install linuxptp which was version 1.7.
Later I downloaded and installed latest version from sourceforge (3.1.1).

Since I have no grandmaster clock nor a PTP compliant switch, I connected 2
computers directly.
While no grandmaster clock, I thought to use the system clock as master and
slave the PHC to the system clock by using phc2sys on 1 computer
(experiment 1)
Next step would be to synchronize a second computer to the first computer
(experiment 2)

Experiment 1:
  phc2sys -s CLOCK_REALTIME -c eth0 -O 0 -m
gives the following output:
   phc2sys[1040.475]: sys offset -76090251872 s0 freq -23999998 delay    736
  phc2sys[1041.475]: sys offset -76834355556 s1 freq -23999999 delay    736
  phc2sys[1042.476]: sys offset -744083717 s2 freq -23999999 delay    736
  phc2sys[1043.476]: clockcheck: clock jumped backward or running slower
than expected!
  phc2sys[1043.476]: sys offset -1488162238 s0 freq -23999999 delay    736
  phc2sys[1044.476]: clockcheck: clock jumped backward or running slower
than expected!
  phc2sys[1044.476]: sys offset -2232260194 s0 freq -23999999 delay    736
  phc2sys[1045.476]: clockcheck: clock jumped backward or running slower
than expected!
  phc2sys[1045.476]: sys offset -2976349047 s0 freq -23999999 delay    736
  phc2sys[1046.476]: clockcheck: clock jumped backward or running slower
than expected!
  phc2sys[1046.476]: sys offset -3720439785 s0 freq -23999999 delay    736
  ...
  phc2sys[1059.478]: clockcheck: clock jumped backward or running slower
than expected!
  phc2sys[1059.478]: sys offset -13393624210 s0 freq -23999999 delay    704
  phc2sys[1060.478]: clockcheck: clock jumped backward or running slower
than expected!
  phc2sys[1060.478]: sys offset -14137705401 s0 freq -23999999 delay    736
  ...
  phc2sys[1075.480]: clockcheck: clock jumped backward or running slower
than expected!
  phc2sys[1075.480]: sys offset -25299057751 s0 freq -23999999 delay    736
  phc2sys[1076.480]: clockcheck: clock jumped backward or running slower
than expected!
  phc2sys[1076.480]: sys offset -26043146441 s0 freq -23999999 delay    736


Experiment 2:
  master: ptp4l -i eth0 -m
  slave:  ptp4l -i eth0 -m -s

Master gives output:
  ptp4l[1285.052]: selected /dev/ptp0 as PTP clock
  ptp4l[1285.052]: port 1: INITIALIZING to LISTENING on INITIALIZE
  ptp4l[1285.052]: port 0: INITIALIZING to LISTENING on INITIALIZE
  ptp4l[1291.462]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
  ptp4l[1291.462]: selected best master clock 001395.fffe.3329f2
  ptp4l[1291.462]: assuming the grand master role

Slave gives output:
  ptp4l[1307.595]: selected /dev/ptp0 as PTP clock
  ptp4l[1307.595]: port 1: INITIALIZING to LISTENING on INITIALIZE
  ptp4l[1307.596]: port 0: INITIALIZING to LISTENING on INITIALIZE
  ptp4l[1307.919]: port 1: new foreign master 001395.fffe.3329f2-1
  ptp4l[1311.919]: selected best master clock 001395.fffe.3329f2
  ptp4l[1311.919]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
  ptp4l[1312.918]: master offset 1895520235628 s0 freq -18003277 path delay
        0
  ptp4l[1313.918]: master offset 1895520228878 s1 freq -18030763 path delay
     5343
  ptp4l[1315.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1315.918]: master offset    9696846 s0 freq -18030763 path delay
-680343
  ptp4l[1316.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1316.918]: master offset   14682690 s0 freq -18030763 path delay
 -1159889
  ptp4l[1317.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1317.920]: master offset   19362056 s0 freq -18030763 path delay
 -1333023
  ptp4l[1318.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1318.918]: master offset   23868345 s0 freq -18030763 path delay
 -1333023
  ptp4l[1319.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1319.918]: master offset   28201513 s0 freq -18030763 path delay
 -1159889
  ptp4l[1320.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1320.918]: master offset   32534672 s0 freq -18030763 path delay
-986755
  ptp4l[1321.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1321.918]: master offset   37214040 s0 freq -18030763 path delay
 -1159889
  ...
  ptp4l[1330.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1330.918]: master offset   77796465 s0 freq -18030763 path delay
 -1185816
  ptp4l[1331.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1331.918]: master offset   82472537 s0 freq -18030763 path delay
 -1355555
  ...
  ptp4l[1341.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1341.918]: master offset  127082899 s0 freq -18030763 path delay
-903187
  ptp4l[1342.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1342.918]: master offset  131589224 s0 freq -18030763 path delay
-903187
  ptp4l[1343.918]: clockcheck: clock jumped backward or running slower than
expected!
  ptp4l[1343.918]: master offset  136095456 s0 freq -18030763 path delay
-903187

(The above outputs are from version 1.7. The 3.1.1 version gives similar
results)
Whatever I try , there is never a converging offset value. Also the freq
seems to be constant and the opposite direction of the offset. It seems to
me that the correction of the servo has no effect.

Any clue or hints are welcome. Thanks!

[Linuxptp-users] (no subject)

[Akash M. <aka...@s2...>]

Dear All,
My NIC is i350 which supports ptp. when i ran the command ethtool -T  
"my interface" it doesn't show any parameters. it's quite strange. i  
have attached an image for your reference. Do let me know if i am  
missing something and btw i even installed latest ethernet driver but  
in vain.

Re: [Linuxptp-users] (no subject)

[Miroslav L. <mli...@re...>]

On Mon, Sep 26, 2022 at 02:12:38PM +0200, Akash Munirathinam wrote:
> 
> Dear All,
> My NIC is i350 which supports ptp. when i ran the command ethtool -T "my
> interface" it doesn't show any parameters. it's quite strange. i have
> attached an image for your reference. Do let me know if i am missing
> something and btw i even installed latest ethernet driver but in vain.

Which parameters? The output seems ok to me, except it doesn't look
like an I350, which should be able to timestamp all received packets.
Here is the output I get:

Time stamping parameters for i350a:
Capabilities:
        hardware-transmit
        software-transmit
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        all

-- 
Miroslav Lichvar

[Linuxptp-users] (no subject)

[Gururaj B. <gur...@gm...>]

Hello,

We have a need for a PTP instance to only be a master but still respond
normally to the BMCA.

This is used when we have two or more dedicated masters which use the BMCA
to choose the GM. So the expected states once running are Master and
Passive. We can get this if we set the  *clockClass * at 58 or below. This
inhibits the slave states. However we need this to work with a
*clockClass * of 248.

Is there a way to inhibit the slave state? We cannot use masterOnly=1 as
that mode forces it to go to Leader and ignores the announce messages and
does not follow the BMCA. We have tried *asCapable*=true and
*inhibit_delay_req*=1 but in that mode, device states are Master or
Uncalibrated.

It appears the logic we want is possible since it works when the *clockClass
*is 58 or less. Is there an explicit configuration parameter to achieve
this directly?

Thank you.

Regards,

Guru

Re: [Linuxptp-users] (no subject)

[Gururaj B. <gur...@gm...>]

Hellow,

Trying to make this query a bit simple:

When *ClockClass* is set to 248, ptp4l, currently, goes into Ordinary
Clock(OC) mode. By that, it can switch to either Leader or Follower based
on availability of GM in the domain.
However, during some usecases, I would like to inhibit Slave state when
clockClass is set to 248.

To achieve this, I'm looking for a flag which can be set in the config file
to inhibit slave state. Does such a flag exist?

Thank you,
Regards,
Guru

On Wed, 12 Oct 2022 at 18:42, Gururaj Badiger <gur...@gm...>
wrote:

> Hello,
>
> We have a need for a PTP instance to only be a master but still respond
> normally to the BMCA.
>
> This is used when we have two or more dedicated masters which use the BMCA
> to choose the GM. So the expected states once running are Master and
> Passive. We can get this if we set the  *clockClass * at 58 or below.
> This inhibits the slave states. However we need this to work with a
> *clockClass * of 248.
>
> Is there a way to inhibit the slave state? We cannot use masterOnly=1 as
> that mode forces it to go to Leader and ignores the announce messages and
> does not follow the BMCA. We have tried *asCapable*=true and
> *inhibit_delay_req*=1 but in that mode, device states are Master or
> Uncalibrated.
>
> It appears the logic we want is possible since it works when the *clockClass
> *is 58 or less. Is there an explicit configuration parameter to achieve
> this directly?
>
> Thank you.
>
> Regards,
>
> Guru
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>

Re: [Linuxptp-users] (no subject)

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

On Fri, Oct 14, 2022 at 04:33:11PM +0530, Gururaj Badiger wrote:
> Hellow,
> 
> Trying to make this query a bit simple:
> 
> When *ClockClass* is set to 248, ptp4l, currently, goes into Ordinary
> Clock(OC) mode. By that, it can switch to either Leader or Follower based
> on availability of GM in the domain.
> However, during some usecases, I would like to inhibit Slave state when
> clockClass is set to 248.
> 
> To achieve this, I'm looking for a flag which can be set in the config file
> to inhibit slave state. Does such a flag exist?

Why not use this?

   --free_running=1

This prevents synchronization unconditionally, regardless of port state.

HTH,
Richard