[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aK8ZBWokfWSNBW70@localhost>
Date: Wed, 27 Aug 2025 16:41:09 +0200
From: Miroslav Lichvar <mlichvar@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Jacob Keller <jacob.e.keller@...el.com>,
Kurt Kanzenbach <kurt@...utronix.de>,
Tony Nguyen <anthony.l.nguyen@...el.com>,
Przemek Kitszel <przemyslaw.kitszel@...el.com>,
Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Richard Cochran <richardcochran@...il.com>,
Vinicius Costa Gomes <vinicius.gomes@...el.com>,
Paul Menzel <pmenzel@...gen.mpg.de>,
Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org
Subject: Re: [PATCH iwl-next v2] igb: Convert Tx timestamping to PTP aux
worker
On Wed, Aug 27, 2025 at 04:10:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2025-08-27 15:57:01 [+0200], Miroslav Lichvar wrote:
> > Anyway, if anyone is still interested in finding out the cause of
> > the regression, there is a thing I forgot to mention for the
> > reproducer using ntpperf. chronyd needs to be configured with a larger
> > clientloglimit (e.g. clientloglimit 100000000), otherwise it won't be
> > able to respond to the large number of clients in interleaved mode
> > with a HW TX timestamp. The chronyc serverstats report would show
> > that. It should look like the outputs I posted here before.
>
> How does this work with HW timestamps vs SW? I can't believe that 1k
> packets are sent and all of them receive a HW timestamp.
>From the results I posted before, the machine (CPU Intel E3-1220) with
the I350 NIC can provide about 59k HW TX timestamps per second without
any of the patches, about 41k with the original patch, and about 52k
with this patch and pinned aux worker.
The difference between ptp4l and chronyd is that chronyd is
asynchronous. It saves the timestamps as they come from the error
queue and provides the best timestamp to the clients later in their
subsequent response (NTP interleaved mode). At higher rates it's
random, only some of the packets get a HW timestamp. But the clients
can see less accurate (SW) timestamps as an increase in the measured
delay and they can filter them out if their clock is sufficiently
stable and the interval between HW timestamps is not too long.
--
Miroslav Lichvar
Powered by blists - more mailing lists