Date: Thu, 23 Apr 2015 13:43:11 +0300 From: Karlis Laivins <karlis.laivins@gmail.com> To: grenville armitage <garmitage@swin.edu.au> Cc: freebsd-net@freebsd.org Subject: Re: Testing Congestion Control Algorithms Message-ID: <CAF4H_7=5hV6iPJw=erTjir9ExDCBQcFRySdfHYQ=E570WipxoA@mail.gmail.com> In-Reply-To: <5538BF47.4000803@swin.edu.au> References: <CAF4H_7m0mUeHMCEPoXycJAHYXqqvvH3KaFZdH0c%2BpTsJnzUxwg@mail.gmail.com> <5538BF47.4000803@swin.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Thank you very much for this suggestion! I will try to build the testbed and use the tool suggested by you. Best Regards, Karlis On Thu, Apr 23, 2015 at 12:45 PM, grenville armitage <garmitage@swin.edu.au> wrote: > > > On 04/23/2015 17:17, Karlis Laivins wrote: > >> Hi, >> >> I am currently working on a modification of TCP NewReno congestion control >> algorithm. It seems that I have been able to write a working module. >> >> Now, I am looking for a way to test the performance of the built-in >> congestion control algorithms and the new algorithm. I have heard about >> the >> NS-2 simulator, and I am trying to compile and configure it now, but >> that's >> just a statistical tool (from what I hear) and the results are far from >> reality (please correct me, if I am wrong). >> >> Please recommend a tool or way I can test the performance of the >> congestion >> control algorithm in a "real" environment (sender side - 2 Computers, one >> connected to the wireless network, other to a wire, receiver - one PC, >> running FTP server, both senders each sending a big file at the same >> time). >> I would like to get comparable performance results from each of the >> existing congestion control algorithm as well as the new one I have >> created >> by modifying the NewReno algorithm. >> >> Thank you in advance for your assistance. >> > > Lars is right, the ns-2 tangent is starting to diverge from freebsd-net@ > > Indeed, I would suggest you don't bother with ns-2 -- it wont help you do > meaningful comparisons to a kernel-resident cc module you develop under > FreeBSD. > > If you have the time and inclination to build a small testbed using a > couple of physical hosts, you might find this tool useful -- > http://caia.swin.edu.au/tools/teacup > > My colleague and I built TEACUP (TCP Experiment Automation Controlled > Using Python) to automate many aspects of running TCP performance > experiments in our small, specially-constructed physical testbed. TEACUP > enables repeatable testing of different TCP algorithms over a range of > emulated network path conditions, bottleneck rate limits and bottleneck > queuing disciplines. (e.g. I've used it to experiment with custom FreeBSD > CC modules vs conventional FreeBSD and Linux CC algorithms.) > > A key caveat: TEACUP assumes your physical testbed is a > multi-host/single-bottleneck dumbbell-like topology with suitably > configured end hosts and Linux-based bottleneck router (see > http://caia.swin.edu.au/reports/150210C/CAIA-TR-150210C.pdf for an > example). TEACUP does not try to run experiments over arbitrary network > paths or the wider Internet. This has satisfied our use-cases, other > people's mileage may vary :-) > > We've released TEACUP in case it may be useful to other researchers who > already have (or are interested in setting up) similar network testbeds. > > (Small note -- we recently found a small bug in some of the v0.9 data > analysis code, which will be fixed when v0.9.2 comes out RSN.) > > cheers, > gja > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF4H_7=5hV6iPJw=erTjir9ExDCBQcFRySdfHYQ=E570WipxoA>