From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luis R. Rodriguez Date: Fri, 5 Dec 2008 17:16:48 -0800 Subject: [ath9k-devel] 2.6.28-rc7-wl In-Reply-To: <4939CF01.9070103@astronomicalresearchaustralia.org> References: <43e72e890812031414m6a5782e7ga8eed8d91fe056b2@mail.gmail.com> <49370F49.2090602@astronomicalresearchaustralia.org> <20081204023228.GT6522@tesla> <49378DCB.3080401@astronomicalresearchaustralia.org> <20081204191933.GB5970@tesla> <49385507.3090705@astronomicalresearchaustralia.org> <20081204224300.GN5970@tesla> <493869E1.60207@astronomicalresearchaustralia.org> <20081205022853.GO5970@tesla> <4939CF01.9070103@astronomicalresearchaustralia.org> Message-ID: <20081206011648.GF5926@tesla> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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