On Mon, Apr 03, 2017 at 03:52:13PM +0200, Burkhard Ilsen wrote: > 1. > For the first measurement the nrate ratio cannot be calculated. > To avoid an erroneous measurement the calculation could be aborted if the > nrate is not valid, > e.g. by placing a "if(!p->nrate.ratio_valid) return;" between > port_nrate_calculate() and tsproc_update_delay(). > The drawback is that peer_delay is not available after the first > delay_response.
Yes, and it doesn't make sense to penalize users with reasonable local clocks by removing the default 1.0 NRR. > I prefer a later but correct measurement instead of an incorrect value > affecting the following filtered values as well. The 802.1-AS standard requires that local clocks be within 100 ppm and that Pdelay turnaround time stays under 10 ms. That makes the worst case error 1 usec. Ten milliseconds is already far out, and most Linux embedded systems are surely under 1 ms. So we talking about an error of 100 ns or less. So IMHO we should let systems that have really bad local clocks take the initial error, rather than allowing them to spoil normal systems. After all, bad clocks are bad clocks. > 2. > For the second measurement the nrate ratio is calculated, after the delay > was calculated based on the old (invalid) nrate ratio. > The nrate ratio should be calculated before the delay, > e.g. by moving port_nrate_calculate() in front > of tsproc_set_clock_rate_ratio(). > Please tell me if there is a reason for the current sequence of > calculations. I can't see any reason not to put port_nrate_calculate() first. Thanks, Richard ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
