> -----Original Message-----
> From: Vladimir Oltean [mailto:olte...@gmail.com]
> Sent: Monday, September 30, 2019 3:07 PM
> To: Keller, Jacob E <jacob.e.kel...@intel.com>
> Cc: richardcoch...@gmail.com; linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH] port: Deal with higher-order
> sync/follow-up
> reordering
>
> On Tue, 1 Oct 2019 at 00:34, Keller, Jacob E <jacob.e.kel...@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: Vladimir Oltean [mailto:olte...@gmail.com]
> > > Sent: Monday, September 30, 2019 2:30 PM
> > > To: Keller, Jacob E <jacob.e.kel...@intel.com>
> > > Cc: richardcoch...@gmail.com; linuxptp-devel@lists.sourceforge.net
> > > Subject: Re: [Linuxptp-devel] [PATCH] port: Deal with higher-order
> > > sync/follow-up
> > > reordering
> > >
> > > Hi Jake,
> > >
> > > > Could we add a section to the man page describing this option and when
> > > > it might
> > > make sense? The tail dropping due to re-ordering is clear but may not
> > > immediately
> be
> > > obvious to users which knobs to use to help resolve the problem.
> > > >
> > >
> > > The patch does indeed touch ptp4l.8. Did you notice that and think it
> > > could use some improvement?
> > >
> > > > Thanks,
> > > > Jake
> > > >
> >
> > It would be nice if the manual page indicated the specific error message
> > that occurs
> (tail-dropped due to reordering).
> >
>
> So I posted this just to get some initial feedback for the general
> approach (removing some config options, adding others, etc) and its
> general sanity (how deep a queue is enough? how can you even know? do
> we even want to go down the rabbit hole? should we print anything in
> the benign case that out-of-order frames are received and still
> properly processed, just to make sure people are not blindly relying
> on this fail safe that could disappear any moment with bad enough
> reordering?). So if the feedback I get is only related to the printf
> strings, then I should already send out a new version?
>
I would wait on that, for at least some feedback.
I generally think the approach is good, and the configurable variable makes
sense.
Leaving the default the same as the old behavior is definitely the most
conservative approach.
> > I also am wondering if we can print a message that indicates the history
> > depth
> option might be useful, similar to how we print something about
> "tx_timestamp_timeout" when we fail to receive a Tx timestamp in time.
> >
>
> Which by the way has a completely inadequate default value, at 1 ms.
> There are even some regular Ethernet drivers for which it's too
> little. And then there are DSA drivers on top of those for which it's
> already too little. The tx_timestamp_timeout should catch all 'real'
> timestamp losses and not just badmouth the driver ("it is likely
> caused by a driver bug").
> But my point is that although I need to change tx_timestamp_timeout
> for every single installation of linuxptp, I'm not sending out a patch
> to change the default because I have no clue what a universally better
> default would be.
>
Yea, picking a good default is problematic.
> > Thanks,
> > Jake
> >
>
> Thanks,
> -Vladimir
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
