Hi Richard, Jake, many thanks for your replies.
>> 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 agree for AS compliant neighbors, still I want to throw in some points into the discussion: > 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. - The maximum peak-to-peak rate offset of two neighbors is 200 ppm, which doubles the worst case error to 2 us. - The neighborPropDelayThresh for gPTP is 800 ns, which leaves an error margin of about 200 ns (for 100 m cables). - As stated by Richard in another thread, there might be 1588 TC peers (or not fully AS compliant TAB) using a controlled clock instead of local clock for timestamping, which rockets the maximum rate offset to max_frequency of the peer. This is what I observed during my tests. But I guess at least after some pdelay_req this tweak is pointless anyhow. I am fine with using default NRR of 1.0 although in opinion it is not optimal. Regards, Burkhard ------------------------------------------------------------------------------ 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
