> -----Original Message-----
> From: Miroslav Lichvar <mlich...@redhat.com>
> Sent: Monday, July 12, 2021 12:35 AM
> To: Keller, Jacob E <jacob.e.kel...@intel.com>
> Cc: Eric Decker <edec...@oldi.com>; linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH] Increase the default
> tx_timestamp_timeout
> to 5
>
> On Thu, Jul 08, 2021 at 07:35:25PM +0000, Keller, Jacob E wrote:
> > > As a future improvement, maybe it could be adaptive, e.g. once in a
> > > while try waiting much longer and if that doesn't give a timestamp
> > > stick to a shorter interval. That is, try to detect when the hardware
> > > is not able to timestamp all packets.
> > >
> >
> > Not sure I follow here. I guess we'd default to a long timeout and
> > periodically
> try shorter ones? I'm not sure this would be effective. I think the
> complexity isn't
> really worth it.
>
> That's another way to look at it. The idea is to estimate something
> like the 99th percentile of the delay to maximize the performance
> instead of wasting time waiting for a timestamp that is unlikely to
> come. The main use case where it could help is multiple applications
> doing TX timestamping on the same interface, e.g. a PTP server and
> client running in different domains.
>
> Just an idea for future improvement.
>
> --
> Miroslav Lichvar
Right. Though.. running something like ptp4l on the same connection could be
problematic if the applications aren't working together because most hardware
supports a single request at once, so if both applications send a request at
the same time one of them will fail. They would need to either ensure they're
off-sync or be communicating to each other about when its ok to timestamp
request somehow.
I do like the idea of estimating the 99% percentile over time and adjusting
delay
Thanks,
Jake
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
