LinuxLists.cc - [RFC] ath9k: remove ath9k_rate

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Felix Fietkau wrote:
> I'm pretty sure it's because the algorithm isn't designed to handle more
> rates. It's a step-up/step-down type algorithm, and those typically only
> work with a sorted rateset, preferably duplicate free.
>
> Minstrel_ht selects rates in a different way that doesn't have the same
> limitations, so it can use the full rateset.

Makes sense.

Sujith

2013-02-08 16:38:37

by Paul Stewart

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Could you share some of the test results? I know with ChromeOS when
we switched to 3.4, the first thing that tipped us off to the fact
that we had inadvertently switch to minstrel was that our RvR
throughput values had dropped significantly. Has anyone done an RvR
comparison between minstrel and the ath9k internal rate control
lately?

--
Paul

On Fri, Feb 8, 2013 at 6:16 AM, Felix Fietkau <[email protected]> wrote:
> On 2013-02-08 3:08 PM, Sujith Manoharan wrote:
>> Felix Fietkau wrote:
>>> In many tests throughput with ath9k_rate_control has been shown to be
>>> worse than with minstrel_ht (the mac8021 default RC).
>>>
>>> This module also has some other problems, like starting to use the
>>> highest possible rate early in the connection, causing problems with
>>> reliability of connection/authentication attempts.
>>>
>>> It also has a much more limited search space, ignoring many potentially
>>> useful rates, caused by the design decision to operate on a sorted rate
>>> set with the assumption that higher rates are always more unreliable
>>> than lower rates. In some scenarios this assumption is not true, and
>>> this can cause it to fall back to a really bad rate.
>>>
>>> minstrel_ht has been tested extensively in AP and client mode by lots of
>>> users (mostly in the OpenWrt project, where it has been the default for
>>> years).
>>
>> I don't think managed mode would have received much testing in OpenWRT.
> I know quite a few people that use directional links with 4-addr
> AP/Station. I also know a few people that put up some devices that roam
> between multiple APs. Obviously it doesn't receive as much testing as AP
> mode, but there are some active users stress testing it.
>
> - Felix
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2013-02-08 16:53:56

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-02-08 5:38 PM, Paul Stewart wrote:
> Could you share some of the test results? I know with ChromeOS when
> we switched to 3.4, the first thing that tipped us off to the fact
> that we had inadvertently switch to minstrel was that our RvR
> throughput values had dropped significantly. Has anyone done an RvR
> comparison between minstrel and the ath9k internal rate control
> lately?
Are you sure it was minstrel_ht, or could it also have been minstrel
(the legacy version)? I don't have any recent RvR test results, however
on every single link that I tested both rate control modules on (leaving
everything else unchanged), minstrel_ht got slightly better results.
Additionally, I occasionally get asked for help on debugging low
throughput issues, and many of the people asking me have reported that
simply switching to minstrel_ht fixed these issues in their tests.

I would also like to see some real RvR tests comparing both, preferably
before this gets merged, which is why I sent it as RFC.

- Felix

2013-02-28 05:10:20

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Felix Fietkau wrote:
> What was the distance and what was the rate used?

The station was about a meter away from the AP. I don't have the rcstats,
debugfs was compiled out. I'll rerun the test and post the results.

Sujith

2013-02-28 03:55:49

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Felix Fietkau wrote:
> I don't see the point in keeping that algorithm around. It has known
> design flaws that make it perform poorly in several scenarios, and
> fixing some of the flaws require basically rewriting it.

I ran some comparison throughput tests between minstrel_ht and ath9k RC
and minstrel showed lower numbers (~10Mbps difference). This is in a clean
environment (OTA). IMO, we can switch the default to minstrel_ht, but keep
the ath9k RC until the perf. gap is fixed. I think this was Google's concern too,
a drop in the average throughput. This was in the STA->AP direction.

In the AP->STA direction (AP: DB120, STA: AR9280), the numbers were really low.
The highest that I could see was ~165 Mbps, while with WNDR3700 (stock FW), the
average throughput was ~185 Mbps and an occasional high of 190 and above.

Sujith

2013-02-08 14:04:21

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-02-08 2:30 PM, Sujith Manoharan wrote:
> Felix Fietkau wrote:
>> In many tests throughput with ath9k_rate_control has been shown to be
>> worse than with minstrel_ht (the mac8021 default RC).
>>
>> This module also has some other problems, like starting to use the
>> highest possible rate early in the connection, causing problems with
>> reliability of connection/authentication attempts.
>>
>> It also has a much more limited search space, ignoring many potentially
>> useful rates, caused by the design decision to operate on a sorted rate
>> set with the assumption that higher rates are always more unreliable
>> than lower rates. In some scenarios this assumption is not true, and
>> this can cause it to fall back to a really bad rate.
>>
>> minstrel_ht has been tested extensively in AP and client mode by lots of
>> users (mostly in the OpenWrt project, where it has been the default for
>> years).
>>
>> The only advantage that ath9k_rate_control previously had over minstrel_ht
>> was the support for using CCK rates as fall back in case MCS rates got
>> too bad, but this has now also been taken care of.
>
> Various rates are marked as invalid in the ath9k rate control module. I don't
> know all the reasons, but the recommendation to disable certain rates came from
> the internal algorithms team. How will this be handled ?
I'm pretty sure it's because the algorithm isn't designed to handle more
rates. It's a step-up/step-down type algorithm, and those typically only
work with a sorted rateset, preferably duplicate free.

Minstrel_ht selects rates in a different way that doesn't have the same
limitations, so it can use the full rateset.

- Felix

2013-02-08 14:09:40

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Felix Fietkau wrote:
> In many tests throughput with ath9k_rate_control has been shown to be
> worse than with minstrel_ht (the mac8021 default RC).
>
> This module also has some other problems, like starting to use the
> highest possible rate early in the connection, causing problems with
> reliability of connection/authentication attempts.
>
> It also has a much more limited search space, ignoring many potentially
> useful rates, caused by the design decision to operate on a sorted rate
> set with the assumption that higher rates are always more unreliable
> than lower rates. In some scenarios this assumption is not true, and
> this can cause it to fall back to a really bad rate.
>
> minstrel_ht has been tested extensively in AP and client mode by lots of
> users (mostly in the OpenWrt project, where it has been the default for
> years).

I don't think managed mode would have received much testing in OpenWRT.

> The only advantage that ath9k_rate_control previously had over minstrel_ht
> was the support for using CCK rates as fall back in case MCS rates got
> too bad, but this has now also been taken care of.
>
> Signed-off-by: Felix Fietkau <[email protected]>

Acked-by: Sujith Manoharan <[email protected]>

Sujith

2013-02-28 03:24:58

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-02-28 3:21 AM, Adrian Chadd wrote:
> Why don't we just move the ath9k rate control code to another mac80211
> rate control module, so it's available to other devices?
>
> It may not be a bad idea to keep it around as a reference and for
> people to do comparisons against. It just seems silly to have a rate
> control framework and then not use it..
I don't see the point in keeping that algorithm around. It has known
design flaws that make it perform poorly in several scenarios, and
fixing some of the flaws require basically rewriting it.

- Felix

