[ath9k-devel] AR5416 not fully working

[ath9k-devel] AR5416 not fully working

[Benoit PAPILLAULT]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

I'm currently testing an AR5416 minipci card in a laptop (using 1, 2 or
3 antennas does not make any difference). My configuration is:

- - laptop with the minipci card in STA mode
- - Linksys WRT350N in AP mode
- - another laptop wired to the Linksys AP
- - doing iperf between the 2 laptops

I'm using wireless-testing tree + the ath9k driver. Here are the problem
i'm facing:

1/ Association using wpa_suplicant (WPA2-PSK) is OK
2/ DHCP is always failing (I never got an IP)
3/ Using a fixed IP, I'm not able to ping for some time (at least for 80s)
4/ When ping is working, throughout is like 15 Mbits at its maximum.
5/ During all the test, tcpdump show that the RX side is OK

dmesg shows lots of "BA request denied", but apparently that might not
be a problem.

Is that a known bug? Did i miss something in my setup? How to debug?

I will redo the very same test with an AR9160 minipci card as well.

Regards,
Benoit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI9Y2/OR6EySwP7oIRAj9NAJ906MP6kghxhPQs3CbEW2Lx9LrJ4QCeP+jk
JprFlSRC4qgc/J7d2Sj0rgc=
=d/9/
-----END PGP SIGNATURE-----

[ath9k-devel] AR5416 not fully working

[Luis R. Rodriguez]

On Tue, Oct 14, 2008 at 11:29:19PM -0700, Benoit PAPILLAULT wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

Hey Bonoit!

> Hi there,
> 
> I'm currently testing an AR5416 minipci card in a laptop (using 1, 2 or
> 3 antennas does not make any difference). My configuration is:
> 
> - - laptop with the minipci card in STA mode
> - - Linksys WRT350N in AP mode
> - - another laptop wired to the Linksys AP
> - - doing iperf between the 2 laptops
> 
> I'm using wireless-testing tree + the ath9k driver. Here are the problem
> i'm facing:
> 
> 1/ Association using wpa_suplicant (WPA2-PSK) is OK

Yay.

> 2/ DHCP is always failing (I never got an IP)

Thanks, this should not fail and it does not fail in my own setup.
Can you provide the log messages during this?

> 3/ Using a fixed IP, I'm not able to ping for some time (at least for 80s)

This needs to be fixed too, can you provide log messages during this?
I haven't seen this anymore, it used to happen but I no longer see it.

> 4/ When ping is working, throughout is like 15 Mbits at its maximum.

You will only get MCS rates but without aggregation. It also depends
on the noise on the location of where you are testing. More on this below.

> 5/ During all the test, tcpdump show that the RX side is OK
> 
> dmesg shows lots of "BA request denied", but apparently that might not
> be a problem.

Out of these I take it you mean the second one:

