External/passt
1
0
Fork 0
mirror of https://passt.top/passt synced 2024-12-22 21:55:22 +00:00
Code Issues Packages Projects Releases Wiki Activity
f94adb121a
passt/test/perf/passt_tcp

229 lines
6.5 KiB
Plaintext
Raw Normal View History

passt: Relicense to GPL 2.0, or any later version In practical terms, passt doesn't benefit from the additional protection offered by the AGPL over the GPL, because it's not suitable to be executed over a computer network. Further, restricting the distribution under the version 3 of the GPL wouldn't provide any practical advantage either, as long as the passt codebase is concerned, and might cause unnecessary compatibility dilemmas. Change licensing terms to the GNU General Public License Version 2, or any later version, with written permission from all current and past contributors, namely: myself, David Gibson, Laine Stump, Andrea Bolognani, Paul Holzinger, Richard W.M. Jones, Chris Kuhn, Florian Weimer, Giuseppe Scrivano, Stefan Hajnoczi, and Vasiliy Ulyanov. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-04-05 18:11:44 +00:00
# SPDX-License-Identifier: GPL-2.0-or-later
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
#
# PASST - Plug A Simple Socket Transport
# for qemu/UNIX domain socket mode
#
# PASTA - Pack A Subtle Tap Abstraction
# for network namespace/tap device mode
#
# test/perf/passt_tcp - Check TCP performance in passt mode
#
# Copyright (c) 2021 Red Hat GmbH
# Author: Stefano Brivio <sbrivio@redhat.com>
test/perf: Check for /sbin/sysctl with which(1), not simply sysctl Otherwise, we're depending on having /sbin in $PATH. For some reason I didn't completely grasp, with the new command dispatch mechanism that's not the case anymore, even if I have /sbin in $PATH in the parent shell. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-09-16 23:17:04 +00:00
gtools /sbin/sysctl ip jq nproc seq sleep iperf3 tcp_rr tcp_crr # From neper
nstools /sbin/sysctl ip jq nproc seq sleep iperf3 tcp_rr tcp_crr
test/perf: Use CPU frequency from /proc/cpuinfo instead of cpupower(1) Get it to work also in nested virtualisation environments. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-10-19 07:25:29 +00:00
htools bc head sed seq
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
test passt: throughput and latency
guest /sbin/sysctl -w net.core.rmem_max=536870912
guest /sbin/sysctl -w net.core.wmem_max=536870912
guest /sbin/sysctl -w net.core.rmem_default=33554432
guest /sbin/sysctl -w net.core.wmem_default=33554432
guest /sbin/sysctl -w net.ipv4.tcp_rmem="4096 131072 268435456"
guest /sbin/sysctl -w net.ipv4.tcp_wmem="4096 131072 268435456"
guest /sbin/sysctl -w net.ipv4.tcp_timestamps=0
test/perf: Always use /sbin/sysctl in tcp test Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-09-18 13:38:52 +00:00
ns /sbin/sysctl -w net.ipv4.tcp_rmem="4096 524288 134217728"
ns /sbin/sysctl -w net.ipv4.tcp_wmem="4096 524288 134217728"
ns /sbin/sysctl -w net.ipv4.tcp_timestamps=0
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
Don't abbreviate ip(8) arguments in examples and tests ip(8)'s ability to take abbreviated arguments (e.g. "li sh" instead of "link show") is very handy when using it interactively, but it doesn't make for very readable scripts and examples when shown that way. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-06-10 02:32:42 +00:00
gout GW ip -j -4 route show|jq -rM '.[] | select(.dst == "default").gateway'
gout GW6 ip -j -6 route show|jq -rM '.[] | select(.dst == "default").gateway'
gout IFNAME ip -j link show | jq -rM '.[] | select(.link_type == "ether").ifname'
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
test/perf: Try sourcing maximum scaling frequency from cpufreq On most recent CPUs, that's a better indication of all-core turbo frequency, or non-turbo frequency, than /proc/cpuinfo. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-10-20 23:24:22 +00:00
hout FREQ_PROCFS (echo "scale=1"; sed -n 's/cpu MHz.*: \([0-9]*\)\..*$/(\1+10^2\/2)\/10^3/p' /proc/cpuinfo) | bc -l | head -n1
hout FREQ_CPUFREQ (echo "scale=1"; printf '( %i + 10^5 / 2 ) / 10^6\n' $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq) ) | bc -l
hout FREQ [ -n "__FREQ_CPUFREQ__" ] && echo __FREQ_CPUFREQ__ || echo __FREQ_PROCFS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
set THREADS 1
set STREAMS 8
test/perf: Switch performance test duration to 10 seconds instead of 30 It looks like the workaround for the virtio_net TX hang issue is working less reliably with the new command dispatch mechanism, I'm not sure why. Switch to 10 seconds, at least for the moment. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-09-18 13:39:59 +00:00
set TIME 10
test: Parameterize run time for throughput performance tests Currently all the throughput tests are run for 30s. This is reflected in both the actual parameters given to the iperf commands, but also in the matching sleeps in test_iperf3. Allow this to be adjusted more easily with a new parameter to test_iperf3. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Reflect new parameter in comment to test_iperf3()] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-09-02 02:04:33 +00:00
hout OMIT echo __TIME__ / 6 | bc -l
test/perf: Disable periodic throughput reports to avoid vhost hang It appears that if we run throughput tests with one-second periodic reports, the sending side of the vhost channel used for SSH-based command dispatch occasionally stops working altogether. I haven't investigated this further, all I see is that output is truncated at some point, and doesn't resume. If we use gzip compression (ssh -C) this happens less frequently, but it still happens, seemingly indicating the issue is probably related to vhost itself. Disable periodic reports in iperf3 clients. The -i options were actually redundant, so remove them from both test files as well as from test_iperf3(). Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-09-20 23:21:32 +00:00
set OPTS -Z -P __STREAMS__ -l 1M -O__OMIT__ --pacing-timer 1000000
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
info Throughput in Gbps, latency in µs, one thread at __FREQ__ GHz, __STREAMS__ streams
report passt tcp __THREADS__ __FREQ__
th MTU 256B 576B 1280B 1500B 9000B 65520B
tr TCP throughput over IPv6: guest to host
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3s ns 100${i}2 __THREADS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw -
bw -
guest ip link set dev __IFNAME__ mtu 1280
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW guest __GW6__%__IFNAME__ 100${i}2 __THREADS__ __TIME__ __OPTS__ -w 4M
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 1.2 1.5
guest ip link set dev __IFNAME__ mtu 1500
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW guest __GW6__%__IFNAME__ 100${i}2 __THREADS__ __TIME__ __OPTS__ -w 4M
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 1.6 1.8
guest ip link set dev __IFNAME__ mtu 9000
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW guest __GW6__%__IFNAME__ 100${i}2 __THREADS__ __TIME__ __OPTS__ -w 8M
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 4.0 5.0
guest ip link set dev __IFNAME__ mtu 65520
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW guest __GW6__%__IFNAME__ 100${i}2 __THREADS__ __TIME__ __OPTS__ -w 16M
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 7.0 8.0
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3k ns
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
tl TCP RR latency over IPv6: guest to host
lat -
lat -
lat -
lat -
lat -
nsb tcp_rr --nolog -6
gout LAT tcp_rr --nolog -6 -c -H __GW6__%__IFNAME__ | sed -n 's/^throughput=\(.*\)/\1/p'
lat __LAT__ 200 150
tl TCP CRR latency over IPv6: guest to host
lat -
lat -
lat -
lat -
lat -
nsb tcp_crr --nolog -6
gout LAT tcp_crr --nolog -6 -c -H __GW6__%__IFNAME__ | sed -n 's/^throughput=\(.*\)/\1/p'
lat __LAT__ 500 400
tr TCP throughput over IPv4: guest to host
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3s ns 100${i}2 __THREADS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
guest ip link set dev __IFNAME__ mtu 256
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW guest __GW__ 100${i}2 __THREADS__ __TIME__ __OPTS__ -w 1M
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 0.2 0.3
guest ip link set dev __IFNAME__ mtu 576
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW guest __GW__ 100${i}2 __THREADS__ __TIME__ __OPTS__ -w 1M
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 0.5 0.8
guest ip link set dev __IFNAME__ mtu 1280
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW guest __GW__ 100${i}2 __THREADS__ __TIME__ __OPTS__ -w 4M
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 1.2 1.5
guest ip link set dev __IFNAME__ mtu 1500
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW guest __GW__ 100${i}2 __THREADS__ __TIME__ __OPTS__ -w 4M
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 1.6 1.8
guest ip link set dev __IFNAME__ mtu 9000
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW guest __GW__ 100${i}2 __THREADS__ __TIME__ __OPTS__ -w 8M
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 4.0 5.0
guest ip link set dev __IFNAME__ mtu 65520
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW guest __GW__ 100${i}2 __THREADS__ __TIME__ __OPTS__ -w 16M
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 7.0 8.0
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3k ns
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
tl TCP RR latency over IPv4: guest to host
lat -
lat -
lat -
lat -
lat -
nsb tcp_rr --nolog -4
gout LAT tcp_rr --nolog -4 -c -H __GW__ | sed -n 's/^throughput=\(.*\)/\1/p'
lat __LAT__ 200 150
tl TCP CRR latency over IPv4: guest to host
lat -
lat -
lat -
lat -
lat -
nsb tcp_crr --nolog -4
gout LAT tcp_crr --nolog -4 -c -H __GW__ | sed -n 's/^throughput=\(.*\)/\1/p'
lat __LAT__ 500 400
tr TCP throughput over IPv6: host to guest
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3s guest 100${i}1 __THREADS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw -
bw -
ns ip link set dev lo mtu 1280
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW ns ::1 100${i}1 __THREADS__ __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 1.0 1.2
ns ip link set dev lo mtu 1500
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW ns ::1 100${i}1 __THREADS__ __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 2.0 3.0
ns ip link set dev lo mtu 9000
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW ns ::1 100${i}1 __THREADS__ __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 5.0 6.0
ns ip link set dev lo mtu 65520
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW ns ::1 100${i}1 __THREADS__ __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 6.0 6.8
ns ip link set dev lo mtu 65535
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3k guest
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
tl TCP RR latency over IPv6: host to guest
lat -
lat -
lat -
lat -
lat -
guestb tcp_rr --nolog -P 10001 -C 10011 -6
test/perf: Wait for neper servers in guest to be ready before starting client Starting tcp_rr, tcp_crr, udp_rr servers in the guest takes a bit longer than starting the corresponding clients on the host, and we end up starting clients before servers unless we add a delay there. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-09-22 14:40:28 +00:00
sleep 1
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
nsout LAT tcp_rr --nolog -P 10001 -C 10011 -6 -c -H ::1 | sed -n 's/^throughput=\(.*\)/\1/p'
lat __LAT__ 200 150
tl TCP CRR latency over IPv6: host to guest
lat -
lat -
lat -
lat -
lat -
guestb tcp_crr --nolog -P 10001 -C 10011 -6
test/perf: Wait for neper servers in guest to be ready before starting client Starting tcp_rr, tcp_crr, udp_rr servers in the guest takes a bit longer than starting the corresponding clients on the host, and we end up starting clients before servers unless we add a delay there. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-09-22 14:40:28 +00:00
sleep 1
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
nsout LAT tcp_crr --nolog -P 10001 -C 10011 -6 -c -H ::1 | sed -n 's/^throughput=\(.*\)/\1/p'
lat __LAT__ 500 350
tr TCP throughput over IPv4: host to guest
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3s guest 100${i}1 __THREADS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
ns ip link set dev lo mtu 256
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW ns 127.0.0.1 100${i}1 __THREADS__ __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 0.3 0.5
ns ip link set dev lo mtu 576
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW ns 127.0.0.1 100${i}1 __THREADS__ __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 0.5 1.0
ns ip link set dev lo mtu 1280
ns ip addr add ::1 dev lo
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW ns 127.0.0.1 100${i}1 __THREADS__ __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 2.0 3.0
ns ip link set dev lo mtu 1500
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW ns 127.0.0.1 100${i}1 __THREADS__ __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 2.0 3.0
ns ip link set dev lo mtu 9000
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW ns 127.0.0.1 100${i}1 __THREADS__ __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 5.0 6.0
ns ip link set dev lo mtu 65520
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3 BW ns 127.0.0.1 100${i}1 __THREADS__ __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
bw __BW__ 6.0 6.8
ns ip link set dev lo mtu 65535
test/perf: Start iperf3 server less often Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 07:08:28 +00:00
iperf3k guest
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
tl TCP RR latency over IPv4: host to guest
lat -
lat -
lat -
lat -
lat -
guestb tcp_rr --nolog -P 10001 -C 10011 -4
test/perf: Wait for neper servers in guest to be ready before starting client Starting tcp_rr, tcp_crr, udp_rr servers in the guest takes a bit longer than starting the corresponding clients on the host, and we end up starting clients before servers unless we add a delay there. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-09-22 14:40:28 +00:00
sleep 1
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
nsout LAT tcp_rr --nolog -P 10001 -C 10011 -4 -c -H 127.0.0.1 | sed -n 's/^throughput=\(.*\)/\1/p'
lat __LAT__ 200 150
tl TCP CRR latency over IPv6: host to guest
lat -
lat -
lat -
lat -
lat -
guestb tcp_crr --nolog -P 10001 -C 10011 -4
test/perf: Wait for neper servers in guest to be ready before starting client Starting tcp_rr, tcp_crr, udp_rr servers in the guest takes a bit longer than starting the corresponding clients on the host, and we end up starting clients before servers unless we add a delay there. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-09-22 14:40:28 +00:00
sleep 1
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 13:10:35 +00:00
nsout LAT tcp_crr --nolog -P 10001 -C 10011 -4 -c -H 127.0.0.1 | sed -n 's/^throughput=\(.*\)/\1/p'
lat __LAT__ 500 300
te
Reference in New Issue Copy Permalink