[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Andreas Hofmann]

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] [PATCH] ath9k/rc.c: Change poll-interval to 2000 in ath9k-ratetables

[Andreas Hofmann]

Signed-off-by: Andreas Hofmann <andreas.hofmann@corscience.de>
---
 drivers/net/wireless/ath/ath9k/rc.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index 4c0d36a..0fce735 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -160,7 +160,7 @@ static const struct ath_rate_table ar5416_11na_ratetable = {
 		[67] = {  RC_HT_T_40, WLAN_RC_PHY_HT_40_TS_HGI, 450000,
 			346400, 23, 23, 4, 66, 67, 67 }, /* 450 Mb */
 	},
-	50,  /* probe interval */
+	2000,  /* probe interval */
 	WLAN_RC_HT_FLAG,  /* Phy rates allowed initially */
 };
 
@@ -316,7 +316,7 @@ static const struct ath_rate_table ar5416_11ng_ratetable = {
 		[71] = {  RC_HT_T_40, WLAN_RC_PHY_HT_40_TS_HGI, 450000,
 			346400, 23, 23, 8, 70, 71, 71 }, /* 450 Mb */
 	},
-	50,  /* probe interval */
+	2000,  /* probe interval */
 	WLAN_RC_HT_FLAG,  /* Phy rates allowed initially */
 };
 
@@ -341,7 +341,7 @@ static const struct ath_rate_table ar5416_11a_ratetable = {
 		{ RC_L_SDT, WLAN_RC_PHY_OFDM, 54000, /* 54 Mb */
 			29300, 7, 108, 4},
 	},
-	50,  /* probe interval */
+	2000,  /* probe interval */
 	0,   /* Phy rates allowed initially */
 };
 
-- 
1.7.1

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Mohammed Shafi]

On Thu, Apr 28, 2011 at 3:06 PM, Andreas Hofmann
<andreas.hofmann@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%).

hi,
           I don't know much about rate control, but this probe
interval 50 should have been fixed by the team which had formulated
this algorithm and I hope it might definitely have some meaning.
*Its true that increasing the probe interval will definitely improve
Video traffic(based on some inputs from an Engineer) but it looks 2s
is too high for the probe interval.
*when the channel conditions are poor (or) when the range is high, its
important that the rate control gets down into some lower rate as
quick as possible  but when we have 2seconds won't it affect that?

thanks,
shafi
>
> 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 at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Adrian Chadd]

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.hofmann@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 at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Mohammed Shafi]

On Fri, Apr 29, 2011 at 12:49 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Felix is the better person to speak to, as he coded up minstrel (and I
> guess you're using that, right?)

no ath9k rate control.

>
> Felix, is your thesis online?
>
>
> Adrian
>
> On 28 April 2011 17:36, Andreas Hofmann <andreas.hofmann@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 at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Adrian Chadd]

On 29 April 2011 15:21, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:

> no ath9k rate control.

Where's that hiding in the source tree?


adrian

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Felix Fietkau]

On 2011-04-28 11:36 AM, Andreas Hofmann 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%).
You could try using minstrel_ht instead of the ath9k rate control. 
People have told me that it produces much lower PER, it might help for 
both performance and reliability of your video transmission.

- Felix

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Mohammed Shafi]

On Fri, Apr 29, 2011 at 3:57 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 29 April 2011 15:21, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
>
>> no ath9k rate control.
>
> Where's that hiding in the source tree?

Adrian,

wireless-testing/drivers/net/wireless/ath/ath9k$ vi rc.c
wireless-testing/drivers/net/wireless/ath/ath9k$ vi rc.h

thanks,
shafi

>
>
> adrian
>

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Andreas Hofmann]

Hi Mohammed,

On 29.04.2011 09:00, Mohammed Shafi wrote:
> hi,
>            I don't know much about rate control, but this probe
> interval 50 should have been fixed by the team which had formulated
> this algorithm and I hope it might definitely have some meaning.
> *Its true that increasing the probe interval will definitely improve
> Video traffic(based on some inputs from an Engineer) but it looks 2s
> is too high for the probe interval.
> *when the channel conditions are poor (or) when the range is high, its
> important that the rate control gets down into some lower rate as
> quick as possible  but when we have 2seconds won't it affect that?

I did not do extensive testing with different values for the interval,
only 1 second, 2 seconds and 5 seconds. From these values, 2 secs
yielded the best results. From my understanding, the interval only
controls probing rates higher than the current rate, not falling back to
lower ratesn.In that case, a higher interval would actually be better,
since unnecessary packet drops due to too frequent use of MCSs not
suited for the channel would be reduced.

Kind regards,
 Andreas

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Andreas Hofmann]

Hi Felix,

