On Sat, Jan 25, 2014 at 05:36:55PM +0100, Márton Drótos wrote:
> This is a high power card, with 25dBm output power @802.11g 6Mbit and 22dBm
> @802.11g 54Mbit, and is connected to a pair of 8dBi omnidirectional antennae.
> However, both its range and its signal level at the same distance is similar
> to
> those of my generic wireless router provided by my ISP. An other interesting
> aspect is that when I connect to it either with an Android phone or with a
> laptop (Kubuntu or Linux Mint), they correctly connect with 802.11g 54Mbit,
> but
> tend to randomly downgrade the connection to as low as 802.11g 1Mbit, despite
> the fact that they are in less than 2m distance with direct visibility to the
> antennae. Using wget on the laptop, I couldn't get transfer speeds above
> ~1.5MBps (~12Mbit).
I'm seeing similar behaviour with any card. OpenBSD access points
always hover between 5 and 1 Mbit for me, no matter if it's
ral or ath or athn or urtwn or...
I believe the rate adaptation code decides to drop performance
in noisy environments (i.e. most major cities where virtually
every flat is now hosting an access point on the 2.4Ghz band).
But I'm speculating and haven't truely investigated this yet.
If you're interested in digging into this, you could study
ieee80211_rssadapt.h and ieee80211_rssadapt.c, and figure out if the
algorithm and its implementation are accurate (I wouldn't rule out
bugs in this code), and if there are better alternatives we could use.
Dragonflybsd have done some work in this area, and I would bet Linux
and FreeBSD have done so, too.
As to the rest of your questions:
> Is this the correct behaviour?
> Is it normal to have this amount of errors?
> Is there any oddity here?
I don't really know.
> During initialization, the card is reset multiple times ("needs a full
> reset"),
> is this normal?
This is normal. athn currently resets the chip when switching channels.
The linux ath9k driver has a fast path for this where it doesn't
do a full reset. But our athn driver doesn't do that at present.
And I'm not even sure it's worth doing.
> I don't see any reference of the Tx power/gain or Rx gain settings in the
> logs.
> How could I check if the card is performing as intended?
Depends on what you want to measure and under which conditions.
Range? Packets per seconds? With/without much interference?
All these factors influence each other. Wireless performance is generally
a lot harder to measure than wired. Just because it says 54Mbit/s on the
box doesn't mean you'll get that. Radio is a shared medium.
Of course, if Linux or other BSDs give you better wireless performance
during testing, it may well be that their driver or wireless stack is
doing things we could do as well.
But someone (you?) will have to dig into this and fix it, or nothing
will change. Slow wifi is better than no wifi at all, so I'm trying
every now and then to enhance our wifi driver support, which has started
falling behind badly since Damien left the project. But I cannot spend
much of my time on this. I'm willing to help where possible, of course.
> Furthermore, there seems to be a lot of CRC errors in the log, and "beacon
> stuck" messages. Is this normal?
Again, no idea, unfortunately.
Perhaps if you nicely asked Atheros for hardware documentation they
would mail it to us on a pink pidgin and we could try find an answer
in these docs?
