Closed shashank68 closed 1 year ago
Hmm, good question. So you're just running ss in a busy loop, or did you keep the 'sleep'? If so, that seems a bit excessive to do by default.
I'd be a bit surprised if you could get this short a polling time out of the shell script, actually; what interval were you able to achieve?
Hmm, good question. So you're just running ss in a busy loop, or did you keep the 'sleep'? If so, that seems a bit excessive to do by default.
Yes I did keep the sleep in the loop. Here's the full loop:
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"
echo ''
date '+Time: %s.%N';
echo "---";
sleep $interval || exit 1;
done
EOF
)
I'd be a bit surprised if you could get this short a polling time out of the shell script, actually; what interval were you able to achieve?
Each iteration of this loop takes almost the same time as with the current implementation in flent. So this doesn't really help to set smaller step-size
. But the total time of all iterations will be closer to the expected test duration set by the user.
Here, I feel that the calculated count is a bit excessive and keeps the loop running for much longer than the set test duration. Using end time calculations in the loop will solve this issue
Shashank D @.***> writes:
Hmm, good question. So you're just running ss in a busy loop, or did you keep the 'sleep'? If so, that seems a bit excessive to do by default. Yes I did keep the sleep in the loop. Here's the full loop:
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" echo '' date '+Time: %s.%N'; echo "---"; sleep $interval || exit 1; done EOF )
Right, makes sense. Feel free to open a PR with this, but please lose the dependency on 'bc'. Either do the math in native shell, or just pass the duration as a parameter from Flent.
Did you test whether this works on OpenWrt and on Dash?
Did you test whether this works on OpenWrt and on Dash?
No. I could only test this on a Ubuntu machine.
Shashank D @.***> writes:
Did you test whether this works on OpenWrt and on Dash? No. I could only test this on a Ubuntu machine.
Right, okay. Well, the 'dash' shell should be available to install on ubuntu as well. Feel free to open a PR with the change, I can test it on OpenWrt...
I tried running a
tcp_nup
test in flent withlength
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 thess_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.
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 additionaldate
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
andss_iterate.sh
)? (The endtime calculation can be done from python code and passed to this script instead of passingcount (test_length / interval)
)