ath / 802.11n performance issues and timer code

[Adrian Chadd]

On 24 September 2011 13:13, Alexander Motin <mav at freebsd.org> wrote:

> 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.

What about possible effects on the scheduler?
Is it possible that once the interrupt handler has completed, the
taskqueue thread isn't scheduled immediately,
and isn't scheduled until the next tick?

>>> 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.

> 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.

Nope, it has the opposite effect:

* Increased latency may make aggregation better (for TX) but it limits
throughput because TCP senses a latency increase;
* Increased latency means that RX overflows occur beacuse the rx
thread doesn't get queued until quite a bit later in the future.

> 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.

Ok. The most obvious issues occur on embedded mips boards, so I'll
have to do some tinkering to get this to work.


Adrian