Subject: Re: ath seems still buggy
To: Steven M. Bellovin <firstname.lastname@example.org>
From: Sam Leffler <email@example.com>
Date: 10/18/2005 19:26:43
Steven M. Bellovin wrote:
> In message <20051019012935.GA20196@panix.com>, Thor Lancelot Simon writes:
>>On Tue, Oct 18, 2005 at 11:11:39PM +0000, Marcin Jessa wrote:
>>>When it comes to the ath implementation for NetBSD it seems to be there
>>>just for the records.
>>>Sadly it looks like it can't be used for any serious purpose.
>>That's nonsense. I use it every day, in NetBSD-current, and it works
>>In fact, I'm typing this through a Soekris with an Atheros wireless
>>module in hostap mode right now.
> Sometimes it works well; other times, it doesn't. I put in many hours
> on a wireless connection in my house over the last week; except for
> eating my battery alive, it worked flawlessly. A month ago, I was
> completely unable to acquire carrier at a public hot spot, even though
> wlanctl said that I was receiving a strong signal.
> It's not useless, but in congested networks it can be pretty close to
> it. At the IETF meeting in Paris, I sometimes had to find a wired
> connection, because it either couldn't acquire or couldn't hold
> carrier. Beyond that, even when it's been working, I see frequent
> instances of carrier drop/carrier restore, with the laptop a meter from
> the access point. (Oddly enough, I did not see *anything* like that
> over this last week. Maybe recent changes have helped. I do note,
> though -- and I'm not the only one -- that my card is running at 36
> Mbps right now (on 802.11g), even though it's in its usual meter-away
Again, anectdotal reports are not helpful. You haven't even identified
what hardware you have or what version of the driver you're using.
There are known issues with "phantom beacon miss" interrupts on 5212
parts operating in station mode that I have workarounds for. These
typically occur during periods of heavy traffic but have also been
reported at other times. When you see a link state transition check
what athstats reports and see if the bmiss count is going up. In lieu
of that turn on state transition debugging in the net80211 layer to see
As to rate control one of the first things I noticed in working with
netbsd current is that the default tx rate control algorithm for ath is
still onoe and not sample. This is a likely a cause for significant
performance loss. However even the sample algorithm is suboptimal
compared to other algorithms. If you compare performance of ath parts
to the Atheros ndis driver you will see this quite clearly (though there
are many other factors). John Bickett has improvements to sample that
only exist right now in the linux code and need to be brought over.
Again, rather than kvetching that something doesn't work provide some