[PATCH v2] test: Update the threshold value for some perf tests
The values are adjusted to better match results observerd on the
test hardware with 56-core Xeon Gold 6330 CPU and 126 GB RAM.
Link: https://bugs.passt.top/show_bug.cgi?id=156
Signed-off-by: Yumei Huang
On Mon, Oct 13, 2025 at 09:31:41AM +0800, Yumei Huang wrote:
The values are adjusted to better match results observerd on the test hardware with 56-core Xeon Gold 6330 CPU and 126 GB RAM.
Interesting. That CPU is older than the one on my laptop (i7-12800H), which comfortably hit the old thresholds, but by less than a year (Q2 2021 versus Q1 2022). At the same time it's a much fancier model for its generation. I thought the Xeons might have been built with better memory bandwidth which probably has more effect on passt than the CPU's computational speed. I'm not certain what machine Stefano was using to estimate the existing thresholds, but I'm guessing it was passt.top which is an AMD Ryzen 5 3600 - older than both of the above (2019). passt is single threaded so the Xeon's many cores wouldn't help it, but it's still surprising that it can't keep up with the other machines we've tried on.
Link: https://bugs.passt.top/show_bug.cgi?id=156 Signed-off-by: Yumei Huang
--- test/perf/passt_tcp | 6 +++--- test/perf/pasta_udp | 8 ++++---- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/test/perf/passt_tcp b/test/perf/passt_tcp index 5978c49..1a97a63 100644 --- a/test/perf/passt_tcp +++ b/test/perf/passt_tcp @@ -87,7 +87,7 @@ lat - lat - nsb tcp_crr --nolog -6 gout LAT tcp_crr --nolog -l1 -6 -c -H __MAP_NS6__ | sed -n 's/^throughput=\(.*\)/\1/p' -lat __LAT__ 500 400 +lat __LAT__ 550 450
tr TCP throughput over IPv4: guest to host iperf3s ns 10002 @@ -137,7 +137,7 @@ lat - lat - nsb tcp_crr --nolog -4 gout LAT tcp_crr --nolog -l1 -4 -c -H __MAP_NS4__ | sed -n 's/^throughput=\(.*\)/\1/p' -lat __LAT__ 500 400 +lat __LAT__ 550 450
tr TCP throughput over IPv6: host to guest iperf3s guest 10001 @@ -208,6 +208,6 @@ lat - guestb tcp_crr --nolog -P 10001 -C 10011 -4 sleep 1 nsout LAT tcp_crr --nolog -l1 -P 10001 -C 10011 -4 -c -H 127.0.0.1 | sed -n 's/^throughput=\(.*\)/\1/p' -lat __LAT__ 500 300 +lat __LAT__ 500 350
te diff --git a/test/perf/pasta_udp b/test/perf/pasta_udp index 3a7054c..c51bb6c 100644 --- a/test/perf/pasta_udp +++ b/test/perf/pasta_udp @@ -39,7 +39,7 @@ iperf3s host 10003 # (datagram size) = (packet size) - 48: 40 bytes of IPv6 header, 8 of UDP header
iperf3 BW ns ::1 10003 __TIME__ __OPTS__ -b 5G -l 1452 -bw __BW__ 1.0 1.5 +bw __BW__ 0.8 1.2 iperf3 BW ns ::1 10003 __TIME__ __OPTS__ -b 10G -l 3972 bw __BW__ 1.2 1.8 iperf3 BW ns ::1 10003 __TIME__ __OPTS__ -b 30G -l 16336 @@ -64,7 +64,7 @@ iperf3s host 10003 # (datagram size) = (packet size) - 28: 20 bytes of IPv4 header, 8 of UDP header
iperf3 BW ns 127.0.0.1 10003 __TIME__ __OPTS__ -b 5G -l 1372 -bw __BW__ 1.0 1.5 +bw __BW__ 0.8 1.2 iperf3 BW ns 127.0.0.1 10003 __TIME__ __OPTS__ -b 10G -l 3972 bw __BW__ 1.2 1.8 iperf3 BW ns 127.0.0.1 10003 __TIME__ __OPTS__ -b 30G -l 16356 @@ -88,7 +88,7 @@ tr UDP throughput over IPv6: host to ns iperf3s ns 10002
iperf3 BW host ::1 10002 __TIME__ __OPTS__ -b 5G -l 1452 -bw __BW__ 1.0 1.5 +bw __BW__ 0.8 1.2 iperf3 BW host ::1 10002 __TIME__ __OPTS__ -b 10G -l 3972 bw __BW__ 1.2 1.8 iperf3 BW host ::1 10002 __TIME__ __OPTS__ -b 30G -l 16336 @@ -111,7 +111,7 @@ lat __LAT__ 200 150 tr UDP throughput over IPv4: host to ns iperf3s ns 10002 iperf3 BW host 127.0.0.1 10002 __TIME__ __OPTS__ -b 5G -l 1372 -bw __BW__ 1.0 1.5 +bw __BW__ 0.8 1.2 iperf3 BW host 127.0.0.1 10002 __TIME__ __OPTS__ -b 10G -l 3972 bw __BW__ 1.2 1.8 iperf3 BW host 127.0.0.1 10002 __TIME__ __OPTS__ -b 30G -l 16356 -- 2.47.0
-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Mon, 13 Oct 2025 15:39:32 +1100
David Gibson
On Mon, Oct 13, 2025 at 09:31:41AM +0800, Yumei Huang wrote:
The values are adjusted to better match results observerd on the test hardware with 56-core Xeon Gold 6330 CPU and 126 GB RAM.
Interesting. That CPU is older than the one on my laptop (i7-12800H), which comfortably hit the old thresholds, but by less than a year (Q2 2021 versus Q1 2022). At the same time it's a much fancier model for its generation. I thought the Xeons might have been built with better memory bandwidth which probably has more effect on passt than the CPU's computational speed.
I'm not certain what machine Stefano was using to estimate the existing thresholds, but I'm guessing it was passt.top which is an AMD Ryzen 5 3600 - older than both of the above (2019).
Yep.
passt is single threaded so the Xeon's many cores wouldn't help it, but it's still surprising that it can't keep up with the other machines we've tried on.
Kernels and LSMs might make a huge difference as well. I expect a substantial system call overhead (because that's what it is here, I guess?) might come from SELinux hooks. Not that it really matters, I think, as long as numbers are reasonable (and we don't make them worse with some unsuspecting change) I don't see an actual problem with it. -- Stefano
participants (3)
-
David Gibson
-
Stefano Brivio
-
Yumei Huang