Richard, I'm doing some experiments with linuxptp. It's kind of a neat gadget to have abound, thanks.
I'd like to try adding lucky packet filters. I think these might be useful to get to improved accuracy given residual delay variations in the on-path support's timestamping. The experiments also include timestamping and timekeeping mechanisms, but for now I wanted to talk about how to integrate the filters. I'm having a problem fitting suitable filters into the current architecture. There is a disconnect between my understanding of the problem and how the filter class fits into the overall structure. The details of the disconnect are as follows: In Ptp, the upstream and downstream flows provide delay measurements. If PDV makes only 10% of the measurements useful, it is the filter's job to find these few to use for updating the offset estimate. The two flows are statistically independent. This says that although the individual odds of finding a useful measurement is 10%, the joint odds of finding a pair of good measurements is 10% squared or 1%. This says that you get to keep many more useful measurements if the upstream and downstream experiment streams are filtered separately. 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. The goal is to support improved filtering without breaking all that is currently supported. I think it wise to leave in the current single filter for the combined RTT with a config flag to switch the new calling locations. Any interest in such a path? If so, not sure what the mechanics you prefer. -Stuart
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
