On Fri, Feb 13, 2015 at 01:56:12PM +0100, Miroslav Lichvar wrote: > These patches should improve the synchronization of the clock with > larger jitters, e.g. with software timestamping, wireless networks, > etc.
What kind of networks did you test this on? > What do you think? Does this make sense? This code pairs up the Sync measurement with the most recent Delay_Req measurement. The assumption here is that a randomly larger Sync delay will be paired with a larger Delay_Req delay (if I understood). But that is not a valid assumption in general, is it? I think the best way is to simply leave out (ignore) bad measurements altogether. This is what the mean filter does, and the servos are supposed to mitigate the effects of outliers. Overall, I wouldn't mind having extra filter options for noisy networks. Ideally this would be modular, just like the servos and filters are now. People have asked about discarding software timestamping measurements that are too far out. Come to think of it, can't your algorithm be implemented within the current servo/filter modular architecture? We can change the API to provide t1, t2, t3, and t4. Thanks Richard ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
