On Sat, Sep 11, 2021 at 12:33:43PM +0300, joseph.matan...@gmail.com wrote:
> From: Joseph Matan <joseph.matan...@gmail.com>
>
> The percentile filter can be very useful when running in a non-ptp-aware
> environment.
> For example, if we set a low percentile value (and the filter length is large
> enough), we can still get a good estimation of the real delay, even if our
> setup is running under heavy network traffic.
With that better estimate of delay, what do you do with the sync
messages? There is no filter for them that would compensate this
asymmetry, so I think this will make a negative impact on accuracy of
the clock.
If you insist on using PTP in a non-PTP network, it is better to
disable the delay filter, i.e. set tsproc to a raw mode.
Few comments about the patch below, if there is a use case for it.
> @@ -238,6 +239,7 @@ struct config_item config_tab[] = {
> PORT_ITEM_INT("delayAsymmetry", 0, INT_MIN, INT_MAX),
> PORT_ITEM_ENU("delay_filter", FILTER_MOVING_MEDIAN, delay_filter_enu),
> PORT_ITEM_INT("delay_filter_length", 10, 1, INT_MAX),
> + PORT_ITEM_DBL("delay_filter_percentile", 0.5, 0.0, 1.0),
I'd expect the default percentile to be different from 0.5 (which is
already the default with the default median filter).
> +struct mpercentile {
> struct filter filter;
> int cnt;
> int len;
> int index;
> + double percentile;
> + int percentile_index;
Why is percentile_index here? It seems it's needed only in one
function.
> - if (m->cnt % 2)
> - return m->samples[m->order[m->cnt / 2]];
> - else
> - return tmv_div(tmv_add(m->samples[m->order[m->cnt / 2 - 1]],
> - m->samples[m->order[m->cnt / 2]]), 2);
> + return m->samples[m->order[m->percentile_index]];
I'd prefer if the median filter was a special case here to not change
the behavior for even lengths (the default is 10).
--
Miroslav Lichvar
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