2013-02-08 13:32:11

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Felix Fietkau wrote:
> In many tests throughput with ath9k_rate_control has been shown to be
> worse than with minstrel_ht (the mac8021 default RC).
>
> This module also has some other problems, like starting to use the
> highest possible rate early in the connection, causing problems with
> reliability of connection/authentication attempts.
>
> It also has a much more limited search space, ignoring many potentially
> useful rates, caused by the design decision to operate on a sorted rate
> set with the assumption that higher rates are always more unreliable
> than lower rates. In some scenarios this assumption is not true, and
> this can cause it to fall back to a really bad rate.
>
> minstrel_ht has been tested extensively in AP and client mode by lots of
> users (mostly in the OpenWrt project, where it has been the default for
> years).
>
> The only advantage that ath9k_rate_control previously had over minstrel_ht
> was the support for using CCK rates as fall back in case MCS rates got
> too bad, but this has now also been taken care of.

Various rates are marked as invalid in the ath9k rate control module. I don't
know all the reasons, but the recommendation to disable certain rates came from
the internal algorithms team. How will this be handled ?

Sujith

2013-02-28 11:47:27

by Bob Copeland

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On Thu, Feb 28, 2013 at 04:24:49AM +0100, Felix Fietkau wrote:
> On 2013-02-28 3:21 AM, Adrian Chadd wrote:
> > It may not be a bad idea to keep it around as a reference and for
> > people to do comparisons against. It just seems silly to have a rate
> > control framework and then not use it..
> I don't see the point in keeping that algorithm around. It has known
> design flaws that make it perform poorly in several scenarios, and
> fixing some of the flaws require basically rewriting it.

The same could be said of PID...

--
Bob Copeland %% http://www.bobcopeland.com

2013-02-28 19:07:52

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-02-28 7:53 PM, Adrian Chadd wrote:
> On 28 February 2013 05:09, Felix Fietkau <[email protected]> wrote:
>
>>> The same could be said of PID...
>> I agree, we should remove that one as well.
>
> One of the advantages of having multiple RC modules - even if they're
> not longer optimal - is to keep the API honest. :-)
>
> I still keep onoe/amrr working in FreeBSD's ath(4) driver, primarily
> to make sure that I don't change the API without thinking too much
> about what other rate control modules do, but also to provide a
> simpler example of how the API works.
In that case I'd rather keep PID than the ath9k rate control. The ath9k
rate control is a horrible example of how to use the rate control API,
and fixing that is a waste of time in my opinion.
By the way, minstrel and minstrel_ht are two mostly separate
implementations using the same API, except for the fact that minstrel_ht
falls back to minstrel for legacy clients. So we already do have
multiple examples here :)

> Personally, I'd like to see more examples of rate control modules in
> LInux/FreeBSD, especially ones that start demanding more 802.11 state
> (ie, air-time QoS.)
Do you have any good ideas on what state information would be useful for
a rate control to demand?

- Felix

2013-02-28 04:32:12

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-02-28 4:54 AM, Sujith Manoharan wrote:
> Felix Fietkau wrote:
>> I don't see the point in keeping that algorithm around. It has known
>> design flaws that make it perform poorly in several scenarios, and
>> fixing some of the flaws require basically rewriting it.
>
> I ran some comparison throughput tests between minstrel_ht and ath9k RC
> and minstrel showed lower numbers (~10Mbps difference). This is in a clean
> environment (OTA). IMO, we can switch the default to minstrel_ht, but keep
> the ath9k RC until the perf. gap is fixed. I think this was Google's concern too,
> a drop in the average throughput. This was in the STA->AP direction.
What was the distance and what was the rate used?

> In the AP->STA direction (AP: DB120, STA: AR9280), the numbers were really low.
> The highest that I could see was ~165 Mbps, while with WNDR3700 (stock FW), the
> average throughput was ~185 Mbps and an occasional high of 190 and above.
Comparing against stock FW (especially with different devices) is not
useful, it could be anything.

- Felix

2013-02-28 02:21:47

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Why don't we just move the ath9k rate control code to another mac80211
rate control module, so it's available to other devices?

It may not be a bad idea to keep it around as a reference and for
people to do comparisons against. It just seems silly to have a rate
control framework and then not use it..

Adrian

2013-02-28 13:09:38

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-02-28 12:47 PM, Bob Copeland wrote:
> On Thu, Feb 28, 2013 at 04:24:49AM +0100, Felix Fietkau wrote:
>> On 2013-02-28 3:21 AM, Adrian Chadd wrote:
>> > It may not be a bad idea to keep it around as a reference and for
>> > people to do comparisons against. It just seems silly to have a rate
>> > control framework and then not use it..
>> I don't see the point in keeping that algorithm around. It has known
>> design flaws that make it perform poorly in several scenarios, and
>> fixing some of the flaws require basically rewriting it.
>
> The same could be said of PID...
I agree, we should remove that one as well.

- Felix

2013-02-28 18:53:34

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 28 February 2013 05:09, Felix Fietkau <[email protected]> wrote:

>> The same could be said of PID...
> I agree, we should remove that one as well.

One of the advantages of having multiple RC modules - even if they're
not longer optimal - is to keep the API honest. :-)

I still keep onoe/amrr working in FreeBSD's ath(4) driver, primarily
to make sure that I don't change the API without thinking too much
about what other rate control modules do, but also to provide a
simpler example of how the API works.

Personally, I'd like to see more examples of rate control modules in
LInux/FreeBSD, especially ones that start demanding more 802.11 state
(ie, air-time QoS.)

Adrian

2013-02-08 14:16:09

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-02-08 3:08 PM, Sujith Manoharan wrote:
> Felix Fietkau wrote:
>> In many tests throughput with ath9k_rate_control has been shown to be
>> worse than with minstrel_ht (the mac8021 default RC).
>>
>> This module also has some other problems, like starting to use the
>> highest possible rate early in the connection, causing problems with
>> reliability of connection/authentication attempts.
>>
>> It also has a much more limited search space, ignoring many potentially
>> useful rates, caused by the design decision to operate on a sorted rate
>> set with the assumption that higher rates are always more unreliable
>> than lower rates. In some scenarios this assumption is not true, and
>> this can cause it to fall back to a really bad rate.
>>
>> minstrel_ht has been tested extensively in AP and client mode by lots of
>> users (mostly in the OpenWrt project, where it has been the default for
>> years).
>
> I don't think managed mode would have received much testing in OpenWRT.
I know quite a few people that use directional links with 4-addr
AP/Station. I also know a few people that put up some devices that roam
between multiple APs. Obviously it doesn't receive as much testing as AP
mode, but there are some active users stress testing it.

- Felix

2013-02-27 19:01:06

by Luis R. Rodriguez

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On Fri, Feb 08, 2013 at 05:53:50PM +0100, Felix Fietkau wrote:
> On 2013-02-08 5:38 PM, Paul Stewart wrote:
> > Could you share some of the test results? I know with ChromeOS when
> > we switched to 3.4, the first thing that tipped us off to the fact
> > that we had inadvertently switch to minstrel was that our RvR
> > throughput values had dropped significantly. Has anyone done an RvR
> > comparison between minstrel and the ath9k internal rate control
> > lately?
> Are you sure it was minstrel_ht, or could it also have been minstrel
> (the legacy version)? I don't have any recent RvR test results, however
> on every single link that I tested both rate control modules on (leaving
> everything else unchanged), minstrel_ht got slightly better results.
> Additionally, I occasionally get asked for help on debugging low
> throughput issues, and many of the people asking me have reported that
> simply switching to minstrel_ht fixed these issues in their tests.
>
> I would also like to see some real RvR tests comparing both, preferably
> before this gets merged, which is why I sent it as RFC.

