Re: poor performance with ath5k; reverting to ath_pci

["John W. Linville" <linville@tuxdriver.com>]

On Wed, Jan 21, 2009 at 08:33:01PM +0100, Stefanik G=E1bor wrote:
> On Wed, Jan 21, 2009 at 8:11 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > On Wed, Jan 21, 2009 at 07:22:14PM +0100, Stefanik G=E1bor wrote:
> >> On Wed, Jan 21, 2009 at 4:14 PM, John W. Linville
> >> <linville@tuxdriver.com> wrote:
> >> > On Tue, Jan 20, 2009 at 10:38:08PM -0500, Glenn Burkhardt wrote:
> >> >> On Friday 16 January 2009 10:33:13 Bob Copeland wrote:
> >> >> > On Thu, Jan 15, 2009 at 5:34 PM, Glenn Burkhardt
> >> >> >
> >> >> > <gbburkhardt@verizon.net> wrote:
> >> >> > > ath5k_pci 0000:00:07.0: PCI INT A -> GSI 18 (level, low) ->=
 IRQ 18
> >> >> > > ath5k_pci 0000:00:07.0: registered as 'phy0'
> >> >> > > phy0: Selected rate control algorithm 'pid'
> >> >> >
> >> >> > Can you change the rate control algorithm to minstrel and ret=
ry?
> >> >>
> >> >> I built a 2.6.28.1-9 kernel to get the minstrel code for ath5k.=
  The
> >> >> kernel for Suse 11.1 is 2.6.27.7-9.  But that means that more c=
ould have
> >> >> changed besides the rate control code.
> >> >>
> >> >> It looks like minstrel and pid give about the same result, a bi=
t worse that
> >> >> the ath_pci driver right now.  Performance seems to vary from d=
ay to day.
> >> >> I'll experiment some more, and switch transmission channels.  I=
'm not getting
> >> >> the really poor performance with ath5k right now.
> >> >>
> >> >> I haven't looked yet - is there a way to switch to 'pid' rate c=
ontrol without
> >> >> rebuilding the kernel?
> >> >
> >> > If you configure your kernel to include multiple rate control
> >> > algorithms then you can use the 'ieee80211_default_rc_algo' modu=
le
> >> > option for mac80211.  Of course, changing that only works if you
> >> > rmmod/insmod mac80211.
> >> >
> >> > John
> >>
> >> Judging from this, is it really a good idea to hide pid behind EMB=
EDDED?
> >
> > I've been wondering about that myself.  I'm inclined to think no.
> >
> > John
>=20
> I think EMBEDDED is for options that replace full-featured Linux
> components with dumbed-down, "low-profile" equivalents (like SLOB) -
> PID vs. minstrel is more like SLAB vs. SLUB.

Patches welcome.  Bonus points if you find a way to switch algorithms
without module unloading and/or to pick different algorithms for
different interfaces.

John
--=20
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html