On Mon, Nov 28, 2005 at 06:07:57PM +0100, Damien Bergamini wrote:
> | AMRR is already in the NetBSD tree, although it is coupled with ath(4);
> | see src/sys/dev/ic/athrate-amrr.[ch].  I prefer that the code isn't
> | duplicated in ural(4).
> 
> People always talk about making things generic but never step in or show
> any code.  It's not generic because you don't want it to be generic.
> You want to exploit the different h/w capabilities.  The AMRR algorithm
> is about 30 lines long by itself.  It's not that big.

I'm not concerned with the size, I'm concerned with avoiding a "cut
and paste" programming methodology.

The h/w capabilities are not so different that the code for
bitrate-adaptation cannot be reused.

> | As far as bitrate-selection algorithms go, AMRR seems naive to me.
> | I made SampleRate (athrate-sample.[ch]) the default for ath(4), since it
> | is based on experimental results from 802.11 testbeds.  Alas, SampleRate
> | may be buggy.  I understand there are newer versions of SampleRate
> | somewhere on the Internet; they may fix the bugs.
> 
> There are very good experimental results for AMRR too:
> http://www.inria.fr/rrrt/rr-5208.html 
> http://crewman.uta.edu/corenetworking/ projects/RC_oct21_2005_v1.pdf 
> 
> SampleRate is not an option for ural.  You need a polling algorithm.

That is too bad about ural, but SampleRate appears to be a perfectly
good option for atw, ral, and rtw.

> | AMRR is a perplexing choice for ural(4).  AMRR stands for "Adaptive
> | Multi-Rate Retry."  AFAICT, the ural(4) hardware does not even support
> | multi-rate retry.  Maybe I have overlooked something.
> |
> | Dave
> 
> Yes, you have overlooked somthing *big*:
> the documentation of the RT2570 chipset.

The only RT2570 chipset documentation I have is your code.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933