Why is throughput so bad with lots of virtual stations?

Why is throughput so bad with lots of virtual stations?

[Ben Greear]

I notice that when I get, say, 200 virtual stations on a radio (ath9k),
the total throughput becomes about 100 packets per second.  It can run
several thousands of packets per second with 10 or so stations.

According to the xmit debugfs file, the radio is basically idle.
It's queues are empty almost all of the time, few retransmits, etc.

This is on the 3.0.26 kernel.

If anyone has any ideas of what might need work, please let me know.

I'll start digging into the code to see what I can see.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Why is throughput so bad with lots of virtual stations?

[Christian Lamparter]

On Saturday 31 March 2012 05:56:30 Ben Greear wrote:
> I notice that when I get, say, 200 virtual stations on a radio (ath9k),
> the total throughput becomes about 100 packets per second.  It can run
> several thousands of packets per second with 10 or so stations.
is this tcp or udp "throughput"?

Anyway, I don't know much about your AP. But If it's mac80211 based
then you might also run into a problem with ath9k vs mac80211 for
every sta_info_get_bss [used by ieee80211_find_sta et. al] call.
You see, the station hash table uses the last byte of a station's
MAC as the "HASH" [see STA_HASH]. So for 00:11:22:33:44:55, the hash
is "55". Now, ath9k uses a mac mask for it's VIFs as well, only it 
starts from the other direction [i.e.:] xy:11:22:33:44:55. 
[e.g.: vif1: 00:11:22:33:44:55, vif2: 04:11:22:33:44:55,
vif3: 0c:11:22:33:44:55, ...]

So, mac80211's sta hash table really becomes a "long list". Which has
to be traversed by the driver and stack several times. 

> According to the xmit debugfs file, the radio is basically idle.
> It's queues are empty almost all of the time, few retransmits, etc.
> 
> This is on the 3.0.26 kernel.
> 
> If anyone has any ideas of what might need work, please let me know.
> 
> I'll start digging into the code to see what I can see.

Regards,
	Chr

Re: Why is throughput so bad with lots of virtual stations?

[Ben Greear]

On 03/31/2012 02:59 AM, Christian Lamparter wrote:
> On Saturday 31 March 2012 05:56:30 Ben Greear wrote:
>> I notice that when I get, say, 200 virtual stations on a radio (ath9k),
>> the total throughput becomes about 100 packets per second.  It can run
>> several thousands of packets per second with 10 or so stations.
> is this tcp or udp "throughput"?

It was tcp, and at least part of the problem is that there are lots of
packet drops and very high latency and eventually it seems TCP basically completely hangs
(I'm trying to run a 9kbps TCP stream on each station).

 From sniffing the AP, it seems like it receives at least most of the pkts
OK.  Ath9k can drop packets on rx all over the place w/out bumping
counters, so I'm instrumenting the rx path (and some tx-path drops
as well) to try to see where packets are being lost.

> Anyway, I don't know much about your AP. But If it's mac80211 based
> then you might also run into a problem with ath9k vs mac80211 for
> every sta_info_get_bss [used by ieee80211_find_sta et. al] call.
> You see, the station hash table uses the last byte of a station's
> MAC as the "HASH" [see STA_HASH]. So for 00:11:22:33:44:55, the hash
> is "55". Now, ath9k uses a mac mask for it's VIFs as well, only it
> starts from the other direction [i.e.:] xy:11:22:33:44:55.
> [e.g.: vif1: 00:11:22:33:44:55, vif2: 04:11:22:33:44:55,
> vif3: 0c:11:22:33:44:55, ...]

I'm specifying the MAC addresses, and incrementing the last octet, so
at least that shouldn't be a problem.  Maybe the hash in general needs
to be bigger...I'll look at that.

Thanks for the info.

Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com