On Oct 15, 2013, at 5:15 AM, Anton Matsiuk <anton.mats...@gmail.com> wrote:
> Dear Murphy, > I am experiencing problems with large delays in processing Packet_In messages > on input in POX. > For testing the performance I use 2 different schemes: > · Mininet 2.0 with single Open vSwitch running in kernel (Ubuntu > 13.04) and 2 hosts connected to it. Testbed machine is Core i7 with 8GB RAM. > · With standalone hardware switch (NEC PF) and 2 hosts connected to > it and POX, running on Debain. > I tested it with forwarding.l2_learning l2_pairs and simplified L2 learning > (derived from tutorial) modules on betta and carp releases. On betta I tested > it both with Cpython and pypy interpreters (with carp I get errors while > trying to run it on pypy). I'd really like to fix these errors. Are they easy to replicate? If your carp is up to date, can you send me a report/stack trace/whatever? > In all tests I measure the delay between timestamp when Packet_In appears on > IP interface (dedicated loopback in case of Mininet and separate Ethernet > port in case of hardware switch) and timestamp when it fires Packet_In event > in l2_learning controller. In all schemes and cases this delay is about 15ms > in average (but with large deviation from 2 ms to 50ms). > The processing of Packet_In and construction of packet_out (or Flow_mod) in > response on Packet_In (all just for L2 rules) takes 0.3ms and sending > Packet_Out (or Flow_Mod) out of controller (till appearance it on > IP-interface) also takes about 0.3ms. > Such large delay of Packet_In while entering POX causes the RTT of ping > between two test hosts to increase up to 50-100 ms when hard timeout of flow > rules expires (instead of 0.15ms with rules installed in the switch). There > are no other intermediate devices between switch and POX, in both schemes > they have direct IP-connectivity. > > I measure the delay as difference of timestamps in wireshark and in different > parts of the code of controller. > That’s why I am asking. Is such delay while listening for Packet In normal > for POX? Or is there any ways to reduce it? I expect that overall response of > POX for installation of Flow_Mod or just sending Packet_Out should be around > 1ms in case of simple L2 rule installation. Yes, it's normal. Optimizing reactive use cases hasn't been a priority. But we've actually wanted to address the cause that underlies the delays you're seeing for other reasons anyway. I've put an experimental patch in the dart branch (surprise; there's a dart branch). Run with ./pox.py --unthreaded-sh to enable it. I think you'll probably see an improvement. -- Murphy
