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 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.
> Thanks,
> Jake
>
Thanks,
-Vladimir
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
