I tried running a `tcp_nup` test in flent with `length` set to 200 seconds & `step-size` set to 0.05 seconds. But the test took more than 10 minutes to complete. On checking the log, I found out that the `ss_iterate.sh` was running  even after other runners had finished execution.  

https://github.com/tohojo/flent/blob/9378031415f9d87b2ef500d082f4720abcec52da/flent/scripts/ss_iterate.sh#L43-L45

My guess is that execution time of ss command was about 0.1 ish  second on average (could see from the output timestamps). So each iteration took about 0.15 seconds to execute and hence total execution of the 4200 iterations took about 10 mins.

I resolved this issue by checking current time against endtime.
```bash
command_string=$(cat <<EOF
duration="$(echo "$count*$interval" | bc) sec";
endtime=\$(date -d "\$duration" +%s%N);
while (( \$(date +%s%N) <= \$endtime )); do
    ss -t -i -p -n state connected "dst $target $filter"
```

Infact the issue exists with `tc_iterate.sh` as well. But the execution time only exceeded by about 20 seconds.

Now this might be a bad idea in general since the use of `bc` and the additional `date` commands may add some overhead (although I didn't see any notable difference b/w timestamps).  

Does this fix seem like a good PR (to `tc_iterate.sh` and `ss_iterate.sh`)? (The endtime calculation can be done from python code and passed to this script instead of passing ```count (test_length / interval)```)
 > (I am using flent with network namespaces in Ubuntu 20.04 machine. I am unsure if this works with other environments)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/236