Re: [Linuxptp-devel] [PATCH RFC] Replace moving average with moving median for delay filtering.
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
From: Miroslav L. <mli...@re...> - 2013-10-10 12:38:21
|
On Wed, Oct 09, 2013 at 09:48:07PM +0200, Richard Cochran wrote: > On Wed, Oct 09, 2013 at 12:19:06PM +0200, Miroslav Lichvar wrote: > > This, for instance, allows much faster recovery from an external clock > > time step which happened between receiving sync message and sending > > delay_req message. The measured delay includes a large error, but the > > median is still a good estimate of the delay and the first step > > correction applied by the servo is right. > > I wonder what the effect might be in the case running PTP over normal > (non-transparent) networks. These introduce a variable path delay, > with outliers that keep repeating at some rate. In the simulations with exponentially distributed delays the RMS time and frequency error seem to be the same as with the moving average. If there is a difference, it will be smaller than few percent. The servo performance tests from the test suite pass without any changes to the limits. > Letting the longer paths into the estimate (in proportion to their > occurrence, ie in the average) might perform better in this case than > possibly filtering them out. Just thinking out loud... If you have a specific distribution in mind, we can try it in the simulator. I guess it would have to be extremely asymmetric to see a difference in the offsets passed to the servo when median or average is used. > > -tmv_t mave_accumulate(struct mave *m, tmv_t val); > > +tmv_t mmedian_accumulate(struct mmedian *m, tmv_t val); > > "Accumulate" seems like the wrong word for this, but other than that, > the patch looks okay to me. Ok, I can change it to mmedian_update. > > Maybe we should offer both options in the manner of the servo > interface? >From the results I've seen so far it doesn't seem to be necessary. -- Miroslav Lichvar |