Just to summarize some off-list conversation: --unthreaded-sh makes a pretty big difference; reducing the measured time from 15ms to 0.2ms on CPython. PyPy does slightly worse but is still far better than before.
The PyPy issue with carp was actually resolved a couple of days ago. -- Murphy On Oct 15, 2013, at 11:58 AM, Murphy McCauley <murphy.mccau...@gmail.com> wrote: > 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
