Subject: Re: ural(4) for NetBSD 3.0, now sync'ed with OpenBSD ural driver
To: David Young <tech-net@NetBSD.org>
From: Damien Bergamini <email@example.com>
Date: 11/28/2005 18:07:57
| 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.
| 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:
SampleRate is not an option for ural. You need a polling algorithm.
| 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.
Yes, you have overlooked somthing *big*:
the documentation of the RT2570 chipset.
RT2570 supports multi-rate retry.