On Fri, Sep 20, 2019 at 04:39:06PM +0000, Stuart Venters wrote: > To support separate filtering and give the filter access to everything it > needs, I think what I would like to see is the following refactoring and see > how it works out: > > Change the argument list for filter_create to add an indication of which > filter is being created, and pointers to the clock_type and config. > > Change the argument list for filter_sample to be local time of the experiment > and observed delay. Return value would be filtered delay. Where delay is > rxtimestamp - txtimestamp with corrections. > > Change port.c to create two filters and use them on the one-way measurements > before calling clock_synchronize and clock_path_delay.
Why port.c? As Richard suggested, tsproc might be a better place. It would help if you could describe your approach in a bit more detail. Is the minimum delay configurable or estimated? How do you prevent it from getting stuck on rapid frequency changes? To me it sounds like you want to drop the measurements as if the packets were lost, i.e. something different than what the filter.h API is intended for. That wouldn't work well with the current servo architecture. Reusing old measurements might be easier, but I suspect it could be tricky. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
