Felix is the better person to speak to, as he coded up minstrel (and I guess you're using that, right?)
Felix, is your thesis online? Adrian On 28 April 2011 17:36, Andreas Hofmann <andreas.hofm...@corscience.de> wrote: > > Hello folks, > > I am currently running wireless video transmissions over RTP, using 2 > embedded linux devices with kernel 2.6.37 and AR9280 wireless-cards. The > link was not reliable enough and I found out that a small change to the > ratecontrol-algorithm improves the situation. Now I want to notice other > people, who might have the same problem and request for comments on > that change. > > I noticed that the connection was rather error-prone, when the slightest > change to the wireless-channel was made (e.g. waving around in the area > around the antennas) picture errors were becoming visible. Also tests > with iperf over UDP confirmed that the PER on the wireless link was > quite high (sometimes over 3%). > > When looking at the debugfs-output, my suspicion was that the packet > errors were caused due to frequent switching between different > MCSs. Here is an example iperf result with at -64 dBm signal strength: > > # iperf -c 192.168.50.2 -u -b 50m -n 100m > ------------------------------------------------------------ > Client connecting to 192.168.50.2, UDP port 5001 > Sending 1470 byte datagrams > UDP buffer size: 124 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.50.1 port 47997 connected with 192.168.50.2 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-22.3 sec 100 MBytes 37.6 Mbits/sec > [ 3] Sent 71332 datagrams > [ 3] Server Report: > [ 3] 0.0-22.3 sec 98.4 MBytes 37.0 Mbits/sec 0.450 ms 1128/71331 (1.6%) > [ 3] 0.0-22.3 sec 1 datagrams received out-of-order > > Here is also the debugfs rc_stats output: > > HT40 0 13.5: 0 0 0 0 > HT40 1 27.5: 0 0 0 0 > HT40 2 40.5: 0 0 0 0 > HT40 3 54.0: 0 0 0 0 > HT40 4 81.5: 1 0 0 0 > HT40 5 108.0: 0 0 0 0 > HT40 6 121.5: 0 0 0 0 > HT40 7 135.0: 0 0 0 0 > HT40 7 150.0: 0 0 0 0 > HT40 8 27.0: 0 0 0 0 > HT40 9 54.0: 0 0 0 0 > HT40 10 81.0: 0 0 0 0 > HT40 11 108.0: 980 16 2 7 > HT40 12 162.0: 9040 499 20 13 > HT40 13 216.0: 14386 1131 196 4 > HT40 14 243.0: 17058 1685 220 10 > HT40 15 270.0: 12355 1589 235 2 > > > > I noticed in the ath-ratecontrol-implementation, that a rather short > interval for MCS probing is used by default, other MCSs are probed > every 50 ms. Changing that interval in the rate-table to a higher value > (2000 ms) did lower the PER. Video errors were significantly reduced and > iperf-tests confirmed a PER constantly under 1%. However, on links with > lower quality/signal strength, the overall achieved data rate was > lowered as well, since the algorithm does not try to go for higher rates > as agressively. On good links the maximum rate is reached nevertheless. > > Here is a corresponding iperf result at -64 dBm signal strength (exactly the > same setup as with the previous test, only different poll-interval): > > # iperf -c 192.168.50.2 -u -b 50m -n 100m > ------------------------------------------------------------ > Client connecting to 192.168.50.2, UDP port 5001 > Sending 1470 byte datagrams > UDP buffer size: 124 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.50.1 port 50212 connected with 192.168.50.2 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-24.5 sec 100 MBytes 34.2 Mbits/sec > [ 3] Sent 71332 datagrams > [ 3] Server Report: > [ 3] 0.0-24.4 sec 99.3 MBytes 34.1 Mbits/sec 0.512 ms 476/71331 (0.67%) > [ 3] 0.0-24.4 sec 1 datagrams received out-of-order > > Debugfs rc_stats output: > > HT40 0 13.5: 0 0 0 0 > HT40 1 27.5: 0 0 0 0 > HT40 2 40.5: 0 0 0 0 > HT40 3 54.0: 0 0 0 0 > HT40 4 81.5: 1 0 0 0 > HT40 5 108.0: 0 0 0 0 > HT40 6 121.5: 0 0 0 0 > HT40 7 135.0: 0 0 0 0 > HT40 7 150.0: 0 0 0 0 > HT40 8 27.0: 0 0 0 0 > HT40 9 54.0: 0 0 0 0 > HT40 10 81.0: 0 0 0 0 > HT40 11 108.0: 0 4 2 12 > HT40 12 162.0: 1 4 2 11 > HT40 13 216.0: 7274 10 2 5 > HT40 14 243.0: 22383 147 14 6 > HT40 15 270.0: 37154 1024 88 6 > > > Is this an elegant solution or does the short default-interval have some > deeper > purpose which I am missing? > > Kind regards, > Andreas > _______________________________________________ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
