On 7/10/2023 12:33 PM, Maciek Machnikowski wrote: > > > On 7/10/2023 12:03 PM, Miroslav Lichvar wrote: >> On Mon, Jul 10, 2023 at 11:18:36AM +0200, Maciek Machnikowski wrote: >>> Do you mean the one in clock.c? If so, the clock_stats_display resets >>> them, so there's no way of printing the stats from a whole run - >>> especially if we want to add some periodic read of these stats. >> >> The logged stats can be combined over any number of intervals as you >> like. >> >> If that is not acceptable for some reason, I'd prefer to add a new >> option to not reset the stats after printing instead of duplicating >> the functionality in a different place and printing the data in a >> different format. >> > > I don't think such option would be good. It would break current > implementation for printing stats with telco profiles. If expanding the > clock stats is a preferred way I'd rather add new stats structure into > the clock file (let's name them global_stats) and use those for the full > run (or full S2/S3 state). > > To give more background - some specs require gathering statistical data > along with max/min values over extended periods of time. Having such > statistics built in would make assessing compliance much easier. It can > also replace the need to calculate this stats in the automated tests. > > WDYT?
After looking deeper in code this approach will not work. The clock.c, summary_interval and statistics are used only in ptp4l, so any implementation enhancing existing statistics would only work there. Moving all tools to use clock.c does not make too much sense, as it is too 1588-specific. The best way to make a universal implementation is to implement it in servo.c as proposed in this patch. Thanks, Maciek _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
