Re: ath / 802.11n performance issues and timer code

On Monday, September 26, 2011 10:10:27 am Adrian Chadd wrote:
> 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 meant do the timer settings affect UDP performance?  I.e. does idletick=1
change UDP performance at all?

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

No, that scheduling is synchronous.  Anytime a thread is scheduled the
scheduler will check if it should preempt the current thread to run the
new thread.

-- 
John Baldwin