[pox-dev] capacity of POX

[Murphy McCauley]

I've tested it with many hundred in the past using a modified cbench.  It's easier now, since POX contains its own OpenFlow switch.  I just ran:
#!/bin/bash

for I in $(seq 1 300); do
  ./pox.py datapaths:softwareswitch &
done

The controller does stop somewhere around 250 connections, which would be highly suspicious due to its proximity to 256, but in my case, the problem was clearly visible in the log:
ERROR:openflow.of_01:Exception reading connection <socket._socketobject object at 0x10e009d00>
Traceback (most recent call last):
  File "/Users/murphy/proj/pox_dart/pox/openflow/of_01.py", line 905, in run
    new_sock = listener.accept()[0]
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 202, in accept
error: [Errno 24] Too many open files
ERROR:openflow.of_01:Exception on OpenFlow listener.  Aborting.

POX has run out of file descriptors and the resulting error has caused the OpenFlow loop to abort.  I set it larger using ulimit (500 was the largest I could get without changing the system config), and could now get almost 500 connected.


Did you not get this log message?  As the FAQ says, posting the log can be very useful.  You also don't really describe what you mean by "freeze", though it may be hard to tell.  For example, if the OpenFlow loop aborted, POX would appear to freeze as far as OpenFlow was concerned, though timers and other components would continue to run.

It's not clear why setting the connection rate to two per second would help if the problem was running out of file descriptors unless this led to some of the switches disconnecting (or being disconnected due to idle)... which might be obvious from reading the log.


At any rate, aborting the OpenFlow loop when out of file descriptors is probably just not the right thing to do.  I've pushed a fix to dart.

-- Murphy

On Nov 30, 2013, at 12:31 PM, Nan Zhu <zhunanmcgill at gmail.com> wrote:

> Hi, 
> 
> Do anyone has some experimental result about the pox capacity in terms of concurrent connection number?
> 
> I wrote some software-defined openflow switch (partially implement the openflow protocol, except the packet counters and queues), each switch is a in-memory object which can connects to the pox and send openflow messages, 
> 
> 
> it works well when the number of "openflow switches" is small. however, when I create as many as 320 switches, the pox controller freeze after it processed connectUp for nearly 250 switches
> 
> I controlled the connection rate as 2 connectionup per second, it backs to the normal
> 
> anyone has the similar experience?
> 
> Best,
> 
> Nan