DWL-G520 low signal, low speed

[Sam Leffler]

soralx at cydem.org wrote:
>>>>> I have a problem with my wifi DWL G520 atheros chip based card...
>>>>> I have low signal only 20-30% and also a low speed 5-11
>>>>> Mbit/s..router is only 1-2 m away from me and with gentoo I have
>>>>> 90% signal strength..I'm using FreeBSD 6.2 PRERELEASE
> 
> Same thing here, folks. When using the 'if_ath' module (or compiling the
> driver into kernel -- doesn't matter), the reported signal strength
> (via `ifconfig ath0 up && ifconfig ath0 scan`) is about 20:0 to 30:0
> (whatever the units are?), depending on spatial orientation, and being
> positioned ~10m away from the base station. The 'media:' quickly
> degrades to 'DS/1Mbps'. Measurement of the signal strength with notebook
> relocated right near the transceiver yield values of 50-60 units (noise
> has the value of '0' all the time).

Noise floor is not uniformly reported outside the driver, hence it is 0
according to the tools your using.  Signal strength is the raw rssi
coming off the card averaged over the last 10 frames.  This is the
receive signal strength in approximately 1/2 dBm units relative to the
current noise floor.  Correlating that to physical units is hard.  About
all you can do is consider that the rssi values coming out of the
hardware are in the range 0..63.  rssi values >~15 should support
reasonable communication.

Transmit speeds are mainly a property of the transmit rate control
algorithm.  You haven't indicated what you are using but presumably it
is sample and it is known to be very sensitive to changes in rssi.  That
is a design flaw (maybe even a bug but noone seems to dig for these issues).

Given an rssi of 20-30 I would expect to see upstream tcp netperf
results through a reasonable AP on the order of 8-15 Mb/s to a station
1-hop past the ap.  But that depends on many factors such as the ap and
the antenna's.

> 
> Perhaps the ndisulator is being overly optimistic, but it reports S:N
> of ~140:0 when away from the transiever, and ~160:0 when near. ifconfig
> says that media is OFDM/54Mbps. I says that probably the units are
> totally arbitrary, or the ndis driver is just being piss-proud [i.e.,
> exaggerating a little, and his signal is not really that big] ;)

ndis is useless in this area.  Comparing it's operation to ath is also
rarely meaningful as the ndis driver includes certain features that the
native driver does not (e.g. s/w tx retry and support for xr
mode--useful only when talking to an Atheros AP).

> 
> Now, I didn't do any real performance comparison yet (ath vs ndis), but
> I can say this: ath performance seems to me rather disappointing -- the
> carrier gets lost from time to time, range is not impressive (or am i
> just expecting too much?), there's absolutely no reception without
> antenna connected (I believe this isn't right), etc...

I've not recently tested the particular chip in the DWL-G520 but in the
past it's been ok.  If I recall correctly it's used in at least one
widely distributed commercial product using freebsd and my driver.  What
is going on here is unclear and is par for the course--diagnosing
wireless problems can be very hard and snapshots of data are rarely
meaningful.  What you need to do to get a baseline is isolate the
stations and run tests at each tx rate and w/ a fixed/known attenuation.
 You measure throughput and verify the system is doing what is expected
(this is called a waterfall test and is usually done with stations wired
together in separate rf isolation chambers).  Past that you need to test
how the system behaves in the face of noise.  All of this has been done
repeatedly for this stuff and I have confidence in it.

There are ways to diagnose what is going on such as locking the transmit
rate and running unidirectional blast tests to measure packet error
rate.  These can identify whether problems are on the sending or
receiving side.

> 
> I don't have much time to look into the issue now, but if someone will
> suggest how to do some advanced testing (at almost a step-by-step
> level), I would do that.

See above.

	Sam