Paul, curious if you've run any tests?

Luis

2013-03-02 02:20:47

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Adrian Chadd wrote:
> (190mbit TCP on 2-stream? Damn. Looks like I have a little more
> optimisation to do in FreeBSD. I'm only hitting 160/170mbit TCP on
> AR9280<->AR9280 and AR9280<->AR9287. But I hit 220-240mbit UDP.)

I used a AR9462 card for this test. With AR9280/AR9287 I get abysmal
numbers with both rate control algorithms. Maybe something has regressed
in ath9k for the AR9002 family...

Sujith

2013-03-02 05:40:16

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 1 March 2013 18:19, Sujith Manoharan <[email protected]> wrote:
> Adrian Chadd wrote:
>> (190mbit TCP on 2-stream? Damn. Looks like I have a little more
>> optimisation to do in FreeBSD. I'm only hitting 160/170mbit TCP on
>> AR9280<->AR9280 and AR9280<->AR9287. But I hit 220-240mbit UDP.)
>
> I used a AR9462 card for this test. With AR9280/AR9287 I get abysmal
> numbers with both rate control algorithms. Maybe something has regressed
> in ath9k for the AR9002 family...

It's almost like we need some kind of lab space set aside for running
regression tests with all of the ath9k hardware ,dating back to
AR5416, with some automated testing rigs..

I have the hardware. Who wants to do it? :)

adrian

2013-03-01 11:18:03

by Mohammed Shafi

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Hi Felix,

On Fri, Mar 1, 2013 at 3:59 PM, Felix Fietkau <[email protected]> wrote:
> On 2013-03-01 11:22 AM, Adrian Chadd wrote:
>> On 1 March 2013 02:14, Felix Fietkau <[email protected]> wrote:
>>
>>>> Having access to schedule which peer and how much to send to each peer
>>>> would be nice. Stuff like "peer X only can have up to x ms in this WME
>>>> class this round", so you don't have a busy, close peer monopolising
>>>> the air. It also means you can start doing smart things with far away
>>>> peers who retransmit a lot - they're likely tying up a lot of airtime.
>>>>
>>>> None of this is new. It's just, you know, new to open source. :-)
>>
>>> In my opinion this doesn't really belong into a rate control module.
>>> There should be a tx scheduling API to take care of this. Before I
>>> implement something like this, I plan on exposing all per-station driver
>>> queues to mac80211. This is necessary for a few other things anyway,
>>> e.g. unifying software aggregation logic and fixing its buffer management.
>>
>> Sure, but then some more clever tricks end up being difficult to
>> implement. For example, knowing if a client is tying up too much
>> airtime at the given rate and whether to back them off for a bit. Or
>> to use smaller aggregation limits for certain clients because your'e
>> trying to be "fairer" when trying to keep latency low. That kind of
>> thing.
>>
>> I think "rate control" should likely be expanded to "tx scheduling" as
>> a whole, rather than sitting as a separate thing that just selects the
>> rate for a node who has already been chosen to transmit.
> Even with client airtime use, I still don't see how tx scheduling and
> rate control belong together. In my opinion, the rate selection should
> not be based on client airtime usage or the current load, as it can
> optimize for throughput/airtime ratio without it.
>

Algorithm folks and Engineers had spent considerable time on ath9k rate control.
Wouldn't be a great idea to remove it completely, We can have it optional.
With lot of throughput tests ran over internally and with the test
team verification,
it wouldn't be fair to throw it away.

--
thanks,
shafi

2013-03-01 10:09:34

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-03-01 2:23 AM, Sujith Manoharan wrote:
> Felix Fietkau wrote:
>> In that case I'd rather keep PID than the ath9k rate control. The ath9k
>> rate control is a horrible example of how to use the rate control API,
>> and fixing that is a waste of time in my opinion.
>
> I acked the earlier RFC patch to remove the ath9k RC as I assumed that minstrel_ht
> would perform adequately, if not better. But, there appear to be areas in which
> the numbers given by minstrel_ht are sub-optimal and which can be improved if we
> have something to compare it with. The ath9k RC code is crap, no doubt, but I'd
> prefer to have it for some time in the tree - we can switch the default RC to minstrel_ht
> by default.
Right, I will only submit this patch again once more performance tests
have been run. My own tests and tests of other people that I know of so
far have shown minstrel_ht to perform better than ath9k_rate_control,
whereas in your tests ath9k_rate_control seems to perform better. I'd
like to get some more details on your tests, e.g. raw numbers, rate
control stats, info on how much the throughput fluctuates, etc.

> Can you also explain how the ath9k RC uses the mac80211 API horribly ? The algorithm might be
> terribly implemented and the internal code nasty, but how does it violate the API ?
When I called it a horrible example, I was referring to the bad code
quality, not API violations. The API violations are only minor, there
are a few places left where the rate control code accesses struct ath_softc.

- Felix

2013-03-01 10:14:32

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-03-01 4:53 AM, Adrian Chadd wrote:
> On 28 February 2013 11:07, Felix Fietkau <[email protected]> wrote:
>
>>> Personally, I'd like to see more examples of rate control modules in
>>> LInux/FreeBSD, especially ones that start demanding more 802.11 state
>>> (ie, air-time QoS.)
>
>> Do you have any good ideas on what state information would be useful for
>> a rate control to demand?
>
> Well, there are already hooks to fake the TX time spent, right? Having
> both TX and RX busy times available to rate control so it can better
> schedule TX loads based on current RX workloads would be nice.
>
> Having access to schedule which peer and how much to send to each peer
> would be nice. Stuff like "peer X only can have up to x ms in this WME
> class this round", so you don't have a busy, close peer monopolising
> the air. It also means you can start doing smart things with far away
> peers who retransmit a lot - they're likely tying up a lot of airtime.
>
> None of this is new. It's just, you know, new to open source. :-)
In my opinion this doesn't really belong into a rate control module.
There should be a tx scheduling API to take care of this. Before I
implement something like this, I plan on exposing all per-station driver
queues to mac80211. This is necessary for a few other things anyway,
e.g. unifying software aggregation logic and fixing its buffer management.

- Felix

2013-03-01 15:35:26

by Ben Greear

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 03/01/2013 06:31 AM, Sujith Manoharan wrote:
> Felix Fietkau wrote:
>> What was the distance and what was the rate used?
>
> A distance of about a meter between the AP and STA.
>
> AP: DB120 - running an internal build.
> STA: WB222 - wireless-testing HEAD.
> Signal is about -43 dBm.
> Channel 40, HT40-
>
> I've attached sample runs with minstrel_ht and ath9k-rc. With minstrel_ht,
> the numbers fluctuate between 180 and 190 Mbps and the average throughput
> varies each time (185, 186 etc.). With ath9k-rc, it's 195+ always.

We can run some tests through attenuators today.

I assume UDP would be good, or is TCP traffic preferred?
(In our tests, we see significantly more throughput with
UDP than TCP, even when we hacked on TCP ack delay).

