[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[David Jardin]

Hi,

I'm organizing all the technical stuff for several conferences about
Joomla (opensource content managment system) with 200-300 participants
and therefore I was looking for a low-budget wifi-solution that is able
to handle this number of clients. I decided to use a few raspberry pi's
with atheros-based usb wifi dongles which worked great in my little test
environment but crashed in the real conference setup.

I took a look at the logfiles and it seems that the issue is related to
the number of clients that can be handled by the driver/firmware, which
is 8 (ATH9K_HTC_MAX_STA). Is there any chance to increase this limit to
make the dongles usable in large-scale applications?

David

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Adrian Chadd]

The ath9k_htc stuff isn't ready to do what you want. And even if it
was, the performance would be sub-par compared to the SoC designs.
There's just not a lot of RAM on these things; even if we do
eventually push almost everything into the driver instead of firmware,
there's still only a limited amount of RAM for packet buffers. So
you're never going to reach the same level of performance as
direct-attach.

I suggest you spend the money on some slightly more useful access
points. You'll likely be able to serve at least 2x the clients on a
single 2x2 tplink or dlink access point for about $50-$70 each.

Good luck,


-adrian
(Why does everyone see "Raspberry pi" as the solution to everything
these days? Sheesh..)


On 8 July 2013 01:35, David Jardin <ich@djardin.de> wrote:
> Hi,
>
> I'm organizing all the technical stuff for several conferences about
> Joomla (opensource content managment system) with 200-300 participants
> and therefore I was looking for a low-budget wifi-solution that is able
> to handle this number of clients. I decided to use a few raspberry pi's
> with atheros-based usb wifi dongles which worked great in my little test
> environment but crashed in the real conference setup.
>
> I took a look at the logfiles and it seems that the issue is related to
> the number of clients that can be handled by the driver/firmware, which
> is 8 (ATH9K_HTC_MAX_STA). Is there any chance to increase this limit to
> make the dongles usable in large-scale applications?
>
> David
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[David Jardin]

Hi Adrian,

thanks for the response. That's bad news.

I thought about using the Pi's as they have much more RAM and CPU power
than normal consumer access points have - which seems to be the limiting
factor of clients on those devices. And as we are a non profit
organization we simply can't afford business class access points (Cisco
etc.) as they are way to expensive.

David

Am 08.07.13 22:07, schrieb Adrian Chadd:
> The ath9k_htc stuff isn't ready to do what you want. And even if it
> was, the performance would be sub-par compared to the SoC designs.
> There's just not a lot of RAM on these things; even if we do
> eventually push almost everything into the driver instead of firmware,
> there's still only a limited amount of RAM for packet buffers. So
> you're never going to reach the same level of performance as
> direct-attach.
>
> I suggest you spend the money on some slightly more useful access
> points. You'll likely be able to serve at least 2x the clients on a
> single 2x2 tplink or dlink access point for about $50-$70 each.
>
> Good luck,
>
>
> -adrian
> (Why does everyone see "Raspberry pi" as the solution to everything
> these days? Sheesh..)
>
>
> On 8 July 2013 01:35, David Jardin <ich@djardin.de> wrote:
>> Hi,
>>
>> I'm organizing all the technical stuff for several conferences about
>> Joomla (opensource content managment system) with 200-300 participants
>> and therefore I was looking for a low-budget wifi-solution that is able
>> to handle this number of clients. I decided to use a few raspberry pi's
>> with atheros-based usb wifi dongles which worked great in my little test
>> environment but crashed in the real conference setup.
>>
>> I took a look at the logfiles and it seems that the issue is related to
>> the number of clients that can be handled by the driver/firmware, which
>> is 8 (ATH9K_HTC_MAX_STA). Is there any chance to increase this limit to
>> make the dongles usable in large-scale applications?
>>
>> David
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Oleksij Rempel]

How replacing AP with about MESH or AdHock+BATMAN?

