Thank you for the extensive information :) I'm trying to run with pypy but it can't import some of my modules (all in the /pox directory). For example myrouter.mylinkmonitor does not work, but my myrouter.mypackethandler does.
python pox.py <modules> works like a charm ./pox.py <modules> cannot find all modules <path>/pypy pox.py <modules> has the same problem as the latter It's probably something silly, but I can't find it... Concerning the number of packet_in events. It's about 10 per second (+ about 10 stats_requests and replies, which are logged by a separate module). 2013/3/19 Murphy McCauley <murphy.mccau...@gmail.com> > On Mar 19, 2013, at 9:53 AM, Tmusic wrote: > > > I haven't tried to run it with PyPy. The main reason is that performance > of more than an order of magnitude below what I need, which lead me to > investigating the bottlenecks first. > > Might be worth trying anyway just to collect a datapoint (i.e., how > different are your results). > > > My guess is that the profiler only looks at the main thread (since I'm > seeing almost only init and sleep). > > Can you give some more information about the different threads? > > Which components are you running? > > > I'm seeings 5 thread (poxdesk is running): > > - Main thread (boot / init) > > Yeah. This one is sort of "reserved". In Python, signals are only > delivered to the main thread. So you can think of the main thread as the > "signal thread". Usually it just sleeps and catches signals meant to kill > the process and handles them. It can also be used for various things that > demand to be on the main thread (like tkinter, which probably demands this > because of signals, but I am guessing). > > > - Webserver? > > Possibly, if you're running the web module. > > > - Two threads running recoco (What is the difference?) > > One of these is the actual cooperative thread that actually schedules and > runs Tasks. > The other is a select-based IO loop. When there's IO waiting, it > schedules tasks on the cooperative thread. It sleeps except for that. > > This design is to support additional IO loops (besides just the select > one) with nothing special about any of them. In practice, this has rarely > been used. The debugger branch actually merges the select IO thread and > the scheduler. This is a compromise of the design, but it's very practical > and will eventually get some level of support in the mainline. > > > - Socket thread? > > Maybe a deferred sender thread to keep sends from blocking. This is sort > of a hack, but it's very rare that it actually runs. > > > Maybe I should explain more clearly what is happening: > > When the controller becomes under more stress, the link discovery > modules throws a timeout. Immediately afterwards it fires a link discovered > event. I thought this was caused by the fact that the LLDP packets are > delayed to much in the scheduler. Can this be the case? > > Do you have a whole lot of packet_ins? > > > However the time needed to install new flows (based on packet_in events) > does not seem to change, which makes me think it is a discovery specific > issue. Changing the delay times in discovery module only has a minor > impact. Any ideas? > > Try sending barriers and seeing how long they take to come back. > > -- Murphy
