Re: ath / 802.11n performance issues and timer code

On 26 September 2011 21:17, John Baldwin <jhb_at_freebsd.org> wrote:
> On Sunday, September 25, 2011 5:48:31 am Adrian Chadd wrote:
>> Nope, it has the opposite effect:
>>
>> * Increased latency may make aggregation better (for TX) but it limits
>> throughput because TCP senses a latency increase;
>
> I suspect this matters more.  Have you tried comparing UDP throughput in the
> two cases?

Yes, UDP performance from the MIPS boards (running iperf) is just
plain silly and low.

It's better from the i386 based eeepc (I can get around 200mbit before
things croak it, but I _should_ be able to schedule ~ 250mbit with
maximum aggregation and no airtime errors / retries, which I _can_
achieve in controlled conditions.)

I haven't yet dug into that. It may be related.

> One behavioral difference of a periodic timer vs a deadline timer is that if
> you ask to delay for "1 clock tick", that can be anywhere from 0us to 1000us
> (with hz == 1000) when using the periodic timer (because you can set the
> callout at any time within a tick, but the callout will fire at the start of
> the next tick).  However, for a deadline timer, the TCP timer will always fire
> 1000us after you set the timer.

Right. Hm, what about scheduling in general though? Ie, if I'm
scheduling a taskqueue run, the taskqueue caller does:

* lock queue
* schedule next task queue
* call wakeup_one

Which should wake up a/the taskqueue thread in question and have it
immediately run the next task on the queue. The taskqueue doesn't have
any form of timer/callout; it's just a "submit this to get run." When
will it be run? I hope not at the next tick, not if the CPU is free.


Adrian