Is wireless-testing the preferred tree to test against?

Thanks,
Ben

>
> Sujith
>

--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com

2013-03-01 10:29:24

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-03-01 11:22 AM, Adrian Chadd wrote:
> On 1 March 2013 02:14, Felix Fietkau <[email protected]> wrote:
>
>>> Having access to schedule which peer and how much to send to each peer
>>> would be nice. Stuff like "peer X only can have up to x ms in this WME
>>> class this round", so you don't have a busy, close peer monopolising
>>> the air. It also means you can start doing smart things with far away
>>> peers who retransmit a lot - they're likely tying up a lot of airtime.
>>>
>>> None of this is new. It's just, you know, new to open source. :-)
>
>> In my opinion this doesn't really belong into a rate control module.
>> There should be a tx scheduling API to take care of this. Before I
>> implement something like this, I plan on exposing all per-station driver
>> queues to mac80211. This is necessary for a few other things anyway,
>> e.g. unifying software aggregation logic and fixing its buffer management.
>
> Sure, but then some more clever tricks end up being difficult to
> implement. For example, knowing if a client is tying up too much
> airtime at the given rate and whether to back them off for a bit. Or
> to use smaller aggregation limits for certain clients because your'e
> trying to be "fairer" when trying to keep latency low. That kind of
> thing.
>
> I think "rate control" should likely be expanded to "tx scheduling" as
> a whole, rather than sitting as a separate thing that just selects the
> rate for a node who has already been chosen to transmit.
Even with client airtime use, I still don't see how tx scheduling and
rate control belong together. In my opinion, the rate selection should
not be based on client airtime usage or the current load, as it can
optimize for throughput/airtime ratio without it.

- Felix

2013-03-01 21:28:12

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 1 March 2013 06:31, Sujith Manoharan <[email protected]> wrote:
> Felix Fietkau wrote:
>> What was the distance and what was the rate used?
>
> A distance of about a meter between the AP and STA.
>
> AP: DB120 - running an internal build.
> STA: WB222 - wireless-testing HEAD.
> Signal is about -43 dBm.
> Channel 40, HT40-
>
> I've attached sample runs with minstrel_ht and ath9k-rc. With minstrel_ht,
> the numbers fluctuate between 180 and 190 Mbps and the average throughput
> varies each time (185, 186 etc.). With ath9k-rc, it's 195+ always.

Right. And the reason that it fluctuates is quite likely because at
the higher MCS rates (6,7/14,15/22,23) the channel behaviour is not
consistent and there's varying levels of packet loss, so things
oscillate between a bunch of MCS rates there.

IIRC, the ath9k_rc algorithm is a lot more aggressive at sticking to a
fixed, working MCS rate.

(190mbit TCP on 2-stream? Damn. Looks like I have a little more
optimisation to do in FreeBSD. I'm only hitting 160/170mbit TCP on
AR9280<->AR9280 and AR9280<->AR9287. But I hit 220-240mbit UDP.)

Thanks,

Adrian

2013-03-02 20:23:44

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-03-01 3:31 PM, Sujith Manoharan wrote:
> Felix Fietkau wrote:
>> What was the distance and what was the rate used?
>
> A distance of about a meter between the AP and STA.
>
> AP: DB120 - running an internal build.
> STA: WB222 - wireless-testing HEAD.
> Signal is about -43 dBm.
> Channel 40, HT40-
>
> I've attached sample runs with minstrel_ht and ath9k-rc. With minstrel_ht,
> the numbers fluctuate between 180 and 190 Mbps and the average throughput
> varies each time (185, 186 etc.). With ath9k-rc, it's 195+ always.
I just sent some minstrel_ht improvements to linux-wireless@
Please test if they fix the throughput delta in your setup. In my tests
they visibly reduce the number of unnecessary fallbacks to lower rates.

Thanks,

- Felix

2013-03-03 04:00:16

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Felix Fietkau wrote:
> I just sent some minstrel_ht improvements to linux-wireless@
> Please test if they fix the throughput delta in your setup. In my tests
> they visibly reduce the number of unnecessary fallbacks to lower rates.

With the fixes, the avg. TX throughput crept up to 188 Mbps, but I ran
ath9k-rc once again and obtained 197 Mbps. There were lots of 200+ Mbps
max. throughput too.

This is not a synthetic benchmark with shield boxes, attenuators etc.,
just a simple over-the-air test with not much interference, so a gap of
~10 Mbps is somewhat surprising.

Sujith

2013-03-01 10:22:30

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 1 March 2013 02:14, Felix Fietkau <[email protected]> wrote:

>> Having access to schedule which peer and how much to send to each peer
>> would be nice. Stuff like "peer X only can have up to x ms in this WME
>> class this round", so you don't have a busy, close peer monopolising
>> the air. It also means you can start doing smart things with far away
>> peers who retransmit a lot - they're likely tying up a lot of airtime.
>>
>> None of this is new. It's just, you know, new to open source. :-)

> In my opinion this doesn't really belong into a rate control module.
> There should be a tx scheduling API to take care of this. Before I
> implement something like this, I plan on exposing all per-station driver
> queues to mac80211. This is necessary for a few other things anyway,
> e.g. unifying software aggregation logic and fixing its buffer management.

Sure, but then some more clever tricks end up being difficult to
implement. For example, knowing if a client is tying up too much
airtime at the given rate and whether to back them off for a bit. Or
to use smaller aggregation limits for certain clients because your'e
trying to be "fairer" when trying to keep latency low. That kind of
thing.

I think "rate control" should likely be expanded to "tx scheduling" as
a whole, rather than sitting as a separate thing that just selects the
rate for a node who has already been chosen to transmit.

Adrian

2013-03-01 03:53:56

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 28 February 2013 11:07, Felix Fietkau <[email protected]> wrote:

>> Personally, I'd like to see more examples of rate control modules in
>> LInux/FreeBSD, especially ones that start demanding more 802.11 state
>> (ie, air-time QoS.)

> Do you have any good ideas on what state information would be useful for
> a rate control to demand?

Well, there are already hooks to fake the TX time spent, right? Having
both TX and RX busy times available to rate control so it can better
schedule TX loads based on current RX workloads would be nice.

Having access to schedule which peer and how much to send to each peer
would be nice. Stuff like "peer X only can have up to x ms in this WME
class this round", so you don't have a busy, close peer monopolising
the air. It also means you can start doing smart things with far away
peers who retransmit a lot - they're likely tying up a lot of airtime.

None of this is new. It's just, you know, new to open source. :-)

Adrian

2013-03-01 01:24:40

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

Felix Fietkau wrote:
> In that case I'd rather keep PID than the ath9k rate control. The ath9k
> rate control is a horrible example of how to use the rate control API,
> and fixing that is a waste of time in my opinion.

I acked the earlier RFC patch to remove the ath9k RC as I assumed that minstrel_ht
would perform adequately, if not better. But, there appear to be areas in which
the numbers given by minstrel_ht are sub-optimal and which can be improved if we
have something to compare it with. The ath9k RC code is crap, no doubt, but I'd
prefer to have it for some time in the tree - we can switch the default RC to minstrel_ht
by default.

Can you also explain how the ath9k RC uses the mac80211 API horribly ? The algorithm might be
terribly implemented and the internal code nasty, but how does it violate the API ?