Am 09.07.2013 10:46, schrieb David Jardin:
> Hi Adrian,
>
> thanks for the response. That's bad news.
>
> I thought about using the Pi's as they have much more RAM and CPU power
> than normal consumer access points have - which seems to be the limiting
> factor of clients on those devices. And as we are a non profit
> organization we simply can't afford business class access points (Cisco
> etc.) as they are way to expensive.
>
> David
>
> Am 08.07.13 22:07, schrieb Adrian Chadd:
>> The ath9k_htc stuff isn't ready to do what you want. And even if it
>> was, the performance would be sub-par compared to the SoC designs.
>> There's just not a lot of RAM on these things; even if we do
>> eventually push almost everything into the driver instead of firmware,
>> there's still only a limited amount of RAM for packet buffers. So
>> you're never going to reach the same level of performance as
>> direct-attach.
>>
>> I suggest you spend the money on some slightly more useful access
>> points. You'll likely be able to serve at least 2x the clients on a
>> single 2x2 tplink or dlink access point for about $50-$70 each.
>>
>> Good luck,
>>
>>
>> -adrian
>> (Why does everyone see "Raspberry pi" as the solution to everything
>> these days? Sheesh..)
>>
>>
>> On 8 July 2013 01:35, David Jardin <ich@djardin.de> wrote:
>>> Hi,
>>>


-- 
Regards,
Oleksij

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Felix Fietkau]

On 2013-07-09 10:50 AM, Oleksij Rempel wrote:
> How replacing AP with about MESH or AdHock+BATMAN?
Why? That sounds like a recipe for disaster to me (at least for
conference networks). The ath9k_htc stuff can't handle more peers in
mesh/ad-hoc than clients in AP mode.
In setting up a conference network, you have to think about what the
primary bottleneck is. When using consumer APs, the bottleneck isn't
CPU/RAM, it's usually limited channel airtime!

- Felix

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Oleksij Rempel]

Am 09.07.2013 11:18, schrieb Felix Fietkau:
> On 2013-07-09 10:50 AM, Oleksij Rempel wrote:
>> How replacing AP with about MESH or AdHock+BATMAN?
> Why? That sounds like a recipe for disaster to me (at least for
> conference networks). The ath9k_htc stuff can't handle more peers in
> mesh/ad-hoc than clients in AP mode.
> In setting up a conference network, you have to think about what the
> primary bottleneck is. When using consumer APs, the bottleneck isn't
> CPU/RAM, it's usually limited channel airtime!
>
> - Felix
>

Not with ath9k_htc. AdHock+BATMAN can be split in different groups on 
different channels. ath9k_htc can be used as STA to  primer AP and 
second interface on some laptops. But sure -- it is worst case scenario 
with no extra cost.

-- 
Regards,
Oleksij

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Felix Fietkau]

On 2013-07-09 11:34 AM, Oleksij Rempel wrote:
> Am 09.07.2013 11:18, schrieb Felix Fietkau:
>> On 2013-07-09 10:50 AM, Oleksij Rempel wrote:
>>> How replacing AP with about MESH or AdHock+BATMAN?
>> Why? That sounds like a recipe for disaster to me (at least for
>> conference networks). The ath9k_htc stuff can't handle more peers in
>> mesh/ad-hoc than clients in AP mode.
>> In setting up a conference network, you have to think about what the
>> primary bottleneck is. When using consumer APs, the bottleneck isn't
>> CPU/RAM, it's usually limited channel airtime!
>>
>> - Felix
>>
> 
> Not with ath9k_htc. AdHock+BATMAN can be split in different groups on 
> different channels. ath9k_htc can be used as STA to  primer AP and 
> second interface on some laptops. But sure -- it is worst case scenario 
> with no extra cost.
What does this have to do with handling wifi clients of 200-300
participants?

- Felix

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Adrian Chadd]

The newer, higher end tplink/dlink devices that use AR9344 ship with
128mb RAM and a 500MHz mips74k core.

I think that's enough for your needs.



-adrian

