Date: Tue, 2 May 2006 09:28:39 -0300 From: AT Matik <asstec@matik.com.br> To: Sam Leffler <sam@errno.com> Cc: freebsd-mobile@freebsd.org Subject: Re: kernel: ath0: device timeout Message-ID: <200605020928.40730.asstec@matik.com.br> In-Reply-To: <44528359.1030304@errno.com> References: <7.0.1.0.1.20060428134316.01e05648@live555.com> <200604281755.12871.asstec@matik.com.br> <44528359.1030304@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 28 April 2006 18:04, Sam Leffler wrote: > > in my case it stopped when I compiled ath_rate_onoe instead of > > rate_sample as well as I got much higher throughput and response times > > If changing the tx rate control algorithm really fixes it then that says > sample may be handing back bogus rate codes. Since I can't make this > happen someone else needs to dig. > > As to better performance, onoe is not especially good and I do not > recommend it. However sample is too aggressive on up-shifting the tx > rate and tends to vary the rate too quickly so can degrade performance > when signal deteriorates. I have done extensive testing of all the rate > control algorithms as well as a proprietary one and chose sample as the > default. However none are anywhere near as effective as the proprietary > one. > the proprietary one? You mean not compiling or loading any rate and let the= =20 card do the work by itself? anyway, I would say if onoe is "good" or not depends on what this decision = is=20 based on if onoe is lazier in up/down shifting the connextion speed it is probably a= =20 better choice in real life because in outdoor environments there we find=20 conditions which may continuously change the SNR and noise level and so it= =20 may cause troubles on a nervous rate shifter Depends on what we want from this card this rate issue probably needs a=20 general revision (this is not anything against you or your work) because it= =20 is certainly a difference if I run client mode, adhoc or hostap and so the= =20 rate decision must be different. so probably a rate_sample as fast shifter is veru good and desireable when= =20 running in client mode but I am not so sure if this should be so in hostap= =20 and adhoc. I believe that rate_sample shifts down and the rate is going to serve all 1= 00=20 conected clients in 1MB? Or how work this? This new sysctl has to do with rate decision? net.wlan.0.bmiss_max Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605020928.40730.asstec>