$ 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
