On Sun, Sep 19, 2021 at 04:15:15PM +0300, Joseph Matan wrote: > > > > > > > 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. > > > > I think there is no point in using this filter if you don't use weights > either.
Enabling the weighted filtered mode can help, but not as much as disabling the filter completely, at least from what I have seen in my tests. > But isn't that the same with the median filter ? The median filter expects the network delay to have a symmetric distribution. That should work well with full hardware support on the NIC and network. With the percentile filter you expect an asymmetric distribution. The reported delay is more stable, but the clock is less accurate. What is the use case here? Why not just disable the filter? > I did it for optimization. > After m->cnt reaches the value of m->len, there is no need to re-calculate > m->percentile_index anymore (so the function needs to "remember" the value > of m->percentile_index). Saving a single multiplication? I don't think it's worth it. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
