On Wed, Mar 11, 2015 at 03:32:16PM +0100, Richard Cochran wrote: > https://mlichvar.fedorapeople.org/tmp/ptp/ptp4l_error2.png > > I would think simply comparing the sampled offset with the average > offset and scaling (or pruning) it would be at least as effective as > looking at the delay. Plus it would not depend on "balanced" rates.
I think that would be a filter working with already calculated offset/delay samples, not time stamps directly. Spike filters work well if the packets are delayed occasionally, but without looking at delay it wouldn't be able to tell if the network is still congested or the clock is really off that much. > > - port.c can use this too, deduplicating the delay calculation and > > delay filtering > > (The delay must be per port, for P2P mode.) Each port would have its own time stamp processor. > > Does it make sense? > > Yes, that is the right direction. Ok, I'll see if I can update the patches for this. Thanks, -- Miroslav Lichvar ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