On 9 July 2013 01:46, David Jardin <ich@djardin.de> wrote:
> Hi Adrian,
>
> thanks for the response. That's bad news.
>
> I thought about using the Pi's as they have much more RAM and CPU power
> than normal consumer access points have - which seems to be the limiting
> factor of clients on those devices. And as we are a non profit
> organization we simply can't afford business class access points (Cisco
> etc.) as they are way to expensive.
>
> David
>
> Am 08.07.13 22:07, schrieb Adrian Chadd:
>> The ath9k_htc stuff isn't ready to do what you want. And even if it
>> was, the performance would be sub-par compared to the SoC designs.
>> There's just not a lot of RAM on these things; even if we do
>> eventually push almost everything into the driver instead of firmware,
>> there's still only a limited amount of RAM for packet buffers. So
>> you're never going to reach the same level of performance as
>> direct-attach.
>>
>> I suggest you spend the money on some slightly more useful access
>> points. You'll likely be able to serve at least 2x the clients on a
>> single 2x2 tplink or dlink access point for about $50-$70 each.
>>
>> Good luck,
>>
>>
>> -adrian
>> (Why does everyone see "Raspberry pi" as the solution to everything
>> these days? Sheesh..)
>>
>>
>> On 8 July 2013 01:35, David Jardin <ich@djardin.de> wrote:
>>> Hi,
>>>
>>> I'm organizing all the technical stuff for several conferences about
>>> Joomla (opensource content managment system) with 200-300 participants
>>> and therefore I was looking for a low-budget wifi-solution that is able
>>> to handle this number of clients. I decided to use a few raspberry pi's
>>> with atheros-based usb wifi dongles which worked great in my little test
>>> environment but crashed in the real conference setup.
>>>
>>> I took a look at the logfiles and it seems that the issue is related to
>>> the number of clients that can be handled by the driver/firmware, which
>>> is 8 (ATH9K_HTC_MAX_STA). Is there any chance to increase this limit to
>>> make the dongles usable in large-scale applications?
>>>
>>> David
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Gustavo]

Hi David, how you resolve this problem?

What you do?


Thanks!

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Ben Greear]

On 11/20/2013 10:44 AM, Gustavo wrote:
> Hi David, how you resolve this problem?
> 
> What you do?

You may end up having to re-write firmware, and perhaps significantly.

That is not likely to be very easy....

Thanks,
Ben



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

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Gustavo Azambuja]

Ben, thanks for you reply.
I need to convert my rPi into a AP (is not an option a "real" AP) to
get at less 30 stations. You know some way to get a list of
devices/drivers can support this?

Thanks

On Wed, Nov 20, 2013 at 4:58 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 11/20/2013 10:44 AM, Gustavo wrote:
>> Hi David, how you resolve this problem?
>>
>> What you do?
>
> You may end up having to re-write firmware, and perhaps significantly.
>
> That is not likely to be very easy....
>
> Thanks,
> Ben
>
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>



-- 
Gustavo Azambuja - Linux User: 275813
http://gazambuja.com

Uruguay:     091 300 333 (Montevideo - Mobile)

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Oleksij Rempel]

Am 20.11.2013 20:01, schrieb Gustavo Azambuja:
> Ben, thanks for you reply.
> I need to convert my rPi into a AP (is not an option a "real" AP) to
> get at less 30 stations. You know some way to get a list of
> devices/drivers can support this?

It's all about USB, RAM and power.
If you use usb to communicate with wireless hardware, then your first
problem is usb - it is too slow! Some times it is too slow even for one
connection. This is why we have usb wifi adapters with internal cpu, ram
and firmware (micro operation system). If you wont to add more
connections you will need more ram and may be more cpu power. This will
need more power from usb, which is limited to 500mA.
In this case, just take some AP, connect it over ethernet and you will
get same result.

> Thanks
> 
> On Wed, Nov 20, 2013 at 4:58 PM, Ben Greear <greearb@candelatech.com> wrote:
>> On 11/20/2013 10:44 AM, Gustavo wrote:
>>> Hi David, how you resolve this problem?
>>>
>>> What you do?
>>
>> You may end up having to re-write firmware, and perhaps significantly.
>>
>> That is not likely to be very easy....
>>
>> Thanks,
>> Ben
>>
>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
> 
> 
> 


-- 
Regards,
Oleksij

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Ben Greear]

On 11/22/2013 02:23 AM, Oleksij Rempel wrote:
> Am 20.11.2013 20:01, schrieb Gustavo Azambuja:
>> Ben, thanks for you reply.
>> I need to convert my rPi into a AP (is not an option a "real" AP) to
>> get at less 30 stations. You know some way to get a list of
>> devices/drivers can support this?
>
> It's all about USB, RAM and power.
> If you use usb to communicate with wireless hardware, then your first
> problem is usb - it is too slow! Some times it is too slow even for one
> connection. This is why we have usb wifi adapters with internal cpu, ram
> and firmware (micro operation system). If you wont to add more
> connections you will need more ram and may be more cpu power. This will
> need more power from usb, which is limited to 500mA.
> In this case, just take some AP, connect it over ethernet and you will
> get same result.

