Dear Murphy, commenting out log messages decreases the latency by 0.03 ms (in average and obviously it depends on number of log.messages).
As I understood unthreaded_sh option turns off multithreading in scheduler and in this case I can't create my own recoco loop task? I need a task which will perform operations on packets in infinite loop (with lowest priority) which have to be interrupted by packet_In and flow_mod async events. OpenFlow_01_Task should have highest priority (I am not sure about prioritization mechanism in recoco Scheduler, but anyway controller should react on async incoming packets as soon as possible) Can I implement it with recoco Task() or alternatively with usual python threads with unthreaded_sh option enabled? On 16 October 2013 21:21, Murphy McCauley <murphy.mccau...@gmail.com> wrote: > 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 > > > -- Best regards, Anton Matsiuk