Sujith

2013-03-01 13:06:06

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-03-01 1:32 PM, Mohammed Shafi wrote:
> On Fri, Mar 1, 2013 at 5:01 PM, Felix Fietkau <[email protected]> wrote:
>> On 2013-03-01 12:18 PM, Mohammed Shafi wrote:
>>> Hi Felix,
>>>
>>> On Fri, Mar 1, 2013 at 3:59 PM, Felix Fietkau <[email protected]> wrote:
>>>> On 2013-03-01 11:22 AM, Adrian Chadd wrote:
>>>>> On 1 March 2013 02:14, Felix Fietkau <[email protected]> wrote:
>>>>>
>>>>>>> Having access to schedule which peer and how much to send to each peer
>>>>>>> would be nice. Stuff like "peer X only can have up to x ms in this WME
>>>>>>> class this round", so you don't have a busy, close peer monopolising
>>>>>>> the air. It also means you can start doing smart things with far away
>>>>>>> peers who retransmit a lot - they're likely tying up a lot of airtime.
>>>>>>>
>>>>>>> None of this is new. It's just, you know, new to open source. :-)
>>>>>
>>>>>> In my opinion this doesn't really belong into a rate control module.
>>>>>> There should be a tx scheduling API to take care of this. Before I
>>>>>> implement something like this, I plan on exposing all per-station driver
>>>>>> queues to mac80211. This is necessary for a few other things anyway,
>>>>>> e.g. unifying software aggregation logic and fixing its buffer management.
>>>>>
>>>>> Sure, but then some more clever tricks end up being difficult to
>>>>> implement. For example, knowing if a client is tying up too much
>>>>> airtime at the given rate and whether to back them off for a bit. Or
>>>>> to use smaller aggregation limits for certain clients because your'e
>>>>> trying to be "fairer" when trying to keep latency low. That kind of
>>>>> thing.
>>>>>
>>>>> I think "rate control" should likely be expanded to "tx scheduling" as
>>>>> a whole, rather than sitting as a separate thing that just selects the
>>>>> rate for a node who has already been chosen to transmit.
>>>> Even with client airtime use, I still don't see how tx scheduling and
>>>> rate control belong together. In my opinion, the rate selection should
>>>> not be based on client airtime usage or the current load, as it can
>>>> optimize for throughput/airtime ratio without it.
>>>>
>>>
>>> Algorithm folks and Engineers had spent considerable time on ath9k rate control.
>>> Wouldn't be a great idea to remove it completely, We can have it optional.
>>> With lot of throughput tests ran over internally and with the test
>>> team verification,
>>> it wouldn't be fair to throw it away.
>> Regardless of how much time was spent tuning it, it still has a really
>> bad design, bad implementation and a number of practical issues.
>> It seems to be tuned entirely for artificial benchmarks in clean air. It
>> also starts with a very high rate without having proven that it works.
>> I don't think anybody is going to fix all of these issues, and even if
>> somebody does, it would invalidate pretty much all of the tuning/testing
>> that went into this code.
>>
>
> We can certainly question the design and implementation, but it was proven
> to work well and had been tested by more hands(even with propitiatory stuff).
> Even if some one thinks it as bad, we should still allow it as an option.
> For instance if the environment is pretty good/pretty bad, we should give
> the users an option to choose between the two, that's why we should retain
> it.
I agree that we should keep it for a while, but we should probably
change the default soon. As for giving *users* the option of choosing
rate control based on the environment, I think it's a bad idea! Regular
users can't really be expected to know enough about the details of rate
control to make a meaningful decision, nor should they be. Simply being
lazy and telling every user to just test which one works better for them
is also a bad idea.

The default implementation needs to be good for all kinds of
environments. minstrel_ht is already tuned to work quite well in tough
environments with heavy interference, so closing the performance gap in
clean environments should be quite easy. The main thing I need to get
that done is good quality test feedback - something that I didn't get a
lot of, neither from users, nor from QCA.

> Further its been tested internally, by customers and more folks.
Right, and a few of those customers complained about bad performance
with ath9k, and also reported that switching to minstrel_ht fixed their
issues :)
Good to know that it's been tested, but where are the results? Who is
going to take care of the long standing *known* issues?
One of these issues (too high bitrate before rate feedback is available)
led to somebody from Google hacking up a crappy workaround in
wpa_supplicant that disables high bitrates during connect.

Saying that it has been tested does not necessarily imply that it's any
good or that it works properly in all normal scenarios ;)

> Its been also worked by some serious developers and Engineers.
Well, I do consider myself a serious developer and engineer as well :)

- Felix

2013-03-02 08:26:37

by Georgiewskiy Yuriy

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 2013-03-01 21:40 -0800, Adrian Chadd wrote Sujith Manoharan:

AC>On 1 March 2013 18:19, Sujith Manoharan <[email protected]> wrote:
AC>> Adrian Chadd wrote:
AC>>> (190mbit TCP on 2-stream? Damn. Looks like I have a little more
AC>>> optimisation to do in FreeBSD. I'm only hitting 160/170mbit TCP on
AC>>> AR9280<->AR9280 and AR9280<->AR9287. But I hit 220-240mbit UDP.)
AC>>
AC>> I used a AR9462 card for this test. With AR9280/AR9287 I get abysmal
AC>> numbers with both rate control algorithms. Maybe something has regressed
AC>> in ath9k for the AR9002 family...
AC>
AC>It's almost like we need some kind of lab space set aside for running
AC>regression tests with all of the ath9k hardware ,dating back to
AC>AR5416, with some automated testing rigs..

Think this is good idea, have same problem - no mo ~50 megabit on ar9002.

AC>I have the hardware. Who wants to do it? :)

C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE

2013-03-01 12:33:00

by Mohammed Shafi

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On Fri, Mar 1, 2013 at 5:01 PM, Felix Fietkau <[email protected]> wrote:
> On 2013-03-01 12:18 PM, Mohammed Shafi wrote:
>> Hi Felix,
>>
>> On Fri, Mar 1, 2013 at 3:59 PM, Felix Fietkau <[email protected]> wrote:
>>> On 2013-03-01 11:22 AM, Adrian Chadd wrote:
>>>> On 1 March 2013 02:14, Felix Fietkau <[email protected]> wrote:
>>>>
>>>>>> Having access to schedule which peer and how much to send to each peer
>>>>>> would be nice. Stuff like "peer X only can have up to x ms in this WME
>>>>>> class this round", so you don't have a busy, close peer monopolising
>>>>>> the air. It also means you can start doing smart things with far away
>>>>>> peers who retransmit a lot - they're likely tying up a lot of airtime.
>>>>>>
>>>>>> None of this is new. It's just, you know, new to open source. :-)
>>>>
>>>>> In my opinion this doesn't really belong into a rate control module.
>>>>> There should be a tx scheduling API to take care of this. Before I
>>>>> implement something like this, I plan on exposing all per-station driver
>>>>> queues to mac80211. This is necessary for a few other things anyway,
>>>>> e.g. unifying software aggregation logic and fixing its buffer management.
>>>>
>>>> Sure, but then some more clever tricks end up being difficult to
>>>> implement. For example, knowing if a client is tying up too much
>>>> airtime at the given rate and whether to back them off for a bit. Or
>>>> to use smaller aggregation limits for certain clients because your'e
>>>> trying to be "fairer" when trying to keep latency low. That kind of
>>>> thing.
>>>>
>>>> I think "rate control" should likely be expanded to "tx scheduling" as
>>>> a whole, rather than sitting as a separate thing that just selects the
>>>> rate for a node who has already been chosen to transmit.
>>> Even with client airtime use, I still don't see how tx scheduling and
>>> rate control belong together. In my opinion, the rate selection should
>>> not be based on client airtime usage or the current load, as it can
>>> optimize for throughput/airtime ratio without it.
>>>
>>
>> Algorithm folks and Engineers had spent considerable time on ath9k rate control.
>> Wouldn't be a great idea to remove it completely, We can have it optional.
>> With lot of throughput tests ran over internally and with the test
>> team verification,
>> it wouldn't be fair to throw it away.
> Regardless of how much time was spent tuning it, it still has a really
> bad design, bad implementation and a number of practical issues.
> It seems to be tuned entirely for artificial benchmarks in clean air. It
> also starts with a very high rate without having proven that it works.
> I don't think anybody is going to fix all of these issues, and even if
> somebody does, it would invalidate pretty much all of the tuning/testing
> that went into this code.
>