The RAM is certainly an issue, but just adding more stations should not
have much CPU impact as the total throughput is unlikely to increase
as more stations are added.

Changing software to make better use of RAM is also unlikely to increase
power usage, though adding more RAM to the hardware might.

Out of curiosity, does anyone know how much RAM is on those adapters?

Thanks,
Ben


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

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Oleksij Rempel]

Am 22.11.2013 15:40, schrieb Ben Greear:
> On 11/22/2013 02:23 AM, Oleksij Rempel wrote:
>> Am 20.11.2013 20:01, schrieb Gustavo Azambuja:
>>> Ben, thanks for you reply.
>>> I need to convert my rPi into a AP (is not an option a "real" AP) to
>>> get at less 30 stations. You know some way to get a list of
>>> devices/drivers can support this?
>>
>> It's all about USB, RAM and power.
>> If you use usb to communicate with wireless hardware, then your first
>> problem is usb - it is too slow! Some times it is too slow even for one
>> connection. This is why we have usb wifi adapters with internal cpu, ram
>> and firmware (micro operation system). If you wont to add more
>> connections you will need more ram and may be more cpu power. This will
>> need more power from usb, which is limited to 500mA.
>> In this case, just take some AP, connect it over ethernet and you will
>> get same result.
> 
> The RAM is certainly an issue, but just adding more stations should not
> have much CPU impact as the total throughput is unlikely to increase
> as more stations are added.
> 
> Changing software to make better use of RAM is also unlikely to increase
> power usage, though adding more RAM to the hardware might.

patches are welcome

> Out of curiosity, does anyone know how much RAM is on those adapters?

http://wikidevi.com/wiki/AR9271
http://wikidevi.com/wiki/AR7010

-- 
Regards,
Oleksij

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Ben Greear]

On 11/22/2013 06:47 AM, Oleksij Rempel wrote:
> Am 22.11.2013 15:40, schrieb Ben Greear:
>> On 11/22/2013 02:23 AM, Oleksij Rempel wrote:
>>> Am 20.11.2013 20:01, schrieb Gustavo Azambuja:
>>>> Ben, thanks for you reply.
>>>> I need to convert my rPi into a AP (is not an option a "real" AP) to
>>>> get at less 30 stations. You know some way to get a list of
>>>> devices/drivers can support this?
>>>
>>> It's all about USB, RAM and power.
>>> If you use usb to communicate with wireless hardware, then your first
>>> problem is usb - it is too slow! Some times it is too slow even for one
>>> connection. This is why we have usb wifi adapters with internal cpu, ram
>>> and firmware (micro operation system). If you wont to add more
>>> connections you will need more ram and may be more cpu power. This will
>>> need more power from usb, which is limited to 500mA.
>>> In this case, just take some AP, connect it over ethernet and you will
>>> get same result.
>>
>> The RAM is certainly an issue, but just adding more stations should not
>> have much CPU impact as the total throughput is unlikely to increase
>> as more stations are added.
>>
>> Changing software to make better use of RAM is also unlikely to increase
>> power usage, though adding more RAM to the hardware might.
>
> patches are welcome

I'm sure :)

My customers are all interested in /AC these days, so I'm putting my
effort there.  If/when someone opens an /AC firmware to the public
I will be all over it!

>> Out of curiosity, does anyone know how much RAM is on those adapters?
>
> http://wikidevi.com/wiki/AR9271
> http://wikidevi.com/wiki/AR7010

Thanks, that is good info.

Ben


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

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Oleksij Rempel]

Am 22.11.2013 16:00, schrieb Ben Greear:
> On 11/22/2013 06:47 AM, Oleksij Rempel wrote:
>> Am 22.11.2013 15:40, schrieb Ben Greear:
>>> On 11/22/2013 02:23 AM, Oleksij Rempel wrote:
>>>> Am 20.11.2013 20:01, schrieb Gustavo Azambuja:
>>>>> Ben, thanks for you reply.
>>>>> I need to convert my rPi into a AP (is not an option a "real" AP) to
>>>>> get at less 30 stations. You know some way to get a list of
>>>>> devices/drivers can support this?
>>>>
>>>> It's all about USB, RAM and power.
>>>> If you use usb to communicate with wireless hardware, then your first
>>>> problem is usb - it is too slow! Some times it is too slow even for one
>>>> connection. This is why we have usb wifi adapters with internal cpu,
>>>> ram
>>>> and firmware (micro operation system). If you wont to add more
>>>> connections you will need more ram and may be more cpu power. This will
>>>> need more power from usb, which is limited to 500mA.
>>>> In this case, just take some AP, connect it over ethernet and you will
>>>> get same result.
>>>
>>> The RAM is certainly an issue, but just adding more stations should not
>>> have much CPU impact as the total throughput is unlikely to increase
>>> as more stations are added.
>>>
>>> Changing software to make better use of RAM is also unlikely to increase
>>> power usage, though adding more RAM to the hardware might.
>>
>> patches are welcome
> 
> I'm sure :)
> 
> My customers are all interested in /AC these days, so I'm putting my
> effort there.  If/when someone opens an /AC firmware to the public
> I will be all over it!