On 29.04.2011 13:20, Felix Fietkau wrote:
> On 2011-04-28 11:36 AM, Andreas Hofmann wrote:
> You could try using minstrel_ht instead of the ath9k rate control.
> People have told me that it produces much lower PER, it might help for
> both performance and reliability of your video transmission.

I did try that and it performed better than the default
ath9k-ratecontrol, but with focus on PER, the slowed down
ath9k-ratecontrol gave even better results. I did not inspect the
performance regarding maximum data rate during testing, though.

Kind regards,
 Andreas

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Adrian Chadd]

On 29 April 2011 21:31, Andreas Hofmann <andreas.hofmann@corscience.de> wrote:

> I did try that and it performed better than the default
> ath9k-ratecontrol, but with focus on PER, the slowed down
> ath9k-ratecontrol gave even better results. I did not inspect the
> performance regarding maximum data rate during testing, though.

Would you mind summarising some of the test situations and results?
I'm interested in rate control stuff too; I'm about to start working
on that in FreeBSD in preparation for TX aggregation support.


Adrian

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Mohammed Shafi]

On Fri, Apr 29, 2011 at 7:00 PM, Andreas Hofmann
<andreas.hofmann@corscience.de> wrote:
> Hi Mohammed,
>
> On 29.04.2011 09:00, Mohammed Shafi wrote:
>> hi,
>> ? ? ? ? ? ?I don't know much about rate control, but this probe
>> interval 50 should have been fixed by the team which had formulated
>> this algorithm and I hope it might definitely have some meaning.
>> *Its true that increasing the probe interval will definitely improve
>> Video traffic(based on some inputs from an Engineer) but it looks 2s
>> is too high for the probe interval.
>> *when the channel conditions are poor (or) when the range is high, its
>> important that the rate control gets down into some lower rate as
>> quick as possible ?but when we have 2seconds won't it affect that?
>
> I did not do extensive testing with different values for the interval,
> only 1 second, 2 seconds and 5 seconds. From these values, 2 secs
> yielded the best results. From my understanding, the interval only
> controls probing rates higher than the current rate, not falling back to
> lower ratesn.In that case, a higher interval would actually be better,
> since unnecessary packet drops due to too frequent use of MCSs not
> suited for the channel would be reduced.

yes you are correct, falling back does requires that probe interval. thanks!

regards,
shafi

>
> Kind regards,
> ?Andreas
>

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Mohammed Shafi]

On Fri, Apr 29, 2011 at 7:06 PM, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> On Fri, Apr 29, 2011 at 7:00 PM, Andreas Hofmann
> <andreas.hofmann@corscience.de> wrote:
>> Hi Mohammed,
>>
>> On 29.04.2011 09:00, Mohammed Shafi wrote:
>>> hi,
>>> ? ? ? ? ? ?I don't know much about rate control, but this probe
>>> interval 50 should have been fixed by the team which had formulated
>>> this algorithm and I hope it might definitely have some meaning.
>>> *Its true that increasing the probe interval will definitely improve
>>> Video traffic(based on some inputs from an Engineer) but it looks 2s
>>> is too high for the probe interval.
>>> *when the channel conditions are poor (or) when the range is high, its
>>> important that the rate control gets down into some lower rate as
>>> quick as possible ?but when we have 2seconds won't it affect that?
>>
>> I did not do extensive testing with different values for the interval,
>> only 1 second, 2 seconds and 5 seconds. From these values, 2 secs
>> yielded the best results. From my understanding, the interval only
>> controls probing rates higher than the current rate, not falling back to
>> lower ratesn.In that case, a higher interval would actually be better,
>> since unnecessary packet drops due to too frequent use of MCSs not
>> suited for the channel would be reduced.
>
> yes you are correct, falling back does requires that probe interval. thanks!
sorry I mean't 'does not requires'
>
> regards,
> shafi
>
>>
>> Kind regards,
>> ?Andreas
>>
>

[ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol

[Felix Fietkau]

On 2011-04-29 3:31 PM, Andreas Hofmann wrote:
> Hi Felix,
>
> On 29.04.2011 13:20, Felix Fietkau wrote:
>>  On 2011-04-28 11:36 AM, Andreas Hofmann wrote:
>>  You could try using minstrel_ht instead of the ath9k rate control.
>>  People have told me that it produces much lower PER, it might help for
>>  both performance and reliability of your video transmission.
>
> I did try that and it performed better than the default
> ath9k-ratecontrol, but with focus on PER, the slowed down
> ath9k-ratecontrol gave even better results. I did not inspect the
> performance regarding maximum data rate during testing, though.
What kind of PER are you looking for? Just the one in the rate control 
stats, or are you getting any excessive retries during your tests?
Are you using any specific measurements in your app?

- Felix