From owner-freebsd-mobile@FreeBSD.ORG Tue May 2 12:29:13 2006 Return-Path: X-Original-To: freebsd-mobile@freebsd.org Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 284EA16A4C4 for ; Tue, 2 May 2006 12:29:13 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CC4143D53 for ; Tue, 2 May 2006 12:29:12 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.6/8.13.1) with ESMTP id k42CShc3034121; Tue, 2 May 2006 09:28:45 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: Sam Leffler Date: Tue, 2 May 2006 09:28:39 -0300 User-Agent: KMail/1.9.1 References: <7.0.1.0.1.20060428134316.01e05648@live555.com> <200604281755.12871.asstec@matik.com.br> <44528359.1030304@errno.com> In-Reply-To: <44528359.1030304@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200605020928.40730.asstec@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-mobile@freebsd.org Subject: Re: kernel: ath0: device timeout X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 12:29:18 -0000 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