AC?


-- 
Regards,
Oleksij

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Ben Greear]

On 11/22/2013 07:02 AM, Oleksij Rempel wrote:
> Am 22.11.2013 16:00, schrieb Ben Greear:
>> On 11/22/2013 06:47 AM, Oleksij Rempel wrote:
>>> Am 22.11.2013 15:40, schrieb Ben Greear:
>>>> On 11/22/2013 02:23 AM, Oleksij Rempel wrote:
>>>>> Am 20.11.2013 20:01, schrieb Gustavo Azambuja:
>>>>>> Ben, thanks for you reply.
>>>>>> I need to convert my rPi into a AP (is not an option a "real" AP) to
>>>>>> get at less 30 stations. You know some way to get a list of
>>>>>> devices/drivers can support this?
>>>>>
>>>>> It's all about USB, RAM and power.
>>>>> If you use usb to communicate with wireless hardware, then your first
>>>>> problem is usb - it is too slow! Some times it is too slow even for one
>>>>> connection. This is why we have usb wifi adapters with internal cpu,
>>>>> ram
>>>>> and firmware (micro operation system). If you wont to add more
>>>>> connections you will need more ram and may be more cpu power. This will
>>>>> need more power from usb, which is limited to 500mA.
>>>>> In this case, just take some AP, connect it over ethernet and you will
>>>>> get same result.
>>>>
>>>> The RAM is certainly an issue, but just adding more stations should not
>>>> have much CPU impact as the total throughput is unlikely to increase
>>>> as more stations are added.
>>>>
>>>> Changing software to make better use of RAM is also unlikely to increase
>>>> power usage, though adding more RAM to the hardware might.
>>>
>>> patches are welcome
>>
>> I'm sure :)
>>
>> My customers are all interested in /AC these days, so I'm putting my
>> effort there.  If/when someone opens an /AC firmware to the public
>> I will be all over it!
>
> AC?
>
>

802.11 ac, for instance ath10k.

Thanks,
Ben

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

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Alex Hacker]

QCA stated the firmware source can be opened for the "selected customers".
We need to know who and how select the customers. Can the open source community
be included in this category? Something hints me what it never happens. :(

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Sujith Manoharan]

Alex Hacker wrote:
> QCA stated the firmware source can be opened for the "selected customers".
> We need to know who and how select the customers. Can the open source community
> be included in this category? Something hints me what it never happens. :(

Sorry, but which firmware are you referring to ? The firmware for
ath9k_htc is open: https://github.com/qca/open-ath9k-htc-firmware

Sujith

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Alex Hacker]

Sorry for the offtopic Sujith, we talk about QCA9880 firmware.
Regards,
Alex.

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Adrian Chadd]

You need to be a big customer that requires that QCA open up the
firmware to open source, much like what's driven ath9k support.

I heartily encourage this.



-adrian


On 25 November 2013 04:02, Alex Hacker <hacker@epn.ru> wrote:
> Sorry for the offtopic Sujith, we talk about QCA9880 firmware.
> Regards,
> Alex.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Ben Greear]

On 11/25/2013 11:19 AM, Adrian Chadd wrote:
> You need to be a big customer that requires that QCA open up the
> firmware to open source, much like what's driven ath9k support.
> 
> I heartily encourage this.

If it's just money, maybe they could name their price and see
if someone will pay it :)

Either way, QCA seems more open to sharing firmware than anyone
else, so it could be worse.

Thanks,
Ben

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

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Adrian Chadd]

