As Ben mentioned, there are also a few posted benchmarks for NOX and other controllers using cbench (part of the Oflops package) here: http://www.openflow.org/wk/index.php/Controller_Performance_Comparisons

-David

On 05/24/2011 12:52 PM, Ben Pfaff wrote:
So you're using Open vSwitch?  What version?

There shouldn't be any need to use an external tool to analyze
OpenFlow traffic to and from Open vSwitch.  You can just turn up the
log level of the "vconn" module, e.g. "ovs-appctl vlog/set vconn".
You can also use "ovs-ofctl snoop<bridge>" as an alternative.

If your primary goal is to find the limits of the NOX controller,
there is already a benchmark utility for that:
        http://www.openflow.org/wk/index.php/Oflops

You might want to turn off packet buffering in the switch.

On Tue, May 24, 2011 at 09:35:17PM +0200, Jose Luis Franco Arza wrote:
Thank you for your answer Ben,
The idea is to test the NOX controller and see how many flows per second can
be handled. Imagine a situation in a data center where lots of flows are
sent per second, could the NOX controller handle them and install them
all?This is one of the objectives of this tests, find the limits of the NOX
controller to handle the packets income in the control channel.
The version of OpenFlow that i'm using is the 1.0 provided with the
OpenVSwitch and in the NOX controller, the 0.6. I was thinking that one of
the reasons of this packets loss could be that when the rate is high and the
OpenFlow has to send every single packet to the controller then the number
of packets queued in the switch increases till a point where they are
dropped, but the only tool I found to check the number of packets queued is
this oftrace command.


2011/5/24 Ben Pfaff<[email protected]>

On Tue, May 24, 2011 at 08:47:05PM +0200, Jose Luis Franco Arza wrote:
I am an doing some scalability testings for my Master Thesis related to
OpenFlow. One of the aims is to obtain a limitation in the number of
flows
per second that the NOX controller can install. Using an UDP packet
generator and sending packets in a UDP ports range (each port corresponds
to
a new flow) I have been trying to obtain a limit for the number of flows
installed in the flow table and how many flows per second can be
installed
obtaining a good performance in the network.

If your goal is scalability, I doubt that sending the first packet of
every flow up to the controller is a good way to achieve it.  Your
network will scale better if you proactively install flows, reducing
the need to send traffic to the controller.

You didn't say what version of OpenFlow you had installed, but it may
not make sense to use the OpenFlow reference implementation for
scalability testing.  I don't think it's designed for performance but
rather for simplicity.


_______________________________________________
openflow-discuss mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss

_______________________________________________
openflow-discuss mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss


_______________________________________________
openflow-discuss mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss

Reply via email to