MT-Cbench is an extended version of Cbench emulator
which uses threading (Posix threads) to generate OpenFlow traffic from multiple streams
The motivation behind this extension is to provide the ability for booting-up
and operating network topologies with OpenDaylight, much larger than those being
able with the original Cbench traffic generator. The problem with the original
Cbench is that, large number of switches (e.g. 200) cannot be connected to the
OpenDaylight controller large at once, without causing the controller to crash.
Even though original Cbench offers command line options for group-wise switch
addition, with configurable delays between groups, these options did not help
with OpenDaylight, because early-added switches were not able to respond to
initialization messages while the boot-up process for the remaining switches was
still ongoing. For this reason a multi-threaded implementation has been
resorted, which makes switches owned by different threads independent from each
other and therefore responsive to controller requests.
Our initial results show that we can boot-up topologies of 5000 switches,
and perhaps more.
Multithreaded execution: the user can specify a configurable number of
threads to launch with MT-Cbench, each emulating the same number of switches.
In this way we can efficiently leverage multi-core architectures to scale the
amount of generated traffic with the number of cores.
Delay between thread creation (i.e., group-wise switch addition): the user
can specify the delay between thread creation. This means that switches will
connect to the controller in batches, with a specific delay between each batch.
In this way large topologies can be connected gradually to the controller,
while fine-tuning how they will connect, something not being possible with
standard Cbench. Each thread created does not pause its execution while other
threads are in line for creation, and therefore remains responsive to
Delay between traffic initiation: after all threads have been launched
and have created their switches, they sleep for a configurable delay before
starting sending traffic. This delay is configurable, and makes possible
test scenarios such as idle tests.
The command line options supported by MT-Cbench are:
--total-threads): total number of MT-Cbench threads
--switches-per-thread): total number of switches per thread
--delay-per-thread): delay between creation of consecutive threads.
This flag allows gradually connecting topologies to the controller.
--delay): delay starting traffic transmission
--debug-threads): enable thread-level debugging
--debug): enable debugging
--controller): controller hostname or IP address
--port): controller port for switches to connect to
--mac-addresses): unique source MAC addresses per switch
--loops): internal iterations per test
--ms-per-test): duration of an internal iterations (in msec)
--throughput): use generator in "throughput" mode
--warmup): number of initial internal iterations that should be
treated as "warmup" and are not considered when computing aggregate
--cooldown): number of final internal iterations to be disregarded
--learn-dst-macs): send gratuitious ARP replies to lean destination
macs before testing
In addition to thread related messages, the output of MT-Cbench is the same as
the original Cbench. As described in the code design
page, this is an essential requirement for the tests of NSTAT to be compatible
The figure below demonstrates MT-Cbench execution flow. During initialization,
threads are created one-by-one, with delay between them (
initialization and before traffic initiation threads sleep for a specific delay
-D). At the end of each internal iteration threads synchronize into a
barrier, so that partial measurements can be aggregated and reported by a single