Re: ath / 802.11n performance issues and timer code

From: Alexander Motin <mav_at_FreeBSD.org>
Date: Sat, 24 Sep 2011 08:13:36 +0300
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 Motin
Received 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