The Realtime Response Under Load (RRUL) test suite specification is an attempt to provide useful tools for analyzing network performance under the heavy workloads that typically induce bufferbloat and other networking problems. By creating a well defined specification we hope to one day create a standard for network testing that is a vast improvement on what currently exists in the field, which is mostly “packets per second” and “raw bandwidth” testing.
A rrul prototype is being developed as part of the Flent tests. As the title suggests, the tests are being wrapped around the popular netperf netperf network analysis tool. Requirements are a recent version of netperf, python, matplotlib, python-matplotlib, and fping.
It does your classic latency under load tests in a variety of ways, and
provides output data in json format, with plots in CDF (very helpful)
and combination format. For an explanation of the charting techniques
see the RRUL charting methods page, and/or the RRUL Rogues Gallery for some example plots.
rrul: an 8 bidirectional stream test against icmp and udp traffic, that
uses classification to attempt to exercise qos queues such as those in
rrul_be: The same test as rrul, but without classification - the fairest test at all
rrul46compete: the same test, but using ipv4 and ipv6 at the same time
rtt_fair: test tcp performance between two or more hosts to see if a system is RTT-fair (meaning that connections to machines at different distances eventually or not get a fair share of the bandwidth)
reno_cubic_westwood_ledbat: test performance of different TCPs (if enabled on both systems) in the same test
There are also some simpler tests in the suite currently:
tcp_bidirectional: a basic test intended to give a “textbook” result of
two competing streams against a ping
tcp_upload: test multiple tcp uploads against a ping
tcp_download: test multiple tcp downloads against a ping
A core component of the specification includes measuring one-way delays,
while under load. Measuring this well is very important for voice and
gaming traffic as well as shorter transactions. We will probably write
something new or adopt
d-itg for that.
Another core component is measuring typical web workloads, while under
And the last component is a tcp traceroute or mtr, showing the source(s) of the bottleneck(s) affecting the test(s).
Early versions are targetted at:
At some point (after the bugs are sorted out), a web driven version suitable for end-user testing at the edge will be developed, similar to speedtest.net.
As the available resources and funding for developing even this first part of the test suite are slim, getting to the end result will take time and resources we do not have.
rrul tests are all over the web at this point… google for them.