Gerrit, It was my fault for using the TFRC throughput page and not changing delayed acks from 2 to 1 which is used in RFC3448 (and our code) as the default. I've gone and corrected my figures. I'm now within 1% of your figures - I think this is rounding error from bc but not 100% sure. I've attached the spreadsheet I used for verification which matched Perry's page.
The scripts are all on that page at http://linux-net.osdl.org/index.php/DCCP_Testing#netem and loading CCID3 at http://linux-net.osdl.org/index.php/DCCP#Choosing_and_initialising_your_CCID Maybe I have not worded it well? If not please feel free to improve. Regards, Ian On 6/25/07, Gerrit Renker <[EMAIL PROTECTED]> wrote:
Ian - | Results here now: | http://linux-net.osdl.org/index.php/DCCP_Testing#Regression_testing many thanks indeed for working out these test cases and reference points. Testing is really very much needed at this stage and the input is helpful. The test setup is very useful and I am strongly in favour of using http://linux-net.osdl.org/index.php/DCCP_Testing#Regression_testing as a kind of benchmark for all further development on the test tree - to see whether results deteriorate. If you have links to scripts you use that would be great. I am getting confused by Perry's throughput calculator. Attached is a simple bc(1) script which can be made executable and takes s, R, p. I get different results from the ones on the web page (using 1424 bytes): * for the 150ms / 10% case, I get Xcalc = 132.44 Kbits/sec and * for the 40ms / 1% case, I get Xcalc = 3.27 Mbits/sec But this may likely be due to using slightly different `s' and rounding errors; for live testing it is reasonably close.
-- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group
xcalc.sxc
Description: OpenOffice Calc spreadsheet
