On a sidenote, it might be useful to benchmark both against TCP and UDP flows. TCP handshake is more friendly with pkt-ins on the reactive scenario. (This assumes that ovs doesn't do any optimization with multiple pkt-ins belonging to the same flow, which I don't know whether is true or not).
Regards, Y. On Tue, May 24, 2011 at 5:17 PM, David Erickson <[email protected]>wrote: > 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 >
_______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
