On 1/13/2021 6:54 AM, Richard Cochran wrote:
> On Wed, Jan 13, 2021 at 12:42:36PM +0200, Vladimir Oltean wrote:
>> So I might expect that what you mean by "different requirements" is
>> simply that some might be ok with simply a one-time measurement of
>> offsetFromMaster that falls below (in absolute value) than the
>> user-provided threshold, while others might want to compare a time
>> average of the offsetFromMaster with the threshold. Maybe we can do
>> both?
>
> There are many more than two variants. For example you could want a
> moving window of mean or median below X, or standard deviation below
> Y, or frequency offset not exceeding Z. The list goes on and on...
>
Right. Precisely how you calculate the offset from master over time
might differ, and in addition your threshold requirements might be lower
or higher depending on your goals.
However, even just being able to report offset from master would allow
other software to implement specifics of measuring how synchronized the
clocks are.
>> So this is where I was trying to get at. What should this management
>> interface look like? Should it be compliant to IEEE 1588 clause 15
>> Management, or should it be a custom implementation?
>
> If we use the standard TLVs, then we can re-use code.
I would prefer using standard TLVs for any messages that match, and
using the same method of custom non-portable TLVs for any special new
messages we need.
>
>> If the former, I guess we would have to fake a portIdentity for
>> CLOCK_REALTIME, and we should make it answer the managementIDs that make
>> sense (CLOCK_ACCURACY, CLOCK_DESCRIPTION, TIMESCALE_PROPERTIES,
>> TIME_STATUS_NP, TRACEABILITY_PROPERTIES). Or we could treat it like a
>> full-blown ordinary clock and register all the clock data sets for one:
>> defaultDS, currentDS, parentDS, timePropertiesDS, portDS.
>>
>> If the latter, any ideas?
>
> IIRC, not all management IDs need be implemented. So we could let
> ptp4l receive requests for portIdentity.portNumber = 0xffff and
> forward them to phc2sys over UDS.
>
Right. This seems reasonable to me!
> Thanks,
> Richard
>
>
>
> _______________________________________________
> Linuxptp-users mailing list
> Linuxptp-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
