Bug finding, the other way

[Michael Welzl < >]

Ugly stuff, this … but:

it seems the bug of ns-3’s ever-growing cwnd only happens with relatively 
large bandwidth*delay product values, or in particular with large delay (e.g. 
caused by a long queue).  And, it always seems to be the same: slow start, 
followed by immediate reductions, and then after growing again in congestion 
avoidance, cwnd grows endlessly.

I decided to check, for my own test scenarios, if this happens - to be able 
to filter out the cases with the bug.
If, after reducing cwnd after reaching its max. value (which would be in slow 
start), it exceeds the max value again, something is really weird, and I call 
this a bug.

I made a minor change to my “michaelssim” script to make this check, which 
I’m attaching. I call it “bugfinder”.
I’m also attaching:
- wafrun.sh, which allows to call waf more easily in a loop (avoiding a 
problem due to the “ symbols in bash - good for bash beginners like me)
- a perl script that runs wafrun for all my parameters, just to show how that 
works
- bugfinder-plotcwnd, which is the same as bugfinder, but prints out the 
cwnd, so it helps for a quick check if a bug was real or not.

Note that getting neither an indication of a bug nor a comment like this one:
***
Reducing cwnd from 101138 to 48441 at s=24.967; no bug expected.
***
may mean that the simulation was too short, and it’s worth looking at the 
cwnd too


Maybe you want to run this for the fixed capacity and delay values of the 
evaluation suite tests too, just to see if everything is okay…   but I guess 
when you add more traffic and more loss reactions then the behavior becomes 
normal anyway.

A lot of wild guessing here… but what else can we do, except really detecting 
and fixing this bug…   :-(

Cheers,
Michael

Attachment: bugfinder-plotcwnd.cc
Description: Binary data

Attachment: bugfinder.cc
Description: Binary data

Attachment: run_bugchecker_loop.sh
Description: Binary data

Attachment: wafrun.sh
Description: Binary data