On Mon, Nov 09, 2015 at 01:16:19PM +0100, Richard Cochran wrote: > On Mon, Nov 09, 2015 at 12:24:11PM +0100, Miroslav Lichvar wrote: > > > > Hm, I'm not sure I follow. Which of the four timestamps are allowed to > > be zero and how it's related to the one-step mode? If some timestamps > > are zero I'd expect the problem to rather be a missing or extra > > tsproc_down_ts/tsproc_up_ts call. > > For P2P one step, you get t1 from PDelay_Req and t4 from PDelay_Resp. > The value (t3-t2) is provided in the correction field of the > PDelay_Resp.
Ok, I think I see now. With a one-step clock there is no way to transfer t3 in the pdelay response, only the t3-t2 difference, so t2 is set to zero and t3 is assumed to be equal to that. With a two-step clock t2 and t3 can be transferred, but it's not a requirement and they can actually be zero too. So I guess the fix could be one of the following: - modify tsproc_update_delay() to not require that t1 and t4 are non-zero - set t2 and t3 in port_peer_delay() to any non-zero value to indicate to tsproc they are valid - if the correction can be assumed to be always non-zero, in port_peer_delay() apply half of it to t2 and half to t3 -- Miroslav Lichvar ------------------------------------------------------------------------------ Presto, an open source distributed SQL query engine for big data, initially developed by Facebook, enables you to easily query your data on Hadoop in a more interactive manner. Teradata is also now providing full enterprise support for Presto. Download a free open source copy now. http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140 _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
