Subject: Re: ural(4) for NetBSD 3.0, now sync'ed with OpenBSD ural driver
To: None <tech-net@NetBSD.org, tech-kern@NetBSD.org>
From: David Young <firstname.lastname@example.org>
Date: 11/28/2005 12:40:34
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://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.
David Young OJC Technologies
email@example.com Urbana, IL * (217) 278-3933