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 <garmit...@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-unsubscr...@freebsd.org" > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