We can certainly question the design and implementation, but it was proven
to work well and had been tested by more hands(even with propitiatory stuff).
Even if some one thinks it as bad, we should still allow it as an option.
For instance if the environment is pretty good/pretty bad, we should give
the users an option to choose between the two, that's why we should retain
it. Further its been tested internally, by customers and more folks. Its been
also worked by some serious developers and Engineers.

--
thanks,
shafi

2013-03-01 14:33:30

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

root@linux-test ~# iperf -i1 -c 172.16.1.222 -t 120 -P 4
------------------------------------------------------------
Client connecting to 172.16.1.222, TCP port 5001
TCP window size: 22.9 KByte (default)
------------------------------------------------------------
[ 5] local 172.16.1.111 port 36820 connected with 172.16.1.222 port 5001
[ 4] local 172.16.1.111 port 36819 connected with 172.16.1.222 port 5001
[ 3] local 172.16.1.111 port 36821 connected with 172.16.1.222 port 5001
[ 6] local 172.16.1.111 port 36822 connected with 172.16.1.222 port 5001

685:[SUM] 0.0- 1.0 sec 21.0 MBytes 176 Mbits/sec
690:[SUM] 1.0- 2.0 sec 21.8 MBytes 182 Mbits/sec
695:[SUM] 2.0- 3.0 sec 21.8 MBytes 182 Mbits/sec
700:[SUM] 3.0- 4.0 sec 22.8 MBytes 191 Mbits/sec
705:[SUM] 4.0- 5.0 sec 22.5 MBytes 189 Mbits/sec
710:[SUM] 5.0- 6.0 sec 22.9 MBytes 192 Mbits/sec
715:[SUM] 6.0- 7.0 sec 22.2 MBytes 187 Mbits/sec
720:[SUM] 7.0- 8.0 sec 22.0 MBytes 185 Mbits/sec
725:[SUM] 8.0- 9.0 sec 23.1 MBytes 194 Mbits/sec
730:[SUM] 9.0-10.0 sec 21.9 MBytes 184 Mbits/sec
735:[SUM] 10.0-11.0 sec 22.5 MBytes 189 Mbits/sec
740:[SUM] 11.0-12.0 sec 22.1 MBytes 186 Mbits/sec
745:[SUM] 12.0-13.0 sec 22.5 MBytes 189 Mbits/sec
750:[SUM] 13.0-14.0 sec 23.0 MBytes 193 Mbits/sec
755:[SUM] 14.0-15.0 sec 21.5 MBytes 180 Mbits/sec
760:[SUM] 15.0-16.0 sec 22.5 MBytes 189 Mbits/sec
765:[SUM] 16.0-17.0 sec 22.8 MBytes 191 Mbits/sec
770:[SUM] 17.0-18.0 sec 22.8 MBytes 191 Mbits/sec
775:[SUM] 18.0-19.0 sec 21.9 MBytes 184 Mbits/sec
780:[SUM] 19.0-20.0 sec 21.1 MBytes 177 Mbits/sec
785:[SUM] 20.0-21.0 sec 22.8 MBytes 191 Mbits/sec
790:[SUM] 21.0-22.0 sec 22.5 MBytes 189 Mbits/sec
795:[SUM] 22.0-23.0 sec 22.5 MBytes 189 Mbits/sec
800:[SUM] 23.0-24.0 sec 22.6 MBytes 190 Mbits/sec
805:[SUM] 24.0-25.0 sec 21.5 MBytes 180 Mbits/sec
810:[SUM] 25.0-26.0 sec 22.1 MBytes 186 Mbits/sec
815:[SUM] 26.0-27.0 sec 22.1 MBytes 186 Mbits/sec
820:[SUM] 27.0-28.0 sec 21.6 MBytes 181 Mbits/sec
825:[SUM] 28.0-29.0 sec 22.6 MBytes 190 Mbits/sec
830:[SUM] 29.0-30.0 sec 23.0 MBytes 193 Mbits/sec
835:[SUM] 30.0-31.0 sec 22.8 MBytes 191 Mbits/sec
840:[SUM] 31.0-32.0 sec 22.6 MBytes 190 Mbits/sec
845:[SUM] 32.0-33.0 sec 21.9 MBytes 184 Mbits/sec
850:[SUM] 33.0-34.0 sec 21.6 MBytes 181 Mbits/sec
855:[SUM] 34.0-35.0 sec 22.9 MBytes 192 Mbits/sec
860:[SUM] 35.0-36.0 sec 22.0 MBytes 185 Mbits/sec
865:[SUM] 36.0-37.0 sec 22.6 MBytes 190 Mbits/sec
870:[SUM] 37.0-38.0 sec 22.2 MBytes 187 Mbits/sec
875:[SUM] 38.0-39.0 sec 22.5 MBytes 189 Mbits/sec
880:[SUM] 39.0-40.0 sec 21.9 MBytes 184 Mbits/sec
885:[SUM] 40.0-41.0 sec 22.6 MBytes 190 Mbits/sec
890:[SUM] 41.0-42.0 sec 22.2 MBytes 187 Mbits/sec
895:[SUM] 42.0-43.0 sec 21.9 MBytes 184 Mbits/sec
900:[SUM] 43.0-44.0 sec 22.4 MBytes 188 Mbits/sec
905:[SUM] 44.0-45.0 sec 20.5 MBytes 172 Mbits/sec
910:[SUM] 45.0-46.0 sec 22.4 MBytes 188 Mbits/sec
915:[SUM] 46.0-47.0 sec 23.0 MBytes 193 Mbits/sec
920:[SUM] 47.0-48.0 sec 21.8 MBytes 182 Mbits/sec
925:[SUM] 48.0-49.0 sec 22.2 MBytes 187 Mbits/sec
930:[SUM] 49.0-50.0 sec 22.4 MBytes 188 Mbits/sec
935:[SUM] 50.0-51.0 sec 22.4 MBytes 188 Mbits/sec
940:[SUM] 51.0-52.0 sec 23.1 MBytes 194 Mbits/sec
945:[SUM] 52.0-53.0 sec 22.4 MBytes 188 Mbits/sec
950:[SUM] 53.0-54.0 sec 22.6 MBytes 190 Mbits/sec
955:[SUM] 54.0-55.0 sec 22.8 MBytes 191 Mbits/sec
960:[SUM] 55.0-56.0 sec 22.4 MBytes 188 Mbits/sec
965:[SUM] 56.0-57.0 sec 22.5 MBytes 189 Mbits/sec
970:[SUM] 57.0-58.0 sec 23.0 MBytes 193 Mbits/sec
975:[SUM] 58.0-59.0 sec 22.1 MBytes 186 Mbits/sec
980:[SUM] 59.0-60.0 sec 21.8 MBytes 182 Mbits/sec
985:[SUM] 60.0-61.0 sec 21.6 MBytes 181 Mbits/sec
990:[SUM] 61.0-62.0 sec 22.6 MBytes 190 Mbits/sec
995:[SUM] 62.0-63.0 sec 22.1 MBytes 186 Mbits/sec
1000:[SUM] 63.0-64.0 sec 21.8 MBytes 182 Mbits/sec
1005:[SUM] 64.0-65.0 sec 22.2 MBytes 187 Mbits/sec
1010:[SUM] 65.0-66.0 sec 21.8 MBytes 182 Mbits/sec
1015:[SUM] 66.0-67.0 sec 22.2 MBytes 187 Mbits/sec
1020:[SUM] 67.0-68.0 sec 22.2 MBytes 187 Mbits/sec
1025:[SUM] 68.0-69.0 sec 23.2 MBytes 195 Mbits/sec
1030:[SUM] 69.0-70.0 sec 23.2 MBytes 195 Mbits/sec
1035:[SUM] 70.0-71.0 sec 22.5 MBytes 189 Mbits/sec
1040:[SUM] 71.0-72.0 sec 22.2 MBytes 187 Mbits/sec
1045:[SUM] 72.0-73.0 sec 22.0 MBytes 185 Mbits/sec
1050:[SUM] 73.0-74.0 sec 21.9 MBytes 184 Mbits/sec
1055:[SUM] 74.0-75.0 sec 22.5 MBytes 189 Mbits/sec
1060:[SUM] 75.0-76.0 sec 22.4 MBytes 188 Mbits/sec
1065:[SUM] 76.0-77.0 sec 22.6 MBytes 190 Mbits/sec
1070:[SUM] 77.0-78.0 sec 22.9 MBytes 192 Mbits/sec
1075:[SUM] 78.0-79.0 sec 22.1 MBytes 186 Mbits/sec
1080:[SUM] 79.0-80.0 sec 22.0 MBytes 185 Mbits/sec
1085:[SUM] 80.0-81.0 sec 21.9 MBytes 184 Mbits/sec
1090:[SUM] 81.0-82.0 sec 21.5 MBytes 180 Mbits/sec
1095:[SUM] 82.0-83.0 sec 22.4 MBytes 188 Mbits/sec
1100:[SUM] 83.0-84.0 sec 23.4 MBytes 196 Mbits/sec
1105:[SUM] 84.0-85.0 sec 22.0 MBytes 185 Mbits/sec
1110:[SUM] 85.0-86.0 sec 22.5 MBytes 189 Mbits/sec
1115:[SUM] 86.0-87.0 sec 22.8 MBytes 191 Mbits/sec
1120:[SUM] 87.0-88.0 sec 22.4 MBytes 188 Mbits/sec
1125:[SUM] 88.0-89.0 sec 22.1 MBytes 186 Mbits/sec
1130:[SUM] 89.0-90.0 sec 22.8 MBytes 191 Mbits/sec
1135:[SUM] 90.0-91.0 sec 21.4 MBytes 179 Mbits/sec
1140:[SUM] 91.0-92.0 sec 22.4 MBytes 188 Mbits/sec
1145:[SUM] 92.0-93.0 sec 22.9 MBytes 192 Mbits/sec
1150:[SUM] 93.0-94.0 sec 22.9 MBytes 192 Mbits/sec
1155:[SUM] 94.0-95.0 sec 23.4 MBytes 196 Mbits/sec
1160:[SUM] 95.0-96.0 sec 21.1 MBytes 177 Mbits/sec
1165:[SUM] 96.0-97.0 sec 22.0 MBytes 185 Mbits/sec
1170:[SUM] 97.0-98.0 sec 22.2 MBytes 187 Mbits/sec
1175:[SUM] 98.0-99.0 sec 22.5 MBytes 189 Mbits/sec
1180:[SUM] 99.0-100.0 sec 22.2 MBytes 187 Mbits/sec
1185:[SUM] 100.0-101.0 sec 22.4 MBytes 188 Mbits/sec
1190:[SUM] 101.0-102.0 sec 22.5 MBytes 189 Mbits/sec
1195:[SUM] 102.0-103.0 sec 23.0 MBytes 193 Mbits/sec
1200:[SUM] 103.0-104.0 sec 22.0 MBytes 185 Mbits/sec
1205:[SUM] 104.0-105.0 sec 22.0 MBytes 185 Mbits/sec
1210:[SUM] 105.0-106.0 sec 22.5 MBytes 189 Mbits/sec
1215:[SUM] 106.0-107.0 sec 22.1 MBytes 186 Mbits/sec
1220:[SUM] 107.0-108.0 sec 22.4 MBytes 188 Mbits/sec
1225:[SUM] 108.0-109.0 sec 22.8 MBytes 191 Mbits/sec
1230:[SUM] 109.0-110.0 sec 22.4 MBytes 188 Mbits/sec
1235:[SUM] 110.0-111.0 sec 22.2 MBytes 187 Mbits/sec
1240:[SUM] 111.0-112.0 sec 22.9 MBytes 192 Mbits/sec
1245:[SUM] 112.0-113.0 sec 23.1 MBytes 194 Mbits/sec
1250:[SUM] 113.0-114.0 sec 23.1 MBytes 194 Mbits/sec
1255:[SUM] 114.0-115.0 sec 21.8 MBytes 182 Mbits/sec
1260:[SUM] 115.0-116.0 sec 21.5 MBytes 180 Mbits/sec
1265:[SUM] 116.0-117.0 sec 22.0 MBytes 185 Mbits/sec
1270:[SUM] 117.0-118.0 sec 21.8 MBytes 182 Mbits/sec
1275:[SUM] 118.0-119.0 sec 23.1 MBytes 194 Mbits/sec
1283:[SUM] 119.0-120.0 sec 23.2 MBytes 195 Mbits/sec

