Hi Richard, On Tue, 1 Oct 2019 at 05:17, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Sat, Sep 28, 2019 at 03:34:14PM +0300, Vladimir Oltean wrote: > > > > From an application socket's perspective, it may happen from time to > > time that follow-up messages are delayed and received not 1 sync message > > too late, but 2 sync messages too late (or more). > > Then it is "game over". > > The delay between the Tx time stamp on the GM and the Rx time stamp > must not exceed a small fraction of the sync. period, otherwise the
You are only correct in the case of E2E delay measurement and dumb switches as being the cause of reordering. But even a PTP-aware (and P2P capable) system that is multi-queue, multi-core etc may suffer from reordering, and that doesn't mean anything w.r.t. to the timestamps, which are still taken by the MACs. So the path delay does not increase. > servo on the slave becomes unstable. See Eidson 5.2.2. > I have no idea what is "Eidson 5.2.2". Some psalm of sorts? If you're talking about IEEE 1588-2008, clause 5.2.2 does not exist (and 5.2 is "Primitive data type specifications") The only reference to ordering that I can see (but not understand) is in clause 9.5.1 "Messaging behavior of ordinary and boundary clocks", which says that requests to issue a PTP message shall be processed in FIFO order by message class. I guess that means "do not _send_ reordered sync frames" (which are event messages) and "do not _send_ reordered follow-up frames" (which are general messages), but it doesn't say to not buffer them until the ordering is re-established? I mean they can get reordered without having been sent that way. And more importantly, I don't see anything that says to send follow-up N immediately after sync N. After all, follow-up messages are not even timestamped. > There is no point in delivering the FollowUp one whole synch. period > too late! > As far as I understand, this just introduces "dead time" from a control theory point of view. Not sure that it is as fatal you are suggesting it is. > Thanks, > Richard > > Thanks, -Vladimir _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
