From: Kurt Kanzenbach <kurt@linutronix.de>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Richard Cochran <richardcochran@gmail.com>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] igb: Retrieve Tx timestamp directly from interrupt
Date: Tue, 19 Aug 2025 16:50:23 +0200 [thread overview]
Message-ID: <87ms7vs6vk.fsf@jax.kurt.home> (raw)
In-Reply-To: <aKMbekefL4mJ23kW@localhost>
[-- Attachment #1: Type: text/plain, Size: 5186 bytes --]
On Mon Aug 18 2025, Miroslav Lichvar wrote:
> On Fri, Aug 15, 2025 at 08:50:23AM +0200, Kurt Kanzenbach wrote:
>> Retrieve Tx timestamp directly from interrupt handler.
>>
>> The current implementation uses schedule_work() which is executed by the
>> system work queue to retrieve Tx timestamps. This increases latency and can
>> lead to timeouts in case of heavy system load.
>>
>> Therefore, fetch the timestamp directly from the interrupt handler.
>>
>> The work queue code stays for the Intel 82576. Tested on Intel i210.
>
> I tested this patch on 6.17-rc1 with an Intel I350 card on a NTP
> server (chrony 4.4), measuring packet rates and TX timestamp accuracy
> with ntpperf. While the HW TX timestamping seems more reliable at some
> lower request rates, there seems to be about 40% drop in the overall
> performance of the server in how much requests it can handle (falling
> back to SW timestamps when HW timestamp is missed). Is this expected
> or something to be considered?
I have never ever used ntpperf before, so please bear with me. I've
setup two x86 machines with Debian Trixie, v6.17.0-rc1+ and Intel i210.
Installed ntpperf on one machine and chrony (v4.6) on the second. In the
chrony config there is 'hwtimestamp enp1s0'. I did run the first example
in ntpperf's README with the following results. 'rate' seems to be
higher with my patch applied. Anyway, your ntpperf output looks
completely different. What parameters are you using? I just want to
reproduce your results first.
* ntpperf with igb patch applied
Linux cml1 6.17.0-rc1+ #1 SMP PREEMPT_RT Tue Aug 19 12:56:41 CEST 2025 x86_64 GNU/Linux
Linux cml2 6.17.0-rc1+ #1 SMP PREEMPT_RT Tue Aug 19 12:56:41 CEST 2025 x86_64 GNU/Linux
root@cml1:~/ntpperf# ./ntpperf -i enp1s0 -m 6c:b3:11:52:39:15 -d 192.168.123.1 -s 172.18.0.0/16 -B -H
| responses | response time (ns)
rate clients | lost invalid basic xleave | min mean max stddev
1000 100 0.00% 0.00% 100.00% 0.00% +15124 +16491 +166838 4773
1500 150 0.00% 0.00% 100.00% 0.00% +14589 +16163 +170222 4028
2250 225 0.00% 0.00% 100.00% 0.00% +14337 +15825 +172604 3356
3375 337 0.00% 0.00% 100.00% 0.00% +14267 +15549 +171365 2727
5062 506 0.00% 0.00% 100.00% 0.00% +14033 +15389 +177490 2384
7593 759 0.00% 0.00% 100.00% 0.00% +14307 +15418 +174652 1983
11389 1138 0.00% 0.00% 100.00% 0.00% +14100 +16551 +169245 6036
17083 1708 0.00% 0.00% 100.00% 0.00% +10077 +20077 +194647 9182
25624 2562 0.00% 0.00% 100.00% 0.00% +10007 +25572 +181577 14952
38436 3843 0.00% 0.00% 100.00% 0.00% +6851 +27466 +184041 14900
57654 5765 0.00% 0.00% 100.00% 0.00% +5164 +29218 +246544 16169
86481 8648 0.00% 0.00% 100.00% 0.00% +5346 +36063 +179512 14388
129721 12972 0.00% 0.00% 100.00% 0.00% +7934 +49386 +229427 17600
194581 16384 0.00% 0.00% 100.00% 0.00% +10760 +54961 +248325 18860
291871 16384 0.00% 0.00% 100.00% 0.00% +13207 +57193 +248870 16908
437806 16384 25.42% 0.00% 74.58% 0.00% +211479 +275061 +703480 20529
656709 16384 50.32% 0.00% 49.68% 0.00% +230344 +292741 +485387 19119
* ntpperf without igb patch applied
Linux cml1 6.17.0-rc1+ #3 SMP PREEMPT_RT Tue Aug 19 15:31:35 CEST 2025 x86_64 GNU/Linux
Linux cml2 6.17.0-rc1+ #3 SMP PREEMPT_RT Tue Aug 19 15:31:35 CEST 2025 x86_64 GNU/Linux
root@cml1:~/ntpperf# ./ntpperf -i enp1s0 -m 6c:b3:11:52:39:15 -d 192.168.123.1 -s 172.18.0.0/16 -B -H
| responses | response time (ns)
rate clients | lost invalid basic xleave | min mean max stddev
1000 100 0.00% 0.00% 100.00% 0.00% +18246 +19931 +174292 4947
1500 150 0.00% 0.00% 100.00% 0.00% +17934 +19494 +194876 4368
2250 225 0.00% 0.00% 100.00% 0.00% +17969 +19254 +177394 3449
3375 337 0.00% 0.00% 100.00% 0.00% +17687 +19090 +179947 2807
5062 506 0.00% 0.00% 100.00% 0.00% +17798 +18999 +175463 2403
7593 759 0.00% 0.00% 100.00% 0.00% +17901 +19039 +176656 1984
11389 1138 0.00% 0.00% 100.00% 0.00% +17192 +20318 +184805 6802
17083 1708 0.00% 0.00% 100.00% 0.00% +14241 +24428 +185137 10118
25624 2562 0.00% 0.00% 100.00% 0.00% +4819 +22667 +201990 7962
38436 3843 0.00% 0.00% 100.00% 0.00% +3869 +17957 +192566 8171
57654 5765 0.00% 0.00% 100.00% 0.00% +2529 +14036 +173719 6240
86481 8648 0.00% 0.00% 100.00% 0.00% +2774 +13642 +201026 5284
129721 12972 0.00% 0.00% 100.00% 0.00% +2670 +14699 +242395 6692
194581 16384 0.00% 0.00% 100.00% 0.00% +2520 +19712 +329254 9571
291871 16384 1.37% 0.00% 98.63% 0.00% +2818 +77396 +15480693 182286
437806 16384 24.69% 0.00% 75.31% 0.00% +108662 +246855 +2306431 38520
Could not send requests at rate 656709
Thanks,
Kurt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
next prev parent reply other threads:[~2025-08-19 14:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 6:50 [Intel-wired-lan] [PATCH iwl-next] igb: Retrieve Tx timestamp directly from interrupt Kurt Kanzenbach
2025-08-15 7:55 ` Paul Menzel
2025-08-15 8:10 ` Sebastian Andrzej Siewior
2025-08-15 8:17 ` Kurt Kanzenbach
2025-08-15 12:54 ` Paul Menzel
2025-08-15 16:41 ` Sebastian Andrzej Siewior
2025-08-15 13:58 ` Vadim Fedorenko
2025-08-16 9:06 ` Kurt Kanzenbach
2025-08-18 12:24 ` Miroslav Lichvar
2025-08-19 6:09 ` Kurt Kanzenbach
2025-08-19 14:50 ` Kurt Kanzenbach [this message]
2025-08-20 6:54 ` Miroslav Lichvar
2025-08-19 23:31 ` Jacob Keller
2025-08-20 7:56 ` Miroslav Lichvar
2025-08-20 20:29 ` Jacob Keller
2025-08-21 7:50 ` Miroslav Lichvar
2025-08-21 11:38 ` Kurt Kanzenbach
2025-08-21 12:59 ` Miroslav Lichvar
2025-08-21 14:08 ` Kurt Kanzenbach
2025-08-21 14:51 ` Miroslav Lichvar
2025-08-19 23:24 ` Jacob Keller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ms7vs6vk.fsf@jax.kurt.home \
--to=kurt@linutronix.de \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=mlichvar@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=richardcochran@gmail.com \
--cc=vinicius.gomes@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).