1285:[SUM] 0.0-120.0 sec 2.62 GBytes 187 Mbits/sec

cat /sys/kernel/debug/ieee80211/phy3/netdev:wlan0/stations/00:03:7f:42:08:56/rc_stats

type rate throughput ewma prob this prob retry this succ/attempt success attempts
HT20/LGI MCS0 6.6 99.9 100.0 2 0( 0) 86 91
HT20/LGI MCS1 10.5 81.1 100.0 2 0( 0) 90 96
HT20/LGI MCS2 17.5 91.8 100.0 2 0( 0) 88 91
HT20/LGI MCS3 24.9 99.6 100.0 2 0( 0) 85 92
HT20/LGI MCS4 36.0 99.2 100.0 2 0( 0) 88 92
HT20/LGI MCS5 42.8 92.0 100.0 2 0( 0) 85 90
HT20/LGI MCS6 48.2 94.0 100.0 2 0( 0) 85 95
HT20/LGI MCS7 57.1 99.9 100.0 2 0( 0) 92 95
HT20/LGI MCS8 12.9 99.5 100.0 2 0( 0) 89 93
HT20/LGI MCS9 24.1 96.4 100.0 2 0( 0) 91 96
HT20/LGI MCS10 36.3 99.9 100.0 2 0( 0) 86 91
HT20/LGI MCS11 46.5 99.9 100.0 2 0( 0) 92 96
HT20/LGI MCS12 60.3 91.1 100.0 2 0( 0) 89 93
HT20/LGI MCS13 81.1 99.8 100.0 2 0( 0) 86 93
HT20/LGI MCS14 90.0 99.9 100.0 2 0( 0) 91 96
HT20/LGI MCS15 83.4 85.9 100.0 2 0( 0) 97 99
HT20/SGI MCS0 7.3 99.6 100.0 2 0( 0) 87 93
HT20/SGI MCS1 14.4 99.9 100.0 2 0( 0) 88 93
HT20/SGI MCS2 20.9 99.3 100.0 2 0( 0) 88 93
HT20/SGI MCS3 27.4 99.3 100.0 2 0( 0) 90 96
HT20/SGI MCS4 37.9 95.2 100.0 2 0( 0) 83 92
HT20/SGI MCS5 48.4 95.5 100.0 2 0( 0) 87 93
HT20/SGI MCS6 55.6 99.6 100.0 2 0( 0) 93 100
HT20/SGI MCS7 60.9 98.1 100.0 2 0( 0) 93 95
HT20/SGI MCS8 13.7 95.3 100.0 2 0( 0) 82 90
HT20/SGI MCS9 26.8 97.3 100.0 2 0( 0) 84 90
HT20/SGI MCS10 39.8 99.9 100.0 2 0( 0) 90 91
HT20/SGI MCS11 50.7 99.9 100.0 2 0( 0) 87 92
HT20/SGI MCS12 71.1 98.9 100.0 2 0( 0) 85 89
HT20/SGI MCS13 80.2 91.4 100.0 2 0( 0) 87 91
HT20/SGI MCS14 97.0 99.9 100.0 2 0( 0) 92 97
HT20/SGI MCS15 78.0 74.9 0.0 2 0( 0) 476 538
HT40/LGI MCS0 13.5 99.8 100.0 2 0( 0) 90 95
HT40/LGI MCS1 26.0 99.9 100.0 2 0( 0) 86 90
HT40/LGI MCS2 36.1 96.6 100.0 2 0( 0) 89 92
HT40/LGI MCS3 44.4 92.0 100.0 2 0( 0) 91 94
HT40/LGI MCS4 61.7 90.7 100.0 2 0( 0) 86 93
HT40/LGI MCS5 70.1 83.4 100.0 2 0( 0) 81 91
HT40/LGI MCS6 85.9 92.0 100.0 2 0( 0) 91 96
HT40/LGI MCS7 100.6 99.6 100.0 2 0( 0) 88 94
HT40/LGI MCS8 25.5 97.9 100.0 2 0( 0) 83 92
HT40/LGI MCS9 44.4 92.0 100.0 2 0( 0) 84 90
HT40/LGI MCS10 67.7 99.5 100.0 2 0( 0) 81 91
HT40/LGI MCS11 59.2 70.5 0.0 2 0( 0) 85 89
HT40/LGI MCS12 105.8 92.0 100.0 3 0( 0) 90 93
HT40/LGI MCS13 118.3 88.7 100.0 3 0( 0) 84 89
HT40/LGI MCS14 145.4 97.4 100.0 4 0( 0) 768 899
HT40/LGI MCS15 130.0 81.9 100.0 4 0( 0) 80856 88875
HT40/SGI MCS0 14.9 99.9 100.0 2 0( 0) 86 91
HT40/SGI MCS1 21.4 74.7 0.0 2 0( 0) 91 95
HT40/SGI MCS2 41.1 99.9 100.0 2 0( 0) 85 91
HT40/SGI MCS3 49.7 93.9 100.0 2 0( 0) 88 93
HT40/SGI MCS4 55.4 74.8 0.0 2 0( 0) 88 92
HT40/SGI MCS5 86.9 95.6 100.0 2 0( 0) 85 91
HT40/SGI MCS6 100.9 99.9 100.0 2 0( 0) 86 94
HT40/SGI P MCS7 106.9 98.4 100.0 5 0( 0) 4424 4980
HT40/SGI MCS8 28.6 99.8 100.0 2 0( 0) 87 89
HT40/SGI MCS9 45.1 85.3 100.0 2 0( 0) 85 91
HT40/SGI MCS10 72.6 98.1 100.0 2 0( 0) 88 90
HT40/SGI MCS11 89.9 98.9 100.0 2 0( 0) 80 88
HT40/SGI MCS12 121.9 98.7 100.0 3 0( 0) 86 92
HT40/SGI MCS13 132.4 94.0 100.0 3 0( 0) 85 89
HT40/SGI t MCS14 152.6 96.1 100.0 5 0( 0) 88243 96781
HT40/SGI T MCS15 161.8 97.1 100.0 5 1( 1) 1760690 1945362

