Date: Sat, 24 Sep 2011 08:13:36 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: ath / 802.11n performance issues and timer code Message-ID: <4E7D6700.4080302@FreeBSD.org> In-Reply-To: <CAJ-Vmom_EkGCe4vA04B4Z1gkVGoybndSwEC78WKFReDMV=picw@mail.gmail.com> References: <CAJ-VmomZyDJV62yCQOvG=UB6H4wfz9=3_cWzEL7vWAA14TCyYA@mail.gmail.com> <4E7CFC42.8000409@FreeBSD.org> <CAJ-Vmom_EkGCe4vA04B4Z1gkVGoybndSwEC78WKFReDMV=picw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24.09.2011 04:13, Adrian Chadd wrote: > On 24 September 2011 05:38, Alexander Motin <mav@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 Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E7D6700.4080302>