Unfortunately, this partially counters recent efforts by David to
speed up these tests, but it looks like iperf3 clients don't reliably
terminate, in some rare cases I couldn't isolate yet.
For the moment being, reintroduce the time-based wait approach, now
using the configurable test duration, and terminate the servers at
the end of it, in case they're stuck. There's no point in keeping
the 'sleep 2' later, so drop that, and while at it, make sure that
the stuck servers have time to flush the JSON output before we use
it.
Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com>
---
test/lib/test | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/test/lib/test b/test/lib/test
index d68ade4..7259383 100755
--- a/test/lib/test
+++ b/test/lib/test
@@ -40,7 +40,7 @@ test_iperf3() {
sleep 1 # Wait for server to be ready
- pane_or_context_run "${__cctx}" \
+ pane_or_context_run_bg "${__cctx}" \
'(' \
' for i in $(seq 0 '${__procs}'); do' \
' iperf3 -c '${__dest}' -p '${__port} \
@@ -49,9 +49,12 @@ test_iperf3() {
' wait' \
')'
+ sleep $((__time + 5))
+
# If client fails to deliver control message, tell server we're done
- pane_or_context_run "${__sctx}" \
- 'sleep 2; kill -INT $(cat s*.pid); rm s*.pid'
+ pane_or_context_run "${__sctx}" 'kill -INT $(cat s*.pid); rm
s*.pid'
+
+ sleep 1 # ...and wait for output to be flushed
__jval=".end.sum_received.bits_per_second"
for __opt in ${@}; do
--
2.35.1