Total packet count:: ideal 1934621 lookaround 5901
Average A-MPDU length: 4.4

cat /sys/kernel/debug/ieee80211/phy3/ath9k/xmit

BE BK VI VO

MPDUs Queued: 10 0 0 47
MPDUs Completed: 10 0 0 47
MPDUs XRetried: 0 0 0 0
Aggregates: 63956 0 0 0
AMPDUs Queued HW: 99 0 0 0
AMPDUs Queued SW: 1940401 0 0 0
AMPDUs Completed: 1940500 0 0 0
AMPDUs Retried: 14536 0 0 0
AMPDUs XRetried: 0 0 0 0
FIFO Underrun: 0 0 0 0
TXOP Exceeded: 0 0 0 0
TXTIMER Expiry: 0 0 0 0
DESC CFG Error: 0 0 0 0
DATA Underrun: 0 0 0 0
DELIM Underrun: 0 0 0 0
TX-Pkts-All: 1940510 0 0 47
TX-Bytes-All: 2980293154 0 0 2296
HW-put-tx-buf: 70308 0 0 47
HW-tx-start: 0 0 0 0
HW-tx-proc-desc: 70308 0 0 47
TX-Failed: 0 0 0 0

Attachments:

ath9k-rc.txt (9.82 kB)
ath9k-rc minstrel_ht.txt (15.74 kB)
minstrel_ht Download all attachments

2013-03-01 21:23:28

[permalink] [raw]

Subject: Re: [RFC] ath9k: remove ath9k_rate_control

On 1 March 2013 07:35, Ben Greear <[email protected]> wrote:

> I assume UDP would be good, or is TCP traffic preferred?
> (In our tests, we see significantly more throughput with
> UDP than TCP, even when we hacked on TCP ack delay).
>
> Is wireless-testing the preferred tree to test against?

Do both. Failures at higher MCS rates -> extra latency -> TCP backoff
-> crappier throughput.

Adrian

2013-03-01 11:31:12