On 25 November 2013 11:28, Ben Greear <greearb@candelatech.com> wrote:
> On 11/25/2013 11:19 AM, Adrian Chadd wrote:
>> You need to be a big customer that requires that QCA open up the
>> firmware to open source, much like what's driven ath9k support.
>>
>> I heartily encourage this.
>
> If it's just money, maybe they could name their price and see
> if someone will pay it :)
>
> Either way, QCA seems more open to sharing firmware than anyone
> else, so it could be worse.

IT's the irony of the situation. If they're lead by their customer
requirements then all it will take is a couple of customers requiring
the firmware source be open sourced and open licenced. It will kick
off another regulatory discussion, but besides that, it'll make things
happen.


-adiran

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Alex Hacker]

Open source community is a biggest of the biggest customers, isn't it? It is
a huge market, I speak about millions of gadgets and plastic boxes working
under some sort of Linux or BSD. Adrian, did you told something like that when
worked for QCA? But IMO the reason is different. QCA prefers to close any
access to a hardware, especially to non-standard PHY/Radio features. The same
role be played by HAL in older Atheros chips.
Sorry for the offtopic again, initially I wanted to leave only a small note to
the Ben's post. We need to move this discussion to the ath10k-devel list.
Regards,
Alex.

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Adrian Chadd]

On 25 November 2013 23:24, Alex Hacker <hacker@epn.ru> wrote:
> Open source community is a biggest of the biggest customers, isn't it? It is
> a huge market, I speak about millions of gadgets and plastic boxes working
> under some sort of Linux or BSD. Adrian, did you told something like that when
> worked for QCA? But IMO the reason is different. QCA prefers to close any
> access to a hardware, especially to non-standard PHY/Radio features. The same
> role be played by HAL in older Atheros chips.

Sure, but they're all initially sold to .. not us. :-)

They're sold to laptop, access point and (increasingly majority by
number) phones and tablets.

Those are the companies that you have to lobby in general to get
improved open source support for these kinds of things. Those are the
customers the hardware manufacturers will care about.

We in the open source community get that "for free" as a side effect
of someone else signing a purchase order for x million a year.

> Sorry for the offtopic again, initially I wanted to leave only a small note to
> the Ben's post. We need to move this discussion to the ath10k-devel list.
> Regards,
> Alex.



-adrian

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Trevor Cullen]

Hello

K2/AR9271 is limited to 8 nodes in AP mode due to RAM size imitation of
internal on-chip RAM (K2 does not use external RAM).

It was once suggested that, with a lot of work, the internal RAM might be
able to be used more efficiently to realise up to 16 nodes. But this was
deemed too much work in light of newer USB chipsets like WASP/AR9342 which
have no such limitations.

Sorry you need to look for AR9342 based USB dongle to get proper AP node
count as follows:-

WEP should be the same as Open, limited by AID field size, i.e. 128.
AES/TKIP is limited by key cache.
AES = 128 - 4 (reserved for WEP) - 2 (group keys) = 122
TKIP = 128/2 - 4 (reserved for WEP) - 2 (group keys) = 58

Trevor
 
-----Original Message-----
From: ath9k-devel-bounces@lists.ath9k.org
[mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Ben Greear
Sent: 22 November 2013 15:10
To: Oleksij Rempel
Cc: Gustavo Azambuja; ath9k-devel at venema.h4ckr.net
Subject: Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

On 11/22/2013 07:02 AM, Oleksij Rempel wrote:
> Am 22.11.2013 16:00, schrieb Ben Greear:
>> On 11/22/2013 06:47 AM, Oleksij Rempel wrote:
>>> Am 22.11.2013 15:40, schrieb Ben Greear:
>>>> On 11/22/2013 02:23 AM, Oleksij Rempel wrote:
>>>>> Am 20.11.2013 20:01, schrieb Gustavo Azambuja:
>>>>>> Ben, thanks for you reply.
>>>>>> I need to convert my rPi into a AP (is not an option a "real" AP) 
>>>>>> to get at less 30 stations. You know some way to get a list of 
>>>>>> devices/drivers can support this?
>>>>>
>>>>> It's all about USB, RAM and power.
>>>>> If you use usb to communicate with wireless hardware, then your 
>>>>> first problem is usb - it is too slow! Some times it is too slow 
>>>>> even for one connection. This is why we have usb wifi adapters 
>>>>> with internal cpu, ram and firmware (micro operation system). If 
>>>>> you wont to add more connections you will need more ram and may be 
>>>>> more cpu power. This will need more power from usb, which is 
>>>>> limited to 500mA.
>>>>> In this case, just take some AP, connect it over ethernet and you 
>>>>> will get same result.
>>>>
>>>> The RAM is certainly an issue, but just adding more stations should 
>>>> not have much CPU impact as the total throughput is unlikely to 
>>>> increase as more stations are added.
>>>>
>>>> Changing software to make better use of RAM is also unlikely to 
>>>> increase power usage, though adding more RAM to the hardware might.
>>>
>>> patches are welcome
>>
>> I'm sure :)
>>
>> My customers are all interested in /AC these days, so I'm putting my 
>> effort there.  If/when someone opens an /AC firmware to the public I 
>> will be all over it!
>
> AC?
>
>

802.11 ac, for instance ath10k.

Thanks,
Ben

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

_______________________________________________
ath9k-devel mailing list
ath9k-devel at lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Sujith Manoharan]

