[Bloat] testing different TCP congestion control algorithms via netperf-wrapper

[Bloat] testing different TCP congestion control algorithms via netperf-wrapper

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

I just checked an attempt at testing reno_westwood_cubic_ledbat into
toke's netperf-wrappers/tests repo. I guess it would be good to have
some error checking to detect if we have those algs installed on both
ends...

Attached is a test against localhost on my linux 3.6 based machine
(pfifo_fast) See how "slow start" is crazy! That makes some sense, but
the other data doesn't.

I am hoping I've merely misconfigured the test given the
upload/download disparity, particularly with ledbat. (the ledbat code
is out of tree and perhaps needs modification given "tcp small
queues"? (https://github.com/silviov/TCP-LEDBAT)

and

From what I understand from mentally parsing netperf's examples/runemomni*

      netperf $HDR -t omni -c -C -H ${remote_hosts[$client]} -l
$length $confidence -- $CSV -H ${remote_hosts[$client]} $socket_sizes
-m 64K -u $NETUUID & HDR="-P 0";

....

      netperf $HDR -t omni -c -C -H ${remote_hosts[$client]} -l
$length $confidence -- $CSV -H ${remote_hosts[$client]} $socket_sizes
-M ,64K -u $NETUUID & HDR="-P 0";
      j=`expr $j + 1`;
    done;
    wait;

-M ,64k is the equivalent of TCP_MAERTS ?
and -m 64K is the equivalent of TCP_STREAM ?

except that they are sending 64K at a time. Given that we are sending
data sometimes at very low rates (384k on adsl),
does it make sense to drop this figure to something lower?


-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: congest.ps --]
[-- Type: application/postscript, Size: 123533 bytes --]

[-- Attachment #3: congest_avg.ps --]
[-- Type: application/postscript, Size: 48977 bytes --]