Hi Miroslav, On Tue, 1 Oct 2019 at 11:56, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Tue, Oct 01, 2019 at 11:04:21AM +0300, Vladimir Oltean wrote: > > 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. > > Hm, I thought the issue was a HW/driver bug that caused some messages > to get stuck in a queue and the patch was proposed as a workaround. > > Are you saying in a local network it's expected that a PTP slave > receives the follow-up message one or more sync intervals after the > corresponding sync message, e.g. a delay of 1 second with the default > sync interval? > > I'd not consider such network to be suitable for PTP. >
No, you read that the other way around. I basically said that there are multiple types of reordering from ptp4l's perspective, which can't distinguish between the local system reordering frames in its network stack vs an external switch doing it. My patch would help somewhat in the case of the 1st issue but probably not in the 2nd. This was in response to Richard who said the synchronization is already 'toast' due to timestamps. But otherwise, why does current linuxptp even attempt to receive a follow-up frame before the sync has arrived, if reordering is somebody else's problem? > -- > Miroslav Lichvar Thanks, -Vladimir _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
