Re: compat-wireless and minstrel

[Adam Wozniak <awozniak@irobot.com>]

$ 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
>