kernel: ath0: device timeout

[AT Matik]

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 sticked 
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 not 
even talk here but write my own code for my needs. And sorry, but first you 
nuke and then confirm what I said ...  man man man

so, since you agree then about existing difference between indoor and outdoor 
which rate should be used?

the propagation delay in outdoor environments is probably not so high as I 
understand you say and very close to indoor

But I like to add here that what works indoor does not necessarily works well 
outdoor but the obvious, what works outdoor would work fine indoor still 
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 need a 
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 WL 
card as client/station is the wrong target. Most people are using windows and 
they do not even care how that works, neither it's performance. They want to 
stay connected. Careful, I am not saying this work is useless but I am saying 
that the work is not payed back.

On the other side, using a Unix as AP is where it changes. I could give you 
lots of reasons why using a unix box as AP and so IMO this would be a better 
target: hostap

At the end it does not even matter if my card (as station) has the best code 
in the driver when I am connected to a weak AP. Even if the AP is not so bad 
my champ-code does not give me any big advantage. But if I have a 
champ-hostap-code ALL stations get a benefit from that, even the worse ones.

João









A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br