Re: compat-wireless and minstrel

Adam Wozniak
2009-11-04T21:46:58Z

$ ls -la /lib/firmware/ar9170*
-rw-r--r-- 1 root root 83968 2009-10-17 15:55 /lib/firmware/ar9170-1.fw
-rw-r--r-- 1 root root 3508 2009-10-17 15:55 /lib/firmware/ar9170-2.fw
-rw-r--r-- 1 root root 15960 2009-10-17 15:55 /lib/firmware/ar9170.fw

It is unclear to me which are actually used. I will try removing the
two stage firmware files and see what happens.

Christian Lamparter wrote:
> On Wednesday 04 November 2009 22:01:39 Derek Smithies wrote:
>
>> Hi,
>> On Wed, 4 Nov 2009, Christian Lamparter wrote:
>>
>>
>>> On Wednesday 04 November 2009 02:13:49 Adam Wozniak wrote:
>>>
>>>> I have two systems under test, both Dell laptops (a Latitude D630 and an
>>>> Inspiron 600m) both running Ubuntu 9.10 with the latest updates, and
>>>> bleeding edge compat-wireless-2009-11-02. I'm using identical AR9170
>>>> based D-Link DWA-160 USB 802.11adapters. I'm using nuttcp to measure
>>>> throughput. I'm running in ad-hoc mode. Both machines have the same
>>>> ar9170 files in /lib/firmware. The machines are sitting about 5 feet
>>>> apart in my office.
>>>>
> by the way: I forgot to ask, but which firmware do you use?
> If you still have *two - stage*, then get rid of it.
> Since one-stage fws contain a few fixes for most temporarily MAC/BB-hiccups.
>
>
>>>> I'm having occasional problems where throughput drops through the floor
>>>> (0.5Mbps - 1.5Mbps). When I cat
>>>> /sys/kernel/debug/ieee80211/*/stations/*/rc_stats, one of the machines
>>>> lists the full set of rates, but the other only lists 1M and 54M. After
>>>> a period of time, that machine drops 54M and lists only one rate
>>>> (1Mbps), and the throughput listed by nuttcp drops accordingly. I
>>>> assume that, for whatever reason, the rates drop off the list and
>>>> minstrel uses the only one left available to it.
>>>>
>>>> If I modify include/net/mac80211.h and force the inline function
>>>> rate_supported to always return 1, this fixes the problem. However, I
>>>> think this is a band aid around some other issue.
>>>>
>>>> Any clues or ideas what the real issue might be here?
>>>>
>> My guess::
>>
>> When an adhoc node (call it A) merges with a second adhoc node (call it
>> B) there is a capability comparison.
>> Node A looks at the rates supported by B and says,
>> "I must only transmit at rates supported by B"
>>
>> Some management frames don't contain a full report of the rates supported
>> by the sender.
>> My view is that node A (in this example) is incorrectly determining that B
>> only supports the 1mb/sec rate. Consequently, node A fills the
>> rate_supported array with one rate - 1mb/sec.
>>
> well, that's the thing... it sounds like something in cfg80211/mac80211 has
> gone wrong. Since ibss supported/basic rates IEs should always include all
> mandatory rates for the given band & mode. Therefore you should see the
> 2Mbit, 11Mbit, 6MBit, 12Mbit 24Mbit rates in rc_stats array as well.
>
>
>> =====
>>
> =====
>
>
>> There is no evidence that Minstrel is doing anything wrong.
>>
> ?but no one said it was minstrel fault? And it clearly isn't.
>
> But something OT: do you have already thoughts about
> _extending_ minstrel to support 802.11n MCS rates?
>
> The current endeavor is stuck and needs a kick-start.
> This is partly because of a hen-egg problem:
> no driver <-> no 11n rc. But it should be easy to get
> 11n capable hw now (e.g. Mikrotik's R52N) and
> ath9k should be the perfect testing platform right now.
>
> nbd has/had some thought about grouping rates and options
> (e.g SGI/40MHz) together to reduce the number of rates to
> improve the _search for best tp_ time. But dunno, maybe he
> has already something better than the proof-of-concept I wrote earlier.
>
> Regards,
> Chr
>