* [ath9k-devel] [PATCH] ath9k/rc.c: Change poll-interval to 2000 in ath9k-ratetables
2011-04-28 9:36 [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol Andreas Hofmann
@ 2011-04-28 9:36 ` Andreas Hofmann
2011-04-29 7:00 ` [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol Mohammed Shafi
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Andreas Hofmann @ 2011-04-28 9:36 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply related [flat|nested] 14+ messages in thread* [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol
2011-04-28 9:36 [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol Andreas Hofmann
2011-04-28 9:36 ` [ath9k-devel] [PATCH] ath9k/rc.c: Change poll-interval to 2000 in ath9k-ratetables Andreas Hofmann
@ 2011-04-29 7:00 ` Mohammed Shafi
2011-04-29 13:30 ` Andreas Hofmann
2011-04-29 7:19 ` Adrian Chadd
2011-04-29 11:20 ` Felix Fietkau
3 siblings, 1 reply; 14+ messages in thread
From: Mohammed Shafi @ 2011-04-29 7:00 UTC (permalink / raw)
To: ath9k-devel
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread* [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol
2011-04-29 7:00 ` [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol Mohammed Shafi
@ 2011-04-29 13:30 ` Andreas Hofmann
2011-04-29 13:36 ` Mohammed Shafi
0 siblings, 1 reply; 14+ messages in thread
From: Andreas Hofmann @ 2011-04-29 13:30 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol
2011-04-29 13:30 ` Andreas Hofmann
@ 2011-04-29 13:36 ` Mohammed Shafi
2011-04-29 13:37 ` Mohammed Shafi
0 siblings, 1 reply; 14+ messages in thread
From: Mohammed Shafi @ 2011-04-29 13:36 UTC (permalink / raw)
To: ath9k-devel
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol
2011-04-29 13:36 ` Mohammed Shafi
@ 2011-04-29 13:37 ` Mohammed Shafi
0 siblings, 0 replies; 14+ messages in thread
From: Mohammed Shafi @ 2011-04-29 13:37 UTC (permalink / raw)
To: ath9k-devel
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
>>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol
2011-04-28 9:36 [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol Andreas Hofmann
2011-04-28 9:36 ` [ath9k-devel] [PATCH] ath9k/rc.c: Change poll-interval to 2000 in ath9k-ratetables Andreas Hofmann
2011-04-29 7:00 ` [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol Mohammed Shafi
@ 2011-04-29 7:19 ` Adrian Chadd
2011-04-29 7:21 ` Mohammed Shafi
2011-04-29 11:20 ` Felix Fietkau
3 siblings, 1 reply; 14+ messages in thread
From: Adrian Chadd @ 2011-04-29 7:19 UTC (permalink / raw)
To: ath9k-devel
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol
2011-04-29 7:19 ` Adrian Chadd
@ 2011-04-29 7:21 ` Mohammed Shafi
2011-04-29 10:27 ` Adrian Chadd
0 siblings, 1 reply; 14+ messages in thread
From: Mohammed Shafi @ 2011-04-29 7:21 UTC (permalink / raw)
To: ath9k-devel
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol
2011-04-28 9:36 [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol Andreas Hofmann
` (2 preceding siblings ...)
2011-04-29 7:19 ` Adrian Chadd
@ 2011-04-29 11:20 ` Felix Fietkau
2011-04-29 13:31 ` Andreas Hofmann
3 siblings, 1 reply; 14+ messages in thread
From: Felix Fietkau @ 2011-04-29 11:20 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol
2011-04-29 11:20 ` Felix Fietkau
@ 2011-04-29 13:31 ` Andreas Hofmann
2011-04-29 13:35 ` Adrian Chadd
2011-04-29 19:07 ` Felix Fietkau
0 siblings, 2 replies; 14+ messages in thread
From: Andreas Hofmann @ 2011-04-29 13:31 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol
2011-04-29 13:31 ` Andreas Hofmann
@ 2011-04-29 13:35 ` Adrian Chadd
2011-04-29 19:07 ` Felix Fietkau
1 sibling, 0 replies; 14+ messages in thread
From: Adrian Chadd @ 2011-04-29 13:35 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ath9k-devel] [PATCH/RFC] ath9k PER/ratecontrol
2011-04-29 13:31 ` Andreas Hofmann
2011-04-29 13:35 ` Adrian Chadd
@ 2011-04-29 19:07 ` Felix Fietkau
1 sibling, 0 replies; 14+ messages in thread
From: Felix Fietkau @ 2011-04-29 19:07 UTC (permalink / raw)
To: ath9k-devel
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
^ permalink raw reply [flat|nested] 14+ messages in thread