Re: hostap TX fix in 5.x

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


	Any word on this? Anyone get any further? If someone could
remember what the syntax was to determine the transmission speed before
sending the packet, I could write a quick hack to make me happy :).. I
have honestly been looking for hours, perhaps I'm missing it.. I don't
care about 5.5mbit or 2mbit.. just need that fall back available when
11mbit isn't going to happen. I've tried comparing the code to openbsd and
netbsd with little success..

 	<on his knees>

	Scott



- ---------- Forwarded message ----------
Date: Mon, 17 May 2004 14:27:37 -0500
From: David Young <dyoung_at_pobox.com>
To: Sam Leffler <sam_at_errno.com>
Cc: freebsd-current_at_freebsd.org, Scott Pilz <scottp_at_tznet.com>,
     current_at_freebsd.org
Subject: 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFArOmb2REUg6gjWxgRAg5MAJwJCf4I5bhcISyphjAkA9MmgMJ0wwCeJm7N
5YXWROUY49wNuq4wZkiqbJc=
=nOpl
-----END PGP SIGNATURE-----