Date: Fri, 24 Apr 2015 08:22:13 +1000 From: grenville armitage <garmitage@swin.edu.au> To: freebsd-net@freebsd.org Subject: Re: Testing Congestion Control Algorithms Message-ID: <55397095.3040700@swin.edu.au> In-Reply-To: <CAF4H_7mVTXxuvFnotYA4Afis5wb0ayiWcumCDjDeTeLNLR_2NA@mail.gmail.com> References: <CAF4H_7m0mUeHMCEPoXycJAHYXqqvvH3KaFZdH0c%2BpTsJnzUxwg@mail.gmail.com> <5538BF47.4000803@swin.edu.au> <CAF4H_7mVTXxuvFnotYA4Afis5wb0ayiWcumCDjDeTeLNLR_2NA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is veering somewhat off tangent for the freebsd-net list, but... On 04/23/2015 21:15, Karlis Laivins wrote: > Hello once again, > > Before I dive in the TEACUP, I wanted to clarify this - should I build the > testbed to consist of FreeBSD machines, will I be able to use congestion > control module (.ko) that was created by modifying the cc_newreno (written > in C) in TEACUP, or will I have to rewrite it in Python? Short answer: TEACUP doesn't implement CC algorithms per se. It focuses on controlling all the data generation & capture tools, end hosts and bottleneck to start/log/stop TCP performance tests using whatever CC algorithm you select. You will need to copy-paste-edit about 5 lines of TEACUP's python code so TEACUP will recognise and kldload your new module on your FreeBSD end hosts. For the long answer -- ping me offlist. > Sorry, if this question seems silly, but I have limited time to do the > tests and I want to be sure that I don't have to redo something in a > language that I haven't used yet. TEACUP takes a bit of time to set up the end hosts and bottleneck router with the right tools. But once you have it running you'll be able to iterate across a range of TCP and path parameters quite efficiently. cheers, gja > > Thank you in advance for your answer! > > With 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" >> > _______________________________________________ > 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" > -- Professor Grenville Armitage Centre for Advanced Internet Architectures School of Software and Electrical Engineering Faculty of Science, Engineering and Technology Swinburne University of Technology, Australia http://caia.swin.edu.au/cv/garmitage
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55397095.3040700>