Date: Mon, 26 Sep 2011 10:53:30 -0400 From: John Baldwin <jhb@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Alexander Motin <mav@freebsd.org>, freebsd-current@freebsd.org Subject: Re: ath / 802.11n performance issues and timer code Message-ID: <201109261053.30410.jhb@freebsd.org> In-Reply-To: <CAJ-Vmom721ndMmSihA=58Fux-JBWHo1rA82FXYa__mmaRMW=tQ@mail.gmail.com> References: <CAJ-VmomZyDJV62yCQOvG=UB6H4wfz9=3_cWzEL7vWAA14TCyYA@mail.gmail.com> <201109260917.44236.jhb@freebsd.org> <CAJ-Vmom721ndMmSihA=58Fux-JBWHo1rA82FXYa__mmaRMW=tQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, September 26, 2011 10:10:27 am Adrian Chadd wrote: > On 26 September 2011 21:17, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201109261053.30410.jhb>