kernel: ath0: device timeout

[Sam Leffler]

AT Matik wrote:
> 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 
> card do the work by itself?

The card is a packet engine; tx rate control is always done in the host.

> 
> anyway, I would say if onoe is "good" or not depends on what this decision is 
> based on
> 
> if onoe is lazier in up/down shifting the connextion speed it is probably a 
> better choice in real life because in outdoor environments there we find 
> conditions which may  continuously change the SNR and noise level and so it 
> may cause troubles on a nervous rate shifter
> 
> Depends on what we want from this card this rate issue probably needs a 
> general revision (this is not anything against you or your work) because it 
> is certainly a difference if I run client mode, adhoc or hostap and so the 
> rate decision must be different.
> 
> so probably a rate_sample as fast shifter is veru good and desireable when 
> running in client mode but I am not so sure if this should be so in hostap 
> and adhoc.
> 
> I believe that rate_sample shifts down and the rate is going to serve all 100 
> conected clients in 1MB? Or how work this?

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.

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.

> 
> This new sysctl has to do with rate decision?
> 
> net.wlan.0.bmiss_max

No.
	Sam