On Oct 22, 2013, at 2:08 AM, Anton Matsiuk <anton.mats...@gmail.com> wrote:
> In case of PyPy turning off logging decreases the latency by 0.06 ms (two > times larger than with CPython). > By the way, standard deviation of latency with PyPy much greater in all test > (around 30 times higher) than with CPython. > > Regarding task implementation: > With usual Python threads it works, thanks! I want to try it implement with > separate recoco task in order to measure the performance and to decide which > to use for further implementation. > If I create EventLoop(Task) can I interrupt its infinite (while > core.running) loop (which performs non-blocking operations) from main Task > (by arriving of Packet_In in my case) So, I mean, is there analog of > threading.Event() in recoco or have I manually schedule execution and pass it > between tasks in this case? There's no way to interrupt a cooperative Task -- the Task itself has to decide to give up control. It could do this by just yield Sleep()ing regularly. If there's nothing else running, it should just get scheduled again. Depending on what you're doing, there's a little recoco producer/consumer example in lib/recoco. I've also pushed an example of implementing a Lock in recoco to dart. With a little work, this could be turned into an Event. Though again, there's no real interrupting here -- the infinite task would need to give up control periodically to let other tasks (like the OpenFlow task) run. Hope some of that is helpful. :) -- Murphy > On 21 October 2013 20:43, Murphy McCauley <murphy.mccau...@gmail.com> wrote: > On Oct 21, 2013, at 4:58 AM, Anton Matsiuk <anton.mats...@gmail.com> wrote: > >> commenting out log messages decreases the latency by 0.03 ms (in average and >> obviously it depends on number of log.messages). > > Thanks for reporting this. Was this on PyPy? That's where I'd expect the > biggest win to be -- the inefficiency of the logging module on PyPy is a > known. > >> 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? > > Either of these should still work. Modulo bugs, --unthreaded-sh will > hopefully not make any difference to anyone, really. It'll probably become > the default. > > With a Task, note that you must explicitly give up control periodically > (since they're cooperative). If that's not feasible, you should use a > Thread. Or, if appropriate, use an entirely separate process (which > eliminates the Python GIL constraint). > > -- Murphy > >> 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 > > > > > -- > Best regards, > Anton Matsiuk
