linuxptp-devel

Re: [Linuxptp-devel] [PATCH RFC v3 00/10] Profile support for IEEE C37.238-2011 and IEEE C37.238-2017

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

On Wed, Nov 10, 2021 at 12:11:19PM +0000, v.n...@pr... wrote:
> IEEE C37.238-2017 says that domainNumber value can be 254. Is it possible to expand the maximum value of this parameter or somehow allow to use of this single value?

Yes.  This detail from the profile is silly, IMO, but I don't see much
harm in allowing the full range of domainNumbers.

Thanks,
Richard

Re: [Linuxptp-devel] [PATCH RFC v3 02/10] Introduce the power profile.

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

On Wed, Nov 10, 2021 at 12:59:33PM +0100, Olivier Dautricourt wrote:

> I had the feeling that power profiles attributes such as
> totalTimeInaccuracy should be properties of the clock.
> In case of a simple BC or jbod, all the ports need to share the
> same inaccuracy.

If two ports have different HW, like one MAC and one PHY with
differing time stamping inaccuracy, then the values will be
different.

In addition, using a port attribute allows having the 2011/2017
flavors running on different ports.

> This way, we don't rely on users to forward the inaccuracy between ports
> with management tlvs.

This series treats the values as static.  There is no automatic
update.  The profile does not specify how to automatically calculate
the values.  On the contrary, it recommends a one time calibration
"during network engineering stage":

    Overall time inaccuracy should be calculated during network
    engineering stage based on device specifications and network
    design. All time inaccuracy values used in this calculation should
    be based on the manufacturer's specified device time inaccuracy
    values, along with the source time inaccuracy of the recognized
    standard time source.

> We also know that the totalTimeInaccuracy will
> always be the sum of other fields.

No, it is one or the other.  Either you have:

reserved1 = grandmasterTimeInaccuracy = 0, totalTimeInaccuracy != 0   2017 flavor

or

grandmasterTimeInaccuracy != 0, networkTimeInaccuracy != 0            2011 flavor

> So i don't think we should allow
> setting it through mgt.

ptpl4 makes consistent use of the management interface for values that
cannot be determined automatically.

Thanks,
Richard

Re: [Linuxptp-devel] [PATCH RFC v3 06/10] Add the ALTERNATE_TIME_OFFSET_PROPERTIES management message.

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

On Wed, Nov 10, 2021 at 08:57:35AM +0000, Geva, Erez wrote:
> Hi,
> 
> According to IEEE 1588 timeOfNextJump is 48 bits.
> The alternate_time_offset_properties structure reserve the full 48 bits.
> The pre and the post function do full handle.
> But the rest handle only the low 32 bits.
> 
> I can understand the PMC set use 32 bits only, but the rest?

The resolution of timeOfNextJump is one second.  Twenty five bits of
seconds is more then enough for a time zone change one year out.

32 bits allows time zone change 136 years in the future.

Do we really need the high order bytes of the 48 bit field?

Thanks,
Richard

Re: [Linuxptp-devel] [PATCH RFC v3 06/10] Add the ALTERNATE_TIME_OFFSET_PROPERTIES management message.

[Geva, E. <ere...@si...>]

I notice that 32 bits are 136 years.

But as IEEE defined it as 48 bits. 
And we try to make the ptp4l compliance with IEEE.

In the same manner that we add zero pad to management GET message, since IEEE recommends.

I think, we need to support 48 bits in ptp4l and display the proper value in PMC.

I do agree that setting the value by PMC is not necessary.
And I doubt if any one really need these extra 16 bits.

As I am sure no one really needs the GET message data filled with zeros.

Erez

-----Original Message-----
From: Richard Cochran <ric...@gm...> 
Sent: Wednesday, 10 November 2021 15:52
To: Geva, Erez (ext) (DI PA DCP R&D 3) <ere...@si...>
Cc: lin...@li...
Subject: Re: [Linuxptp-devel] [PATCH RFC v3 06/10] Add the ALTERNATE_TIME_OFFSET_PROPERTIES management message.

On Wed, Nov 10, 2021 at 08:57:35AM +0000, Geva, Erez wrote:
> Hi,
> 
> According to IEEE 1588 timeOfNextJump is 48 bits.
> The alternate_time_offset_properties structure reserve the full 48 bits.
> The pre and the post function do full handle.
> But the rest handle only the low 32 bits.
> 
> I can understand the PMC set use 32 bits only, but the rest?

The resolution of timeOfNextJump is one second.  Twenty five bits of seconds is more then enough for a time zone change one year out.

