intel-wired-lan.osuosl.org archive mirror
 help / color / mirror / Atom feed
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Kurt Kanzenbach <kurt@linutronix.de>
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: Wed, 20 Aug 2025 08:54:06 +0200	[thread overview]
Message-ID: <aKVxDjocY3uQr342@localhost> (raw)
In-Reply-To: <87ms7vs6vk.fsf@jax.kurt.home>

On Tue, Aug 19, 2025 at 04:50:23PM +0200, Kurt Kanzenbach wrote:
> 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.
> 
> 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

Interleaved mode needs to be selected by the -I option (instead of -B)
in order for the server to enable SW+HW TX timestamps for the
responses it sends back to the client.

My ntpperf command line also had "-x 1.05" to increase the rate in
smaller steps and "-o 0.000000500" to print the offset between the
server TX and client RX timestamp instead of the offset between
server's TX and RX timestamp (response time), but that requires the
NIC PHCs to be synchronized to each other over a different network
link and the -o value to be calibrated for the delays in timestamping
and cable. It's not important for this issue, no need to bother with
that.

> * ntpperf with igb patch applied

> 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
> 
> * ntpperf without igb patch applied

> 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

Those results look the same within few percent, as I'd expect with
the basic NTP mode (-B option), which doesn't enable server's TX
timestamping. Normally, I see larger differences in subsequent runs in
the same configuration.

-- 
Miroslav Lichvar


  reply	other threads:[~2025-08-20  6:54 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
2025-08-20  6:54     ` Miroslav Lichvar [this message]
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=aKVxDjocY3uQr342@localhost \
    --to=mlichvar@redhat.com \
    --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=kurt@linutronix.de \
    --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).