Date: Wed, 3 May 2006 08:20:05 -0300 From: AT Matik <asstec@matik.com.br> To: freebsd-mobile@freebsd.org Subject: Re: kernel: ath0: device timeout Message-ID: <200605030820.06123.asstec@matik.com.br> In-Reply-To: <445789BB.1@errno.com> References: <7.0.1.0.1.20060428134316.01e05648@live555.com> <200605020928.40730.asstec@matik.com.br> <445789BB.1@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 02 May 2006 13:32, Sam Leffler wrote: > > the proprietary one? You mean not compiling or loading any rate and let > > the card do the work by itself? > > The card is a packet engine; tx rate control is always done in the host. > so which one of the envolved hosts you mean? The PC where the card is stick= ed=20 in would be one host ... > > I'm sorry but you don't seem to understand how tx rate control should > work. I suggest you search for papers about it and do some reading. > The atheros h/w provides all the information necessary to do a very good > job of deciding what tx rate is optimal for sending a frame whether > operating in station, hostap, or adhoc mode. How to operate in outdoor > applications with high propagation delay is a totally different matter. > spare me with such comments, of course if I understood everything I would n= ot=20 even talk here but write my own code for my needs. And sorry, but first you= =20 nuke and then confirm what I said ... man man man so, since you agree then about existing difference between indoor and outdo= or=20 which rate should be used? the propagation delay in outdoor environments is probably not so high as I= =20 understand you say and very close to indoor But I like to add here that what works indoor does not necessarily works we= ll=20 outdoor but the obvious, what works outdoor would work fine indoor still=20 better. > I have tried for several years to get folks interested in working on > this problem. John Bickett's sample code is excellent work and by far > the best algorithm available which is why it is the default (replacing > the original onoe code). I am willing to work with anyone interested in > improving the existing code or to do a new algorithm but I am somewhat > constrained by nda's. good base agreeing about the problem but in the field the onoe definitly is the better choice so probably we nee= d a=20 better definition for good, excellent and best. nda as in no disclosure agreement? Why that? Look, lets talk about the real here. I believe that making a lot of effort in making better code for using any W= L=20 card as client/station is the wrong target. Most people are using windows a= nd=20 they do not even care how that works, neither it's performance. They want t= o=20 stay connected. Careful, I am not saying this work is useless but I am sayi= ng=20 that the work is not payed back. On the other side, using a Unix as AP is where it changes. I could give you= =20 lots of reasons why using a unix box as AP and so IMO this would be a bette= r=20 target: hostap At the end it does not even matter if my card (as station) has the best cod= e=20 in the driver when I am connected to a weak AP. Even if the AP is not so ba= d=20 my champ-code does not give me any big advantage. But if I have a=20 champ-hostap-code ALL stations get a benefit from that, even the worse ones. 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?200605030820.06123.asstec>