From owner-freebsd-mobile@FreeBSD.ORG Wed May 3 11:20:19 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 BCE3D16A400 for ; Wed, 3 May 2006 11:20:19 +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 3F10843D48 for ; Wed, 3 May 2006 11:20:19 +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 k43BJMRh055105; Wed, 3 May 2006 08:19:22 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-mobile@freebsd.org Date: Wed, 3 May 2006 08:20:05 -0300 User-Agent: KMail/1.9.1 References: <7.0.1.0.1.20060428134316.01e05648@live555.com> <200605020928.40730.asstec@matik.com.br> <445789BB.1@errno.com> In-Reply-To: <445789BB.1@errno.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200605030820.06123.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: 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: Wed, 03 May 2006 11:20:19 -0000 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