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