Trevor Cullen wrote:
> Hello
> 
> K2/AR9271 is limited to 8 nodes in AP mode due to RAM size imitation of
> internal on-chip RAM (K2 does not use external RAM).
> 
> It was once suggested that, with a lot of work, the internal RAM might be
> able to be used more efficiently to realise up to 16 nodes. But this was
> deemed too much work in light of newer USB chipsets like WASP/AR9342 which
> have no such limitations.
> 
> Sorry you need to look for AR9342 based USB dongle to get proper AP node
> count as follows:-

AR9342 based USB dongles are not sold in the retail market. The USB
reference design, UB124, is used in a few embedded TV products.

Sujith

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Trevor Cullen]

Alex/Ben,

Those 'selected customers' have to be really really big!

I've never seen it happen outside of this sadly.

QCA seem to be happy to leave the open community starved....

Trevor Cullen BSc (Hons) MIoD

-----Original Message-----
From: ath9k-devel-bounces@lists.ath9k.org
[mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Alex Hacker
Sent: 25 November 2013 10:53
To: Ben Greear
Cc: Gustavo Azambuja; ath9k-devel at venema.h4ckr.net
Subject: Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

QCA stated the firmware source can be opened for the "selected customers".
We need to know who and how select the customers. Can the open source
community be included in this category? Something hints me what it never
happens. :( _______________________________________________
ath9k-devel mailing list
ath9k-devel at lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Alex Hacker]

No problem... We only need to disassemble a bunch of xtensa code and hack it
whithout any support as always, as before. :)

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Trevor Cullen]

If you really want to get your hands on UB124 (AR9342) then we have them.
Currently for use with external antenna only - no on-board PCB antenna.

This is NOT a sales push but just an offer to help out.

Getting your hands on working drivers for this though could be problematical
- not an area I'm that very educated on - maybe the rest of the community
can comment?

Trevor
-----Original Message-----
From: Sujith Manoharan [mailto:sujith at msujith.org] 
Sent: 23 November 2013 01:35
To: Trevor Cullen
Cc: 'Ben Greear'; 'Oleksij Rempel'; 'Gustavo Azambuja';
ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

Trevor Cullen wrote:
> Hello
> 
> K2/AR9271 is limited to 8 nodes in AP mode due to RAM size imitation 
> of internal on-chip RAM (K2 does not use external RAM).
> 
> It was once suggested that, with a lot of work, the internal RAM might 
> be able to be used more efficiently to realise up to 16 nodes. But 
> this was deemed too much work in light of newer USB chipsets like 
> WASP/AR9342 which have no such limitations.
> 
> Sorry you need to look for AR9342 based USB dongle to get proper AP 
> node count as follows:-

AR9342 based USB dongles are not sold in the retail market. The USB
reference design, UB124, is used in a few embedded TV products.

Sujith

[ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

[Sujith Manoharan]

Trevor Cullen wrote:
> If you really want to get your hands on UB124 (AR9342) then we have them.
> Currently for use with external antenna only - no on-board PCB antenna.
> 
> This is NOT a sales push but just an offer to help out.
> 
> Getting your hands on working drivers for this though could be problematical
> - not an area I'm that very educated on - maybe the rest of the community
> can comment?

Currently, ath9k or ath9k_htc don't support UB124, which is a fullmac device with
many WLAN components offloaded to the firmware. There are internal, proprietary
drivers which do support UB124, though.

Sujith