On 24.09.2011 04:13, Adrian Chadd wrote: > On 24 September 2011 05:38, Alexander Motin <mav_at_freebsd.org> wrote: >>> When I set kern.eventtimer.periodic=1, the 11n TX/RX performance >>> suddenly jumps to where it should be. >>> >>> Would you mind helping me figure out what the problem is? >> >> I would be glad to help, but at this moment I am not sure how network >> traffic related to timer. May be wireless has some specifics, but for >> wired adapters traffic processing happens on network interrupts. > > Well, here the interrupt handler just sets up some deferred tasks to > run via taskqueue_schedule(). > This isn't the only driver which does this - I think the gige/10gige > NICs also do this. OK, but how taskqueue related to the timer? Taskqueue uses SWI that are called in separate thread and except "swi4: clock" AFAIR they are not anyhow related to the timer. >>> I didn't think kern.eventtimer.periodic was needed? >> >> It should not be needed. >> >> Have you tried to set kern.eventtimer.idletick=1 instead? > > I just tested it - it has the same effect. Interesting. So either it is what I've described below (but it's strange, I have doubt it may consume so much time, at least I haven't seen it on x86), or network traffic is still somehow depends on timer events and timer events are delayed more then needed. >> kern.eventtimer.periodic=1 on UP system effectively includes >> kern.eventtimer.idletick=1. kern.eventtimer.idletick=0 may somewhat >> increase interrupts overhead due to need to reprogram timer before >> context switch, but under high interrupt rate (about few KHz) kernel >> should dynamically switch to "quick" mode skipping it. > > The clock rate interrupt difference is quite startling - at 150mbit > 11n bridging (from wlan0 -> arge0 wired) the clock interrupt rate is > around 300/sec for idletick=0, and about 1150/sec for idletick=1. The numbers themselves look fine. 1150 int/sec should mean 1000 of hz and 127 of stathz. Lower rate with idletick=0 means that eventtimer subsystem is dropping some timer ticks. > The other thing to keep in mind is that the wlreless NIC isn't > interrupting per RX or TX completed packet. So although I'm doing ~ > 19,000 pps, it's only interrupting me ~ 390 times a second. So low interrupt rate means large queuing, that should make bandwidth even less affected by side influences. Can you try to build kernel with KTR_SPARE2 KTR and send me a trace when the traffic flows. I would like to check whether timer events are generated close to a proper time. -- Alexander MotinReceived on Sat Sep 24 2011 - 03:14:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC