[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Alan]

Can anybody give me a status report on the current state of ath9k?
I know the one shipped with kernel 2.6.33.2 is working without major
issues with 802.11g because I'm using it.
But what is the status of 802.11n?
What is the status of multiple ssids? Can I configure more than one in
master mode?

I'm asking because I'm about to set up an AP to be considered
production level, and having 802.11n and two ssids (one open for
guests, one encrypted for intended users) would be great.
Should I stick to the version provided with the current kernel or
should I use compat-wireless?
Should I wait for the next kernel to be released with a major
breakthrough in ath9k? (judging by the mailing list activity, it seems
so).
Hardware is AR5008 (dual band, 3 antennas).

Thanks a lot!

Alan

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Daniel Yingqiang Ma]

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Peter Stuge]

Alan wrote:
> Should I wait for the next kernel to be released with a major
> breakthrough in ath9k? (judging by the mailing list activity, it
> seems so).
> Hardware is AR5008 (dual band, 3 antennas).

I don't consider ath9k on AR5008 to be at production level for STA
with wireless-testing as of a week ago, but AP performance may be
different.


//Peter

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Björn Smedman]

On Thu, May 6, 2010 at 6:35 PM, Peter Stuge <peter@stuge.se> wrote:
> I don't consider ath9k on AR5008 to be at production level for STA
> with wireless-testing as of a week ago, but AP performance may be
> different.

I've been running ath9k in a production network (AP mode) for the last
year or so, but unfortunately have to concur: ath9k is not production
ready.

The frustrating part is it doesn't really seem to be stabilizing. For
example the latest "stable" OpenWRT branch (backfire) is currently
based on compat-wireless from 2010-04-28 and a recent git snapshot of
hostapd (and I guess there is good reason). That's just not workable
from a production point of view.

So question is how do we get it to production quality? I think we need
more focus on stable branches that are maintained and
stress/interoperability tested, but I'm far from the expert here. What
is the official plan?

/Bj?rn

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Felix Fietkau]

On 08.05.2010, at 01:59, Bj?rn Smedman <bjorn.smedman@venatech.se>  
wrote:

> On Thu, May 6, 2010 at 6:35 PM, Peter Stuge <peter@stuge.se> wrote:
>> I don't consider ath9k on AR5008 to be at production level for STA
>> with wireless-testing as of a week ago, but AP performance may be
>> different.
>
> I've been running ath9k in a production network (AP mode) for the last
> year or so, but unfortunately have to concur: ath9k is not production
> ready.
>
> The frustrating part is it doesn't really seem to be stabilizing. For
> example the latest "stable" OpenWRT branch (backfire) is currently
> based on compat-wireless from 2010-04-28 and a recent git snapshot of
> hostapd (and I guess there is good reason). That's just not workable
> from a production point of view.
>
> So question is how do we get it to production quality? I think we need
> more focus on stable branches that are maintained and
> stress/interoperability tested, but I'm far from the expert here. What
> is the official plan?
I think what we're doing now is working well enough. The reason why I  
picked the bleeding edge snapshot of compat-wireless for the stable  
branch of OpenWrt is that it fixes a large number of critical bugs.  
However, none of the bugs that I was working on fixing in ath9k were  
regressions.
I think ath9k (and the linux wireless subsystem in general) has had  
very few regressions over time, even in the wireless-testing tree, so  
I see no point in adding more stable branching to the mix.
The compat-wireless snapshot that is in OpenWrt right now has been  
tested on quite a few APs in production use, and while it's not  
perfect, it's in better shape than anything we had before.
Client connections are no longer dropping all the time, the Rx and Tx  
path seems to no longer get stuck, descriptor corruption seems to be  
gone completely - these were all issues that were present in ath9k  
from the beginning, but were fixed recently.
The reason these were not fixed earlier is that other bugs were in the  
way, but that does not imply that the development process is  
ineffective for stabilization.

- Felix 

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Björn Smedman]

2010/5/8 Felix Fietkau <nbd@nbd.name>:
> I think what we're doing now is working well enough. The reason why I picked
> the bleeding edge snapshot of compat-wireless for the stable branch of
> OpenWrt is that it fixes a large number of critical bugs. However, none of
> the bugs that I was working on fixing in ath9k were regressions.
> I think ath9k (and the linux wireless subsystem in general) has had very few
> regressions over time, even in the wireless-testing tree, so I see no point
> in adding more stable branching to the mix.

Good point, they are not often regressions.

> The compat-wireless snapshot that is in OpenWrt right now has been tested on
> quite a few APs in production use, and while it's not perfect, it's in
> better shape than anything we had before.
> Client connections are no longer dropping all the time, the Rx and Tx path
> seems to no longer get stuck, descriptor corruption seems to be gone
> completely - these were all issues that were present in ath9k from the
> beginning, but were fixed recently.

Agree. I definitely don't want to belittle the progress that is being
made. I see some really good patches going in, quite a few of them
signed off by you. Thanx for that.

> The reason these were not fixed earlier is that other bugs were in the way,
> but that does not imply that the development process is ineffective for
> stabilization.

I guess you are right here too: my problem is not really with the
regressions, and branching won't fix the preexisting bugs. I think
it's mostly psychology. When I'm about to update to a bleeding edge
snapshot that is only a few days old I get nervous. I have hundreds of
people using those APs and they have every chipset imaginable on their
side. It feels like a recipe for disaster to update from a patched
development snapshot a few months old to another one that is only days
old.

Any guess when I will be able to run ath9k "as is" from a mainline
kernel along with a stable hostapd release?

/Bj?rn

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Pavel Roskin]

On Sun, 2010-05-09 at 13:28 +0200, Bj?rn Smedman wrote:

> I guess you are right here too: my problem is not really with the
> regressions, and branching won't fix the preexisting bugs. I think
> it's mostly psychology. When I'm about to update to a bleeding edge
> snapshot that is only a few days old I get nervous. I have hundreds of
> people using those APs and they have every chipset imaginable on their
> side. It feels like a recipe for disaster to update from a patched
> development snapshot a few months old to another one that is only days
> old.

That's not a psychological problem, that's risk management.  The more is
at stake, the more testing you need.

> Any guess when I will be able to run ath9k "as is" from a mainline
> kernel along with a stable hostapd release?

I believe you should be able to do that now.  If some important bug
stands in the way, you can ask it to be backported to the stable series.

You should actually prefer stable kernels because there is a procedure
in place that ensures that fixes go to the stable kernels.  There are
also many users of stable kernels, which provides for some testing.

-- 
Regards,
Pavel Roskin

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Luis R. Rodriguez]

On Fri, May 07, 2010 at 04:59:02PM -0700, Bj?rn Smedman wrote:
> On Thu, May 6, 2010 at 6:35 PM, Peter Stuge <peter@stuge.se> wrote:
> > I don't consider ath9k on AR5008 to be at production level for STA
> > with wireless-testing as of a week ago, but AP performance may be
> > different.
> 
> I've been running ath9k in a production network (AP mode) for the last
> year or so, but unfortunately have to concur: ath9k is not production
> ready.

I think it is a good time to highlight once again that Atheros has supported
anything >= AR9280 with actual staff and good commitment. Our resources are
limited though so we can only focus on a set of chipsets. The AR5008 and AR9001
family are those unfortunate families which did not get as much attention and
love.

So if you want production material support you should use >= AR9280 or
be willing to grind in as the older families *are* supported but with
limited attention and resources, more with the help of the community.

I hope this helps making choices on chipsets.

  Luis

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Daniel Yingqiang Ma]

Could you clarify a little more about the AR9160? Is it also an
unfortunate one as well?
It seems we have been unlucky to choose this one...

Thanks,
-Daniel

2010/5/11 Luis R. Rodriguez <lrodriguez@atheros.com>:
> On Fri, May 07, 2010 at 04:59:02PM -0700, Bj?rn Smedman wrote:
>> On Thu, May 6, 2010 at 6:35 PM, Peter Stuge <peter@stuge.se> wrote:
>> > I don't consider ath9k on AR5008 to be at production level for STA
>> > with wireless-testing as of a week ago, but AP performance may be
>> > different.
>>
>> I've been running ath9k in a production network (AP mode) for the last
>> year or so, but unfortunately have to concur: ath9k is not production
>> ready.
>
> I think it is a good time to highlight once again that Atheros has supported
> anything >= AR9280 with actual staff and good commitment. Our resources are
> limited though so we can only focus on a set of chipsets. The AR5008 and AR9001
> family are those unfortunate families which did not get as much attention and
> love.
>
> So if you want production material support you should use >= AR9280 or
> be willing to grind in as the older families *are* supported but with
> limited attention and resources, more with the help of the community.
>
> I hope this helps making choices on chipsets.
>
> ?Luis
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Luis R. Rodriguez]

On Tue, May 11, 2010 at 01:02:44AM -0700, Daniel Yingqiang Ma wrote:
> Could you clarify a little more about the AR9160? Is it also an
> unfortunate one as well?
> It seems we have been unlucky to choose this one...

AR9160 is part of the AR9100 family.

  Luis

[ath9k-devel] Current state of ath9k in linux release and compat-wireless

[Xianghua Xiao]

On Tue, May 11, 2010 at 11:25 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Tue, May 11, 2010 at 01:02:44AM -0700, Daniel Yingqiang Ma wrote:
>> Could you clarify a little more about the AR9160? Is it also an
>> unfortunate one as well?
>> It seems we have been unlucky to choose this one...
>
> AR9160 is part of the AR9100 family.
>
> ?Luis
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

This is indeed unfortunate, AR9280+ is geared towards laptops with
PCIe, most embedded products nowadays are still using minipci and
there are many AR9100 modules on the market.

Xianghua