mirrors/passt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
passt/test/perf/passt_tcp

211 lines
5.4 KiB
Text
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 20:11:44 +02: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 15:10:35 +02: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-17 01:17:04 +02: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 09:25:29 +02: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 15:10:35 +02: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 15:38:52 +02: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 15:10:35 +02: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 04:32:42 +02: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 15:10:35 +02: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-21 01:24:22 +02: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 15:10:35 +02:00
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
set THREADS 4
test: Speed up by cutting on eye candy and performance test duration We have a number of delays when we switch to new layouts that were added to make the tests visually easier to follow, together with blinking status bars. Shorten the delays and avoid blinking the status bar if $FAST is set to 1 (no demo mode). Shorten delays in busy loops to 10ms, instead of 100ms, and skip the one-second fixed delay when we wait for the status of a command. Cut the duration of throughput and latency tests to one second, down from ten. Somewhat surprisingly, the results we get are rather consistent, and not significantly different from what we'd get with 10 seconds. This, together with Podman's commit 20f3e8909e3a ("test/system: pasta_test_do add explicit port check"), cuts the time needed on my setup for full test run from approximately 37 minutes to...: $ time ./run [exited] PASS: 165, FAIL: 0 Log at /home/sbrivio/passt/test/test_logs/test.log real 15m34.253s user 0m0.011s sys 0m0.011s Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-08-14 19:25:38 +02:00
set TIME 1
test/perf: Simplify calculation of "omit" time for TCP throughput For the TCP throughput tests, we use iperf3's -O "omit" option which ignores results for the given time at the beginning of the test. Currently we calculate this as 1/6th of the test measurement time. The purpose of -O, however, is to skip over the TCP slow start period, which in no way depends on the overall length of the test. The slow start time is roughly speaking log_2 ( max_window_size / MSS ) * round_trip_time These factors all vary between tests and machines we're running on, but we can estimate some reasonable bounds for them: * The maximum window size is bounded by the buffer sizes at each end, which shouldn't exceed 16MiB * The mss varies with the MTU we use, but the smallest we use in tests is ~256 bytes * Round trip time will vary with the system, but with these essentially local transfers it will typically be well under 1ms (on my laptop it is closer to 0.03ms) That gives a worst case slow start time of about 16ms. Setting an omit time of 0.1s uniformly is therefore more than enough, and substantially smaller than what we calculate now for the default case (10s / 6 ~= 1.7s). This reduces total time for the standard benchmark run by around 30s. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 08:08:33 +01:00
set OMIT 0.1
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
set OPTS -Z -P __THREADS__ -l 1M -O__OMIT__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
info Throughput in Gbps, latency in µs, __THREADS__ threads at __FREQ__ GHz
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
report passt tcp __THREADS__ __FREQ__
th MTU 256B 576B 1280B 1500B 9000B 65520B
tr TCP throughput over IPv6: guest to host
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3s ns 10002
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 08:08:28 +01:00
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
bw -
bw -
guest ip link set dev __IFNAME__ mtu 1280
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW guest __GW6__%__IFNAME__ 10002 __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 15:10:35 +02:00
bw __BW__ 1.2 1.5
guest ip link set dev __IFNAME__ mtu 1500
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW guest __GW6__%__IFNAME__ 10002 __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 15:10:35 +02:00
bw __BW__ 1.6 1.8
guest ip link set dev __IFNAME__ mtu 9000
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW guest __GW6__%__IFNAME__ 10002 __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 15:10:35 +02:00
bw __BW__ 4.0 5.0
guest ip link set dev __IFNAME__ mtu 65520
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW guest __GW6__%__IFNAME__ 10002 __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 15:10:35 +02: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 08:08:28 +01:00
iperf3k ns
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
tl TCP RR latency over IPv6: guest to host
lat -
lat -
lat -
lat -
lat -
nsb tcp_rr --nolog -6
test: Speed up by cutting on eye candy and performance test duration We have a number of delays when we switch to new layouts that were added to make the tests visually easier to follow, together with blinking status bars. Shorten the delays and avoid blinking the status bar if $FAST is set to 1 (no demo mode). Shorten delays in busy loops to 10ms, instead of 100ms, and skip the one-second fixed delay when we wait for the status of a command. Cut the duration of throughput and latency tests to one second, down from ten. Somewhat surprisingly, the results we get are rather consistent, and not significantly different from what we'd get with 10 seconds. This, together with Podman's commit 20f3e8909e3a ("test/system: pasta_test_do add explicit port check"), cuts the time needed on my setup for full test run from approximately 37 minutes to...: $ time ./run [exited] PASS: 165, FAIL: 0 Log at /home/sbrivio/passt/test/test_logs/test.log real 15m34.253s user 0m0.011s sys 0m0.011s Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-08-14 19:25:38 +02:00
gout LAT tcp_rr --nolog -l1 -6 -c -H __GW6__%__IFNAME__ | sed -n 's/^throughput=\(.*\)/\1/p'
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
lat __LAT__ 200 150
tl TCP CRR latency over IPv6: guest to host
lat -
lat -
lat -
lat -
lat -
nsb tcp_crr --nolog -6
test: Speed up by cutting on eye candy and performance test duration We have a number of delays when we switch to new layouts that were added to make the tests visually easier to follow, together with blinking status bars. Shorten the delays and avoid blinking the status bar if $FAST is set to 1 (no demo mode). Shorten delays in busy loops to 10ms, instead of 100ms, and skip the one-second fixed delay when we wait for the status of a command. Cut the duration of throughput and latency tests to one second, down from ten. Somewhat surprisingly, the results we get are rather consistent, and not significantly different from what we'd get with 10 seconds. This, together with Podman's commit 20f3e8909e3a ("test/system: pasta_test_do add explicit port check"), cuts the time needed on my setup for full test run from approximately 37 minutes to...: $ time ./run [exited] PASS: 165, FAIL: 0 Log at /home/sbrivio/passt/test/test_logs/test.log real 15m34.253s user 0m0.011s sys 0m0.011s Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-08-14 19:25:38 +02:00
gout LAT tcp_crr --nolog -l1 -6 -c -H __GW6__%__IFNAME__ | sed -n 's/^throughput=\(.*\)/\1/p'
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
lat __LAT__ 500 400
tr TCP throughput over IPv4: guest to host
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3s ns 10002
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 08:08:28 +01:00
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
guest ip link set dev __IFNAME__ mtu 256
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW guest __GW__ 10002 __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 15:10:35 +02:00
bw __BW__ 0.2 0.3
guest ip link set dev __IFNAME__ mtu 576
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW guest __GW__ 10002 __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 15:10:35 +02:00
bw __BW__ 0.5 0.8
guest ip link set dev __IFNAME__ mtu 1280
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW guest __GW__ 10002 __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 15:10:35 +02:00
bw __BW__ 1.2 1.5
guest ip link set dev __IFNAME__ mtu 1500
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW guest __GW__ 10002 __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 15:10:35 +02:00
bw __BW__ 1.6 1.8
guest ip link set dev __IFNAME__ mtu 9000
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW guest __GW__ 10002 __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 15:10:35 +02:00
bw __BW__ 4.0 5.0
guest ip link set dev __IFNAME__ mtu 65520
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW guest __GW__ 10002 __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 15:10:35 +02: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 08:08:28 +01:00
iperf3k ns
test: Reconfigure IPv6 address after changing MTU In the TCP throughput tests, we adjust the guest's MTU in order to test various packet sizes. Some of those are below 1280 which causes IPv6 to be deconfigured on the guest interface. When we increase it above 1280 again, IPv6 is re-enabled and we get an address in the right prefix with NDP, but we don't get exactly the expected address back - that's only communicated with --config-net or DHCPv6. With changes to how we handle NAT this can cause some of the IPv6 tests to fail, because they don't use the address that passt/pasta expects, and the guest doesn't initiate any traffic which allows us to learn what the new address is. Work around this by re-invoking dhclient -6 between adjusting the MTU and running IPv6 test cases. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-08-21 06:20:16 +02:00
# Reducing MTU below 1280 deconfigures IPv6, get our address back
guest dhclient -6 -x
guest dhclient -6 __IFNAME__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
tl TCP RR latency over IPv4: guest to host
lat -
lat -
lat -
lat -
lat -
nsb tcp_rr --nolog -4
test: Speed up by cutting on eye candy and performance test duration We have a number of delays when we switch to new layouts that were added to make the tests visually easier to follow, together with blinking status bars. Shorten the delays and avoid blinking the status bar if $FAST is set to 1 (no demo mode). Shorten delays in busy loops to 10ms, instead of 100ms, and skip the one-second fixed delay when we wait for the status of a command. Cut the duration of throughput and latency tests to one second, down from ten. Somewhat surprisingly, the results we get are rather consistent, and not significantly different from what we'd get with 10 seconds. This, together with Podman's commit 20f3e8909e3a ("test/system: pasta_test_do add explicit port check"), cuts the time needed on my setup for full test run from approximately 37 minutes to...: $ time ./run [exited] PASS: 165, FAIL: 0 Log at /home/sbrivio/passt/test/test_logs/test.log real 15m34.253s user 0m0.011s sys 0m0.011s Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-08-14 19:25:38 +02:00
gout LAT tcp_rr --nolog -l1 -4 -c -H __GW__ | sed -n 's/^throughput=\(.*\)/\1/p'
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
lat __LAT__ 200 150
tl TCP CRR latency over IPv4: guest to host
lat -
lat -
lat -
lat -
lat -
nsb tcp_crr --nolog -4
test: Speed up by cutting on eye candy and performance test duration We have a number of delays when we switch to new layouts that were added to make the tests visually easier to follow, together with blinking status bars. Shorten the delays and avoid blinking the status bar if $FAST is set to 1 (no demo mode). Shorten delays in busy loops to 10ms, instead of 100ms, and skip the one-second fixed delay when we wait for the status of a command. Cut the duration of throughput and latency tests to one second, down from ten. Somewhat surprisingly, the results we get are rather consistent, and not significantly different from what we'd get with 10 seconds. This, together with Podman's commit 20f3e8909e3a ("test/system: pasta_test_do add explicit port check"), cuts the time needed on my setup for full test run from approximately 37 minutes to...: $ time ./run [exited] PASS: 165, FAIL: 0 Log at /home/sbrivio/passt/test/test_logs/test.log real 15m34.253s user 0m0.011s sys 0m0.011s Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-08-14 19:25:38 +02:00
gout LAT tcp_crr --nolog -l1 -4 -c -H __GW__ | sed -n 's/^throughput=\(.*\)/\1/p'
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
lat __LAT__ 500 400
tr TCP throughput over IPv6: host to guest
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3s guest 10001
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 08:08:28 +01:00
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
bw -
bw -
test/perf: "MTU" changes in passt_tcp host to guest aren't useful The TCP packet size used on the passt L2 link (qemu socket) makes a huge difference to passt/pasta throughput; many of passt's overheads (chiefly syscalls) are per-packet. That packet size is largely determined by the MTU on the L2 link, so we benchmark for a number of different MTUs. That works well for the guest to host transfers. For the host to guest transfers, we purport to test for different MTUs, but we're not actually adjusting anything interesting. The host to guest transfers adjust the MTU on the "host's" (actually ns) loopback interface. However, that only affects the packet size for the socket going to passt, not the packet size for the L2 link that passt manages - passt can and will repack the stream into packets of its own size. Since the depacketization on that socket is handled by the kernel it doesn't have a lot of bearing on passt's performance. We can't fix this by changing the L2 link MTU from the guest side (as we do for guest to host), because that would only change the guest's view of the MTU, passt would still think it has the large MTU. We could test this by using the --mtu option to passt, but that would require restarting passt for each run, which is awkward in the current setup. So, for now, drop all the "small MTU" tests for host to guest. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 08:08:31 +01:00
bw -
bw -
bw -
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW ns ::1 10001 __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
bw __BW__ 6.0 6.8
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 08:08:28 +01:00
iperf3k guest
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02: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 16:40:28 +02:00
sleep 1
test: Speed up by cutting on eye candy and performance test duration We have a number of delays when we switch to new layouts that were added to make the tests visually easier to follow, together with blinking status bars. Shorten the delays and avoid blinking the status bar if $FAST is set to 1 (no demo mode). Shorten delays in busy loops to 10ms, instead of 100ms, and skip the one-second fixed delay when we wait for the status of a command. Cut the duration of throughput and latency tests to one second, down from ten. Somewhat surprisingly, the results we get are rather consistent, and not significantly different from what we'd get with 10 seconds. This, together with Podman's commit 20f3e8909e3a ("test/system: pasta_test_do add explicit port check"), cuts the time needed on my setup for full test run from approximately 37 minutes to...: $ time ./run [exited] PASS: 165, FAIL: 0 Log at /home/sbrivio/passt/test/test_logs/test.log real 15m34.253s user 0m0.011s sys 0m0.011s Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-08-14 19:25:38 +02:00
nsout LAT tcp_rr --nolog -l1 -P 10001 -C 10011 -6 -c -H ::1 | sed -n 's/^throughput=\(.*\)/\1/p'
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
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 16:40:28 +02:00
sleep 1
test: Speed up by cutting on eye candy and performance test duration We have a number of delays when we switch to new layouts that were added to make the tests visually easier to follow, together with blinking status bars. Shorten the delays and avoid blinking the status bar if $FAST is set to 1 (no demo mode). Shorten delays in busy loops to 10ms, instead of 100ms, and skip the one-second fixed delay when we wait for the status of a command. Cut the duration of throughput and latency tests to one second, down from ten. Somewhat surprisingly, the results we get are rather consistent, and not significantly different from what we'd get with 10 seconds. This, together with Podman's commit 20f3e8909e3a ("test/system: pasta_test_do add explicit port check"), cuts the time needed on my setup for full test run from approximately 37 minutes to...: $ time ./run [exited] PASS: 165, FAIL: 0 Log at /home/sbrivio/passt/test/test_logs/test.log real 15m34.253s user 0m0.011s sys 0m0.011s Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-08-14 19:25:38 +02:00
nsout LAT tcp_crr --nolog -l1 -P 10001 -C 10011 -6 -c -H ::1 | sed -n 's/^throughput=\(.*\)/\1/p'
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
lat __LAT__ 500 350
tr TCP throughput over IPv4: host to guest
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3s guest 10001
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 08:08:28 +01:00
test/perf: "MTU" changes in passt_tcp host to guest aren't useful The TCP packet size used on the passt L2 link (qemu socket) makes a huge difference to passt/pasta throughput; many of passt's overheads (chiefly syscalls) are per-packet. That packet size is largely determined by the MTU on the L2 link, so we benchmark for a number of different MTUs. That works well for the guest to host transfers. For the host to guest transfers, we purport to test for different MTUs, but we're not actually adjusting anything interesting. The host to guest transfers adjust the MTU on the "host's" (actually ns) loopback interface. However, that only affects the packet size for the socket going to passt, not the packet size for the L2 link that passt manages - passt can and will repack the stream into packets of its own size. Since the depacketization on that socket is handled by the kernel it doesn't have a lot of bearing on passt's performance. We can't fix this by changing the L2 link MTU from the guest side (as we do for guest to host), because that would only change the guest's view of the MTU, passt would still think it has the large MTU. We could test this by using the --mtu option to passt, but that would require restarting passt for each run, which is awkward in the current setup. So, for now, drop all the "small MTU" tests for host to guest. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-06 08:08:31 +01:00
bw -
bw -
bw -
bw -
bw -
test: iperf3 3.16 introduces multiple threads, drop our own implementation of that Starting from iperf3 version 3.16, -P / --parallel spawns multiple clients as separate threads, instead of multiple streams serviced by the same thread. So we can drop our lib/test implementation to spawn several iperf3 client and server processes and finally simplify things quite a bit. Adjust number of threads and UDP sending bandwidth to values that seem to be more or less matching previous throughput tests on my setup. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-07-24 22:40:32 +02:00
iperf3 BW ns 127.0.0.1 10001 __TIME__ __OPTS__
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
bw __BW__ 6.0 6.8
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 08:08:28 +01:00
iperf3k guest
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02: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 16:40:28 +02:00
sleep 1
test: Speed up by cutting on eye candy and performance test duration We have a number of delays when we switch to new layouts that were added to make the tests visually easier to follow, together with blinking status bars. Shorten the delays and avoid blinking the status bar if $FAST is set to 1 (no demo mode). Shorten delays in busy loops to 10ms, instead of 100ms, and skip the one-second fixed delay when we wait for the status of a command. Cut the duration of throughput and latency tests to one second, down from ten. Somewhat surprisingly, the results we get are rather consistent, and not significantly different from what we'd get with 10 seconds. This, together with Podman's commit 20f3e8909e3a ("test/system: pasta_test_do add explicit port check"), cuts the time needed on my setup for full test run from approximately 37 minutes to...: $ time ./run [exited] PASS: 165, FAIL: 0 Log at /home/sbrivio/passt/test/test_logs/test.log real 15m34.253s user 0m0.011s sys 0m0.011s Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-08-14 19:25:38 +02:00
nsout LAT tcp_rr --nolog -l1 -P 10001 -C 10011 -4 -c -H 127.0.0.1 | sed -n 's/^throughput=\(.*\)/\1/p'
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
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 16:40:28 +02:00
sleep 1
test: Speed up by cutting on eye candy and performance test duration We have a number of delays when we switch to new layouts that were added to make the tests visually easier to follow, together with blinking status bars. Shorten the delays and avoid blinking the status bar if $FAST is set to 1 (no demo mode). Shorten delays in busy loops to 10ms, instead of 100ms, and skip the one-second fixed delay when we wait for the status of a command. Cut the duration of throughput and latency tests to one second, down from ten. Somewhat surprisingly, the results we get are rather consistent, and not significantly different from what we'd get with 10 seconds. This, together with Podman's commit 20f3e8909e3a ("test/system: pasta_test_do add explicit port check"), cuts the time needed on my setup for full test run from approximately 37 minutes to...: $ time ./run [exited] PASS: 165, FAIL: 0 Log at /home/sbrivio/passt/test/test_logs/test.log real 15m34.253s user 0m0.011s sys 0m0.011s Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: David Gibson <david@gibson.dropbear.id.au>
2024-08-14 19:25:38 +02:00
nsout LAT tcp_crr --nolog -l1 -P 10001 -C 10011 -4 -c -H 127.0.0.1 | sed -n 's/^throughput=\(.*\)/\1/p'
test: Add CI/demo scripts Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-09-27 15:10:35 +02:00
lat __LAT__ 500 300
te
Reference in a new issue Copy permalink