ht.c:           printk(KERN_DEBUG "BA request denied - session is not "
ht.c:           printk(KERN_DEBUG "BA request denied - queue unavailable for"
ht.c:           printk(KERN_DEBUG "BA request denied - HW unavailable for"

If so I find it strange as aggregation is disabled right now in
mac80211 -- see ieee80211_ht_agg_queue_add(). But keep in mind ath9k
ampdu_queues = 1 on ath9k right now and what I've seen so far is ath9k
sends frames on two tids during a session to an AP some initial data on
tid 0 and some data frames on tid 6. I think this a bug. Anyway you can
temporarilly fix this by increasing the number of ampdu_queues ath9k
declares. This whole ampdu_queues is bogus and just needs to be removed
to fix aggregation properly in mac80211.

> Is that a known bug? Did i miss something in my setup? How to debug?

For now please consider aggregation disabled and broken in mac80211 due
to two facts:

1. Its current design on relying ampdu_queue notion (tid_to_tx_q stuff).
2. TX MQ changes require changes in order to deal with overwriting of
   skb->cb upon having the skb enter the qdisc.

Our initial work on aggregation addresses the second issue and we tried
to get it in for 2.6.27 as a temporary solution without having to rm -rf
ampdu_queue notion yet. This patch didn't make it upstream, however, due
to the more amount of changes required and some other hacks I saw on the
way.

Its now time to simply fix aggregation properly by dealing with these
two issues. For now please consider aggregation disabled.

> I will redo the very same test with an AR9160 minipci card as well.

I suspect you will get similar results. But regardless the issues we
have to definitely address are your latency on ping/dhcp. Then we can
move on to throughput concerns but they may very well be related.

  Luis

[ath9k-devel] AR5416 not fully working

[Benoit PAPILLAULT]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luis R. Rodriguez a ?crit :
> On Tue, Oct 14, 2008 at 11:29:19PM -0700, Benoit PAPILLAULT wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
> 
> Hey Bonoit!
> 
>> Hi there,
>>
>> I'm currently testing an AR5416 minipci card in a laptop (using 1, 2 or
>> 3 antennas does not make any difference). My configuration is:
>>
>> - - laptop with the minipci card in STA mode
>> - - Linksys WRT350N in AP mode
>> - - another laptop wired to the Linksys AP
>> - - doing iperf between the 2 laptops
>>
>> I'm using wireless-testing tree + the ath9k driver. Here are the problem
>> i'm facing:
>>
>> 1/ Association using wpa_suplicant (WPA2-PSK) is OK
> 
> Yay.
> 
>> 2/ DHCP is always failing (I never got an IP)
> 
> Thanks, this should not fail and it does not fail in my own setup.
> Can you provide the log messages during this?
> 
>> 3/ Using a fixed IP, I'm not able to ping for some time (at least for 80s)
> 
> This needs to be fixed too, can you provide log messages during this?
> I haven't seen this anymore, it used to happen but I no longer see it.
> 
>> 4/ When ping is working, throughout is like 15 Mbits at its maximum.
> 
> You will only get MCS rates but without aggregation. It also depends
> on the noise on the location of where you are testing. More on this below.
> 
>> 5/ During all the test, tcpdump show that the RX side is OK
>>
>> dmesg shows lots of "BA request denied", but apparently that might not
>> be a problem.
> 
> Out of these I take it you mean the second one:
> 
> ht.c:           printk(KERN_DEBUG "BA request denied - session is not "
> ht.c:           printk(KERN_DEBUG "BA request denied - queue unavailable for"
> ht.c:           printk(KERN_DEBUG "BA request denied - HW unavailable for"
> 
> If so I find it strange as aggregation is disabled right now in
> mac80211 -- see ieee80211_ht_agg_queue_add(). But keep in mind ath9k
> ampdu_queues = 1 on ath9k right now and what I've seen so far is ath9k
> sends frames on two tids during a session to an AP some initial data on
> tid 0 and some data frames on tid 6. I think this a bug. Anyway you can
> temporarilly fix this by increasing the number of ampdu_queues ath9k
> declares. This whole ampdu_queues is bogus and just needs to be removed
> to fix aggregation properly in mac80211.
> 
>> Is that a known bug? Did i miss something in my setup? How to debug?
> 
> For now please consider aggregation disabled and broken in mac80211 due
> to two facts:
> 
> 1. Its current design on relying ampdu_queue notion (tid_to_tx_q stuff).
> 2. TX MQ changes require changes in order to deal with overwriting of
>    skb->cb upon having the skb enter the qdisc.
> 
> Our initial work on aggregation addresses the second issue and we tried
> to get it in for 2.6.27 as a temporary solution without having to rm -rf
> ampdu_queue notion yet. This patch didn't make it upstream, however, due
> to the more amount of changes required and some other hacks I saw on the
> way.
> 
> Its now time to simply fix aggregation properly by dealing with these
> two issues. For now please consider aggregation disabled.
> 
>> I will redo the very same test with an AR9160 minipci card as well.
> 
> I suspect you will get similar results. But regardless the issues we
> have to definitely address are your latency on ping/dhcp. Then we can
> move on to throughput concerns but they may very well be related.
> 
>   Luis
> 

Thanks Luis,

I must admit I do not fully understand your reply (I've not read the
802.11n specs .... ). I got the same results with AR9160. The exact
error message is:

BA request denied - queue unavailable for tid 0
BA request denied - queue unavailable for tid 6
BA request denied - queue unavailable for tid 7

However, this time, I got 27 Mbits, ie equivalent to 802.11g.

Are there some patches I can try?
Could you give me more details in order to fix aggregation?

Regards,
Benoit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI9kuDOR6EySwP7oIRArsdAKDTp1f+nK8zChNc+6ZeY+8qOhyFwACdGiEX
6vLnZb0y0GQav8QdgW9upVo=
=XPku
-----END PGP SIGNATURE-----

[ath9k-devel] AR5416 not fully working

[Luis R. Rodriguez]

On Wed, Oct 15, 2008 at 12:58:59PM -0700, Benoit PAPILLAULT wrote:
> I must admit I do not fully understand your reply (I've not read the
> 802.11n specs 

Neither have I but I've read a bit of it and a bit of code. I've tried
to summarize what I know so far here:

http://wireless.kernel.org/en/developers/Documentation/ieee80211/802.11n

It would be great to get more people to contribute to that page to help
summarize 11n to help with development so its easier for people to catch
up.

> .... ). I got the same results with AR9160. The exact
> error message is:
> 
> BA request denied - queue unavailable for tid 0
> BA request denied - queue unavailable for tid 6
> BA request denied - queue unavailable for tid 7

BA stands for Black Ack, see the description in the wiki but the
important part is that BAs are useful for aggregation. Aggregation is
disabled right now in mac80211 becuase as I mentioned
ieee80211_ht_agg_queue_add() doesn't allow the usage of an
"ampdu_queue" right now, we simply return early right now.
We call this routine from ieee80211_start_tx_ba_session()
in ht.c as follows:

       ret = ieee80211_ht_agg_queue_add(local, sta, tid);

        /* case no queue is available to aggregation
         * don't switch to aggregation */
        if (ret) {
#ifdef CONFIG_MAC80211_HT_DEBUG
                printk(KERN_DEBUG "BA request denied - queue unavailable
for"
                                        " tid %d\n", tid);
#endif /* CONFIG_MAC80211_HT_DEBUG */
                goto err_unlock_queue;
        }


And that is why you see the printk error message. That is because
ieee80211_ht_agg_queue_add() right now returns early because
the new TX multiqueue changes requires a change in design
on the usage of skb->cb -- we just need to take into consideration
that when an skb enters a qdisc that skb->cb no longer will have
the same information it used to. This information is required
during ieee80211_requeue(), which anyway IMHO is also broken
when you pass the requeue==1 parameter (I think we requeue onto the same
queue!).

int ieee80211_ht_agg_queue_add(struct ieee80211_local *local,
                               struct sta_info *sta, u16 tid)
{
        int i;

        /* XXX: currently broken due to cb/requeue use */
        return -EPERM;
... etc

> However, this time, I got 27 Mbits, ie equivalent to 802.11g.

Is this with HT20 or HT40? If HT20, can you try HT40 on the AP?

> Are there some patches I can try?

You can try removing that EPERM and you will probably get
rtnl_lock() complaints. We fixed this and the skb->cb issue
in some temporary patches and you can see the idea and concept
here for wireless-testing:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/mac80211/aggrv9-wl.tar

These patches may no longer apply and when I did a quick test on it
they oopsed. Anyway the intent was to fix this for 2.6.27 and these
patches do work:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/mac80211/aggrv9-2.6.27.tar

> Could you give me more details in order to fix aggregation?

I'm working on fixing this a *correct* way now, by removing the usage
of ampdu_queue stuff for ath9k. This is an Intel'ism which we just
don't need. The reason Intel added it was that their firmware
schedules aggregates onto their harware queue and they put their
ampdu_queueing mechanism into mac80211. We do this in our driver
and so we simply don't need this.

If you would like to help fix this I can recommend to start reviewing
the above patches and then we can discuss this further. Hopefully by
then I'll have some temporary patches we can work together on.

  Luis