On Wed, Feb 12, 2014 at 09:58:07PM +0100, dbrign...@audioscience.com wrote: > From: Delio Brignoli <dbrign...@audioscience.com> > > Peer delay should never be negative, when it occurs > warn the user and drop it.
I don't think it is right to drop such measurements. If the clocks are far enough apart in frequency and the response turn around time long enough, then the value can be negative. Although a negative delay is intuitively wrong, still the value reflects the true frequency offset between the peers, and using the value will help to syntonize the slave to the master. Even in the gPTP case where you do not tune the clock, still I would expect that you need the actual peer delay measurement (even when negative) in order to calculate the true offset from master. [ Originally I had the same check on the path delay, but I later decided that not including the negative measurements can hurt the servo or even prevent its operation altogether. I did leave a warning message, but since this occurs so often in practice, the messages became annoying and were downgraded in debug messages. See clock_path_delay() in clock.c. ] Thanks, Richard ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
