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... > 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. > 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. Thanks, Richard _______________________________________________ Linuxptp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-users
