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). 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. -- Best regards, Anton Matsiuk
