Hi, Derek
thanks for the suggestion, minstrel stats is shown below.
In brief, rate control itself looks OK and it chose 54 or 48Mbps
most of the time. ( BTW, my card is based on AR5414 )
but, it looks like that packets were queued at the
forwarding node (ath5k node) by some reason and delivered to
the destination without being dropped. the board is Ubiquity RS-Pro.
but huge size of tx queue in ath5k ? mac80211 or above layer (packet
scheduler) ?
therefore, the issues are 1. why so slow before going out to air
2. why packets are not dropped and queued long time ..
now I can not say these are ath5k issues... rather this might be
issues around PCI/DMA.. You do not have this kind of problem, don't
you ?.
In testing these calibration issues, minstrel is your friend. Minstrel
reports what rates are tried, and what rates succeededd.
If throughput decreases after a softwar change, check the minstrel stats.
Is minstrel trying on all rates??
<sample config> distance between (2) and (3) is about 30cm
(1)PC(iperf client) --> (2)Ubiquity RS-Pro(ath5k) --> (3)Ubiquity
RS-Pro(ath5k) --> (4)PC(iperf server)
iperf flow is (1) -> (4)
When iperf (15Mbps UDP 30 secs) completed, the minstrel stats at (2) shows
most of the xmits were over 54Mbs or 48Bps ,but receiving throughput at
(4) was around 9Mbps
<< minstrel stats at (2) >>
rate throughput ewma prob this prob this succ/attempt
success atte
mpts
1 0.8 92.4 100.0 0( 0)
70 70
2 1.8 95.7 100.0 0( 0)
13 13
5.5 4.8 95.7 100.0 0( 0)
12 12
11 9.1 95.7 100.0 0( 0)
11 11
6 5.4 95.7 100.0 0( 0)
11 11
9 8.0 95.7 100.0 0( 0)
13 13
12 10.6 95.6 100.0 0( 0)
162 163
18 15.5 95.7 100.0 0( 0)
11 11
24 20.3 95.7 100.0 0( 0)
11 11
36 29.1 95.7 100.0 0( 0)
11 11
tP 48 37.8 96.9 100.0 0( 0)
15 16
T 54 41.5 95.6 95.7 68( 71)
22250 23397
Total packet count:: ideal 2462 lookaround 129
Note: CPU utilization (checked by TOP) at (2) was so less than 10%
while this iperf test ran .
<< iperf client at (1) >>
r...@taka248:/var/www# iperf -c 192.168.1.243 -u -t 30 -b 15M
------------------------------------------------------------
Client connecting to 192.168.1.243, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 107 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.98.248 port 33525 connected with 192.168.1.243 port 5001
[ 3] *0.0-30.0 sec* 53.6 MBytes 15.0 Mbits/sec
[ 3] Sent 38267 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries.
<< iperf cserver at (4) >>
t...@tkaiso-242:~$ iperf -s -u -i 3.0
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 110 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.243 port 5001 connected with 192.168.98.248 port 33525
[ ID] Interval Transfer Bandwidth Jitter Lost/Total
Datagrams
[ 3] 0.0- 3.0 sec 2.82 MBytes 7.88 Mbits/sec 0.683 ms 0/ 2010 (0%)
[ 3] 3.0- 6.0 sec 2.99 MBytes 8.36 Mbits/sec 0.695 ms 0/ 2133 (0%)
[ 3] 6.0- 9.0 sec 3.16 MBytes 8.83 Mbits/sec 0.410 ms 0/ 2253 (0%)
[ 3] 9.0-12.0 sec 3.21 MBytes 8.98 Mbits/sec 0.349 ms 0/ 2290 (0%)
[ 3] 12.0-15.0 sec 3.21 MBytes 8.97 Mbits/sec 0.745 ms 0/ 2289 (0%)
[ 3] 15.0-18.0 sec 3.11 MBytes 8.69 Mbits/sec 0.606 ms 0/ 2216 (0%)
[ 3] 18.0-21.0 sec 3.11 MBytes 8.69 Mbits/sec 0.390 ms 0/ 2216 (0%)
[ 3] 21.0-24.0 sec 3.10 MBytes 8.67 Mbits/sec 0.411 ms 0/ 2213 (0%)
[ 3] 24.0-27.0 sec 3.19 MBytes 8.91 Mbits/sec 0.472 ms 0/ 2274 (0%)
[ 3] 27.0-30.0 sec 3.10 MBytes 8.68 Mbits/sec 0.590 ms 0/ 2214 (0%)
[ 3] 30.0-33.0 sec 3.33 MBytes 9.32 Mbits/sec 0.415 ms 0/ 2378 (0%)
[ 3] 33.0-36.0 sec 3.25 MBytes 9.07 Mbits/sec 0.529 ms 0/ 2315 (0%)
[ 3] 36.0-39.0 sec 3.26 MBytes 9.11 Mbits/sec 0.618 ms 0/ 2325 (0%)
[ 3] 39.0-42.0 sec 3.26 MBytes 9.11 Mbits/sec 0.466 ms 0/ 2325 (0%)
[ 3] 42.0-45.0 sec 3.16 MBytes 8.82 Mbits/sec 0.318 ms 0/ 2251 (0%)
[ 3] 45.0-48.0 sec 3.16 MBytes 8.83 Mbits/sec 0.781 ms 0/ 2253 (0%)
[ 3] 48.0-51.0 sec 3.11 MBytes 8.69 Mbits/sec 0.755 ms 0/ 2217 (0%)
[ 3] 0.0-51.1 sec 53.6 MBytes 8.80 Mbits/sec 0.448 ms 0/38266 (0%)
[ 3] 0.0-51.1 sec 1 datagrams received out-of-order
read failed: Connection refused
==> whuuum.. this shows the receiver kept on receiving for 51 seconds
while the sender completed its xmit at 30 seconds.
38266 pkts were received while 38267 pkts were xmitted by the
sender.. this is UDP, not TCP ..
thanks
Takayuki Kaiso
Hi,
it helped in 11g for us.
Prevoius to the patch, Minstrel reported that 36Mbit/sec was optimal.
Even though the boxes were adjacent to each other.
Madwifi would have acieved 54 in that configuration.
With the patch, both boxes did 54.
In testing these calibration issues, minstrel is your friend. Minstrel
reports what rates are tried, and what rates succeededd.
If throughput decreases after a softwar change, check the minstrel stats.
Is minstrel trying on all rates??
Derek.
On Fri, 20 Nov 2009, 海藻敬之 wrote:
Hi, Lukas and Nick
I'm sending my own patch in a hope it will finally make it through.
Thanks.
I did brief test with the patch and those test results show the
throughput issues (receiving throughput of ath5k) was fixed. It's
so great.
Thanks a lot, Lukas. (but with my cases, the problem was for 11g
not for 11a )
--
*****************************************
株式会社 シンクチューブ
海藻 敬之 tka...@thinktube.com
〒658-0032 神戸市東灘区向洋町中６－９ KFMビル 4E-10
Phone: 078-857-8390
Fax: 078-857-8389
www.thinktube.com
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
