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. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
