On Tue, 1 Oct 2019 at 14:11, Miroslav Lichvar <mlich...@redhat.com> wrote: > > On Tue, Oct 01, 2019 at 01:57:21PM +0300, Vladimir Oltean wrote: > > On Tue, 1 Oct 2019 at 13:50, Miroslav Lichvar <mlich...@redhat.com> wrote: > > > No, I'd not expect to receive a follow-up message 30 milliseconds > > > after the corresponding sync message. If the difference was getting to > > > the millisecond range, I'd be worried that the network is so > > > overloaded or misconfigured that it might drop some PTP messages. > > > > > > > What about a sync interval of 2^-4, which is what is specified by the > > G.8275.1 telecom profile (supported by linuxptp as there is a config > > file for it)? > > What about the automotive profile which uses a sync interval of 2^-3 > > before arriving at the stable state? > > Both 2^-3 and 2^-4 are longer than 2^-5, so I'd not expect it to > happen either. If it was, I'd try to figure out why it's happening and > fix it. >
We might have a misunderstanding. When you said "I'd not expect to receive a follow-up message 30 milliseconds after the corresponding sync message", I thought you meant it's too early, but what you really meant is that it's too late.... Care to explain why? I know of no timing requirement for the follow-up frames. And well, there are hardware and architectural (DSA => stacked net devices) reasons why it takes so long to transmit these frames. I do need to bump up tx_timestamp_timeout to 30 for the same reasons. So although we do agree on a basic level (that I need to understand where the limit is and why it can't be pushed further), I think this patch gets misinterpreted. When your testing tool gives up and doesn't tell you what's wrong or let you debug further, then you fix it and you go on with the debugging. I'm not even changing the default ptp4l behavior. Sure, I'm not going to let anyone rely on this setting and put it in a production environment that requires a fast sync interval, but that's completely besides the point. > Do you see it happening in a real network? With what switches? > Yes, this is occasionally happening even with 2^-3. The network is a simple 3-board (master, P2P_TC, slave) topology, and the switch is a prototyping board using the sja1105 DSA driver. The reordering is seen on the switch. > -- > Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
