Re: hostap TX fix in 5.x [Fwd: Re: wi hostap speed]

On Mon, May 17, 2004 at 08:42:52AM -0700, Sam Leffler wrote:
> On Monday 17 May 2004 04:38 am, Scott Pilz wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > 	Who normally works on the wi driver? "frmhdr.wi_tx_rate = 110"
> > works great (thanks James) but I am unable to find the syntax/variable
> > where the current TX-RATE is stored. A simple if tx-rate=11 {
> > frmhdr.wi_tx_rate = 110; } would keep auto-fallback working. Currently the
> > system works great (I seen as far as 600KB/sec last night during testing)
> > but when the signal drops and the driver tries for 5.5 or 2, packets are
> > lost. I recall in earlier releases of 5.x there was a 'DataRate' display
> > on 'wicontrol -l', however in CURRENT this seems to be missing.
> 
> In the past Warner and I have worked on the driver but neither has time and 
> noone else has stepped up.  It sounds like you've locked the xmit rate to a 
> fixed value instead of allowing the firmware to select the "best rate."  This 
> sounds as though something else is set wrong to make the best rate operation 
> not work right.
> 
> FWIW netbsd uses an adaptive rate control algorithm to select the xmit rate.  
> Reports are that this algorithm does a better job than the firmware algorithm 
> for choosing xmit rate when operating in hostap mode.

Right.  In hostap mode, the Prism firmware does not do rate adaptation;
it's left to the driver.  By default, the f/w operates in hostap mode at
a measly 1-2Mbps.  So people see a big difference using the rssadapt(9)
adaptation.

In the non-hostap modes, the Prism firmware does a pretty naive
adaptation.  And it is more difficult to do a smart adaptation, because
frmhdr.wi_tx_rate is not available.

In the NetBSD manual pages on the web, see rssadapt(9) for an overview
of NetBSD's adaptation framework.

(As an aside, I think that enthusiasm for wi(4) hardware is diminishing
fast as the flexibility of the WiFi ASICs grows more visible.  There is
scarcely any flexibility in Lucent/Prism hardware versus, say, Atheros.
However, if Lucent & Intersil would release programming specs for their
MAC microcontrollers, their hardware would get really interesting again.
A guy can dream....)

Dave

-- 
David Young             OJC Technologies
dyoung_at_ojctech.com      Urbana, IL * (217) 278-3933