32 bits allows time zone change 136 years in the future.

Do we really need the high order bytes of the 48 bit field?

Thanks,
Richard

Re: [Linuxptp-devel] [PATCH RFC v3 06/10] Add the ALTERNATE_TIME_OFFSET_PROPERTIES management message.

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

On Wed, Nov 10, 2021 at 04:49:54PM +0000, Geva, Erez wrote:
> I notice that 32 bits are 136 years.
> 
> But as IEEE defined it as 48 bits. 
> And we try to make the ptp4l compliance with IEEE.

How is this patch non-compliant?

> I think, we need to support 48 bits in ptp4l and display the proper value in PMC.

Can you please comment on the diff inline and point out which parts
are incorrect?  Bonus points for stating the correction.

Thanks,
Richard

Re: [Linuxptp-devel] [PATCH RFC v3 02/10] Introduce the power profile.

[Olivier D. <oli...@or...>]

Hi,

The 11/10/2021 06:42, Richard Cochran wrote:
> 
> On Wed, Nov 10, 2021 at 12:59:33PM +0100, Olivier Dautricourt wrote:
> 
> > I had the feeling that power profiles attributes such as
> > totalTimeInaccuracy should be properties of the clock.
> > In case of a simple BC or jbod, all the ports need to share the
> > same inaccuracy.
> 
> If two ports have different HW, like one MAC and one PHY with
> differing time stamping inaccuracy, then the values will be
> different.
> 
> In addition, using a port attribute allows having the 2011/2017
> flavors running on different ports.
> 
> > This way, we don't rely on users to forward the inaccuracy between ports
> > with management tlvs.
> 
> This series treats the values as static.  There is no automatic
> update.  The profile does not specify how to automatically calculate
> the values.  On the contrary, it recommends a one time calibration
> "during network engineering stage":
> 
>     Overall time inaccuracy should be calculated during network
>     engineering stage based on device specifications and network
>     design. All time inaccuracy values used in this calculation should
>     be based on the manufacturer's specified device time inaccuracy
>     values, along with the source time inaccuracy of the recognized
>     standard time source.
> 
Ok, this part is confusing as the standard says above:

On grandmasterTimeInaccuracy:
	"This value should be updated in real time, as conditions
	change"
and:
	"TotalTimeInaccuracy shall be automatically incremented by TCs
	and BCs"

Suggesting that BC/TC inaccuracy should be taken into account
automaticaly.
> > We also know that the totalTimeInaccuracy will
> > always be the sum of other fields.
> 
> No, it is one or the other.  Either you have:
> 
> reserved1 = grandmasterTimeInaccuracy = 0, totalTimeInaccuracy != 0   2017 flavor
> 
> or
> 
> grandmasterTimeInaccuracy != 0, networkTimeInaccuracy != 0            2011 flavor
> 
My understanding of the 2011/2017 compat is that you can sum
reserved1 and totalTimeInaccuracy to compute an equivalent
totalTimeInaccuracy coming from a 2011-compatible end device. (C37-238 Annex B)
But i have not read the 2011 standard thoroughly as we were focused on
61850-9-3 (utility).


Thanks,

-- 
Olivier

Re: [Linuxptp-devel] [PATCH RFC v3 02/10] Introduce the power profile.

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

On Mon, Nov 15, 2021 at 10:38:53AM +0100, Olivier Dautricourt wrote:

> > This series treats the values as static.  There is no automatic
> > update.  The profile does not specify how to automatically calculate
> > the values.  On the contrary, it recommends a one time calibration
> > "during network engineering stage":
> > 
> >     Overall time inaccuracy should be calculated during network
> >     engineering stage based on device specifications and network
> >     design. All time inaccuracy values used in this calculation should
> >     be based on the manufacturer's specified device time inaccuracy
> >     values, along with the source time inaccuracy of the recognized
> >     standard time source.
> > 
> Ok, this part is confusing as the standard says above:
> 
> On grandmasterTimeInaccuracy:
> 	"This value should be updated in real time, as conditions
> 	change"
> and:
> 	"TotalTimeInaccuracy shall be automatically incremented by TCs
> 	and BCs"
> 
> Suggesting that BC/TC inaccuracy should be taken into account
> automaticaly.

Yes, but how?  Magic ball?  Wishful thinking?

I say again:

There is no automatic update.  The profile does not specify how to
automatically calculate the values.

Because the profile provides only hand waving fluff, it is up to the
end user to decide when and how to update the values.  The present
patch series allows this via management, just like for GM settings.


Thanks,
Richard