The Good, the Bad and the WiFi: Modern AQMs in a Residential Setting
This web site contains the data files and test scripts for the paper “T. Høiland-Jørgensen et al. The Good, the Bad and the WiFi: Modern AQMs in a Residential Setting, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.07.014”.
The tests are run in a controlled environment consisting of five regular desktop computers, equipped with Intel 82571EB ethernet controllers, and networked together in a daisy-chain configuration, corresponding to a common dumbbell scenario (here multiple senders correspond to the individual flows established between the endpoint nodes). The middle machine adds latency by employing the dummynet emulation framework. The bottleneck routers employ software rate limiting (through the tbf rate limiter) to achieve the desired bottleneck speeds. The test computers are set up to avoid the most common testing pitfalls, as documented by the bufferbloat community best practices document.
This means that all hardware offload features are turned off, to allow all packet handling to happen in the kernel. Furthermore, the kernel Byte Queue Limits have been set to a maximum of one packet, and the kernel is compiled with the highest possible clock tick frequency (1000 Hz). The purpose of both of this is to eliminate other sources of latency and queueing than those induced by the queueing disciplines themselves, and also to prevent the network driver and hardware from skewing the results by queueing packets outside the control of the queue management algorithms. The testbed computers’ clocks are kept in sync by running the Precistion Time Protocol over the control network.
For all tests, the default Linux CUBIC TCP implementation is used. For the WiFi test, the laptop marked ‘WiFI client’ serves as the test client. The laptop is equipped with an Intel WiFi Link 5100 using the iwlwifi driver, while the access point is a Ubiquiti Nanostation M5 equipped with an AR7241 WiFi chipset using the ath9k driver.
A recent version (2.6 or newer) of
Netperf is required for most tests. For
the VoIP tests,
D-ITG is used,
run through the
ditg-control-server.py script included with the Flent
sources. A small patch to D-ITG is required for this to work; that is
also included with the Flent sources. For running the HTTP tests, the
http-getter client is used.
The following files contains the Flent data files for all tests:
- data-files.tar.gz (2.7 GiB; sha1sum f084ac08e401d664d551db1b313a51cc8e03e5d1).
- data-files-wifi.tar.gz (303 MiB; sha1sum d24efcf2466ec9fa78424f57fbfa8b0c7a3517a9)
Packet dumps are available for the wired tests, captured at different vantage points in the test setup.
Each file contains dumps (first 128 bytes for each packet) for one test. The file names correspond to the test file names in the file above, with a host name appended, and a .cap.gz extension. The host names are as follows:
|tohojo-testbed-02||Upstream bottleneck router|
|tohojo-testbed-04||Downstream bottleneck router|
- batch-2014-10-02T153111-testbed-01.tar.gz (145 GiB; sha1sum 53ed1e54b05700036aae28437ec3c9a0caa79b26)
- batch-2014-10-02T153111-testbed-02.tar.gz (163 GiB; sha1sum 9d8b56a36c17d58423b33a7849d31ee37ba2de8f)
- batch-2014-10-02T153111-testbed-04.tar.gz (161 GiB; sha1sum d16494a94f80744f55d3afc5aa269bfb4c6daa9b)
- batch-2014-10-02T153111-testbed-05.tar.gz (152 GiB; sha1sum 954b09bf667dc8bf6bfd7a71304ac6717aff45b1)
This page written and maintained by Toke Høiland-Jørgensen. Questions, comments, etc. are very welcome on toke DOT hoiland-jorgensen AT kau DOT se.