> > > > 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. But isn't that the same with the median filter ? > 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. Sometimes we don't have a choice. > > I'd expect the default percentile to be different from 0.5 (which is > > already the default with the default median filter). > I agree. I will change it. > > Why is percentile_index here? It seems it's needed only in one > > function. > 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). > > I'd prefer if the median filter was a special case here to not change > > the behavior for even lengths (the default is 10). > I assume that for larger lengths this is negligible, but for lower lengths (such as 10) I can understand what you are saying. I'll add a special case here. Thanks for the review, I will update the patch and resend it. Joseph
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
