[ath9k-devel] 2.6.28-rc7-wl

[Luis R. Rodriguez <lrodriguez@atheros.com>]

On Fri, Dec 05, 2008 at 05:01:53PM -0800, Brian wrote:
> 
> 
> Luis,
> > So do some other test -- run bitorrent, or iperf. That should rule out
> > ath9k.
> >
> Yes I was trying that, in the process of setting up ftp.
> 
> > To test if its NX try testing it over a wired ethernet connection.
> >
> Yes, I should have thought of that, however I have problems with my eth0
> port.
> 
> Anyway while looking around the nomachine site I found that my version
> of NX was pretty old. So I downloaded the latest.
> 
> Some observations
> 
> 1) I have been up for over an hour on NX

Lets stop talking about NX.

> 2) The number of errors being generated  are a LOT less, I am collecting
> stats.
> 3) I have changed the bandwidth back to 20mhz so I am only getting 54Mbs
> at the moment.

You should be able to get more than 54Mbps on HT20 (802.11n HT20),
the theoretical max for HT20 with short guard interval is 144 Mbit/s,
the theoretical max for HT20 with long guard interval is 130 Mbps/s --
using only 2 stream. Your card should be 2-stream. For details of
how to get this information please see:

http://wireless.kernel.org/en/developers/Documentation/ieee80211/802.11n#MCSRates

This doesn't mean you should get these, but it means the card can use
these target rates for TX / RX, the actual throughput values seen will
be different but can be higher than 54Mbps. Just to give you an idea
with 802.11g I usually get highest about 24Mbps in practice.

Please run tests with UDP and TCP with iperf. You can do with by setting
an iperf server with a station connected via Gibabit ethernet on the AP
and then having the iperf client send data to the station. Do this then
the other way around, having the iperf server on the wireless station and
have the station send data to you.

Right now we're running some interoperability tests with different APs
so we should hopefully start seeing issues perhaps users are reporting
that we are not. What AP do you have?

> So the main reason I upgraded was because I felt that NX was causing the
> large number of TX/RX errors. I think has proved correct, but I will not
> know for sure until I put the bandwidth back up to 40mhz.

It seems easier to run long tests with things like iperf no?

> If this proves to be correct then I think the driver has a problem as
> there is no way that errors should cause such a hard lockup.
> So my question is how does the driver handle the fact that packets go
> missing?

You mean that didn't get on the other end? It retransmits.

> Or is this problem handled further up in the tcp stack.

If the wireless frame didn't get to the AP the AP doesn't send an ACK
and the STA retries. If using 802.11n AMPDU (the usual case for
aggregation) then the STA will issue a block ack request, send data
the AP sends a Block ACK in which it has a bitmap which indicates which
frames went through and which never reached the AP. The STA then
retransmits the frames that the bitmap indicates failed.

TCP is upper layer, so that's separate, but you can still have TCP
retransmissions.

  Luis