2004-12-08 17:34:36 +00:00
|
|
|
/*-
|
2017-11-27 14:52:40 +00:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
|
|
|
|
|
*
|
2008-04-20 20:35:46 +00:00
|
|
|
* Copyright (c) 2004-2008 Sam Leffler, Errno Consulting
|
2004-12-08 17:34:36 +00:00
|
|
|
* Copyright (c) 2004 Video54 Technologies, Inc.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer,
|
2007-06-06 15:49:16 +00:00
|
|
|
* without modification.
|
2004-12-08 17:34:36 +00:00
|
|
|
* 2. Redistributions in binary form must reproduce at minimum a disclaimer
|
|
|
|
|
* similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
|
|
|
|
|
* redistribution must be conditioned upon including a substantially
|
|
|
|
|
* similar Disclaimer requirement for further binary redistribution.
|
|
|
|
|
*
|
|
|
|
|
* NO WARRANTY
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
|
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
|
|
|
|
|
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
|
|
|
|
|
* THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
|
|
|
|
|
* OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
|
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
|
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
|
|
|
|
|
* IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
|
|
|
|
|
* THE POSSIBILITY OF SUCH DAMAGES.
|
|
|
|
|
*
|
|
|
|
|
* $FreeBSD$
|
|
|
|
|
*/
|
|
|
|
|
#ifndef _ATH_RATECTRL_H_
|
|
|
|
|
#define _ATH_RATECTRL_H_
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Interface definitions for transmit rate control modules for the
|
|
|
|
|
* Atheros driver.
|
|
|
|
|
*
|
|
|
|
|
* A rate control module is responsible for choosing the transmit rate
|
|
|
|
|
* for each data frame. Management+control frames are always sent at
|
|
|
|
|
* a fixed rate.
|
|
|
|
|
*
|
|
|
|
|
* Only one module may be present at a time; the driver references
|
|
|
|
|
* rate control interfaces by symbol name. If multiple modules are
|
|
|
|
|
* to be supported we'll need to switch to a registration-based scheme
|
|
|
|
|
* as is currently done, for example, for authentication modules.
|
|
|
|
|
*
|
|
|
|
|
* An instance of the rate control module is attached to each device
|
|
|
|
|
* at attach time and detached when the device is destroyed. The module
|
|
|
|
|
* may associate data with each device and each node (station). Both
|
|
|
|
|
* sets of storage are opaque except for the size of the per-node storage
|
|
|
|
|
* which must be provided when the module is attached.
|
|
|
|
|
*
|
|
|
|
|
* The rate control module is notified for each state transition and
|
|
|
|
|
* station association/reassociation. Otherwise it is queried for a
|
|
|
|
|
* rate for each outgoing frame and provided status from each transmitted
|
|
|
|
|
* frame. Any ancillary processing is the responsibility of the module
|
|
|
|
|
* (e.g. if periodic processing is required then the module should setup
|
|
|
|
|
* it's own timer).
|
|
|
|
|
*
|
|
|
|
|
* In addition to the transmit rate for each frame the module must also
|
|
|
|
|
* indicate the number of attempts to make at the specified rate. If this
|
|
|
|
|
* number is != ATH_TXMAXTRY then an additional callback is made to setup
|
|
|
|
|
* additional transmit state. The rate control code is assumed to write
|
|
|
|
|
* this additional data directly to the transmit descriptor.
|
|
|
|
|
*/
|
|
|
|
|
struct ath_softc;
|
|
|
|
|
struct ath_node;
|
|
|
|
|
struct ath_desc;
|
|
|
|
|
|
|
|
|
|
struct ath_ratectrl {
|
|
|
|
|
size_t arc_space; /* space required for per-node state */
|
|
|
|
|
};
|
|
|
|
|
/*
|
|
|
|
|
* Attach/detach a rate control module.
|
|
|
|
|
*/
|
|
|
|
|
struct ath_ratectrl *ath_rate_attach(struct ath_softc *);
|
|
|
|
|
void ath_rate_detach(struct ath_ratectrl *);
|
|
|
|
|
|
2011-11-08 01:35:05 +00:00
|
|
|
#define ATH_RC_NUM 4
|
|
|
|
|
|
|
|
|
|
#define ATH_RC_DS_FLAG 0x01 /* dual-stream rate */
|
|
|
|
|
#define ATH_RC_CW40_FLAG 0x02 /* use HT40 */
|
|
|
|
|
#define ATH_RC_SGI_FLAG 0x04 /* use short-GI */
|
|
|
|
|
#define ATH_RC_HT_FLAG 0x08 /* use HT */
|
|
|
|
|
#define ATH_RC_RTSCTS_FLAG 0x10 /* enable RTS/CTS protection */
|
2013-02-28 23:39:38 +00:00
|
|
|
#define ATH_RC_STBC_FLAG 0x20 /* enable STBC */
|
2013-04-17 07:21:30 +00:00
|
|
|
#define ATH_RC_TS_FLAG 0x40 /* triple-stream rate */
|
2011-11-08 01:35:05 +00:00
|
|
|
|
|
|
|
|
struct ath_rc_series {
|
|
|
|
|
uint8_t rix; /* ratetable index, not rate code */
|
|
|
|
|
uint8_t ratecode; /* hardware rate code */
|
|
|
|
|
uint8_t tries;
|
2013-04-17 07:21:30 +00:00
|
|
|
uint8_t tx_power_cap;
|
|
|
|
|
uint16_t flags;
|
|
|
|
|
uint16_t max4msframelen;
|
2011-11-08 01:35:05 +00:00
|
|
|
};
|
2004-12-08 17:34:36 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* State storage handling.
|
|
|
|
|
*/
|
|
|
|
|
/*
|
|
|
|
|
* Initialize per-node state already allocated for the specified
|
|
|
|
|
* node; this space can be assumed initialized to zero.
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_node_init(struct ath_softc *, struct ath_node *);
|
|
|
|
|
/*
|
|
|
|
|
* Cleanup any per-node state prior to the node being reclaimed.
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_node_cleanup(struct ath_softc *, struct ath_node *);
|
|
|
|
|
/*
|
|
|
|
|
* Update rate control state on station associate/reassociate
|
|
|
|
|
* (when operating as an ap or for nodes discovered when operating
|
|
|
|
|
* in ibss mode).
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_newassoc(struct ath_softc *, struct ath_node *,
|
|
|
|
|
int isNewAssociation);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Transmit handling.
|
|
|
|
|
*/
|
2011-02-01 08:10:18 +00:00
|
|
|
/*
|
|
|
|
|
* Return the four TX rate index and try counts for the current data packet.
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_getxtxrates(struct ath_softc *sc, struct ath_node *an,
|
[ath_rate_sample] Limit the tx schedules for A-MPDU ; don't take short retries
into account and remove the requirement that the MCS rate is "higher" if we're
considering a new rate.
Ok, another fun one.
* In order for reliable non-software retried higher MCS rates, the TX schedules
(inconsistently!) use hard-coded lower rates at the end of the schedule.
Now, hard-coded is a problem because (a) it means that aggregate formation
is limited by the SLOWEST rate, so I never formed large AMDU frames for
3 stream rates, and (b) if the AP disables lower rates as base rates, it
complains about "unknown rix" every frame you transmit at that rate.
So, for now just disable the third and fourth schedule entry for AMPDUs.
Now I'm forming 32k and 64k aggregates for the higher density MCS rates
much more reliably.
It would be much nicer if the rate schedule stuff wasn't fixed but instead
I'd just populate ath_rc_series[] when I fetch the rates. This is all a
holdover of ye olde pre-11n stuff and I really just need to nuke it.
But for now, ye hack.
* The check for "is this MCS rate better" based on MCS itself is just garbage.
It meant things like going MCS0->7 would be fine, and say 0->8->16 is fine,
(as they're equivalent encoding but 1,2,3 spatial streams), BUT it meant
going something like MCS7->11 would fail even though it's likely that
MCS11 would just be better, both for EWMA/BER and throughput.
So for now just use the average tx time. The "right" way for this comparison
would be to compare PHY bitrates rather than MCS / rate indexes, but I'm not
yet there. The bit rates ARE available in the PHY index, but honestly
I have a lot of other cleaning up to here before I think about that.
* Don't include the RTS/CTS retry count (and thus time) into the average tx time
caluation. It just makes temporarily failures make the rate look bad by
QUITE A LOT, as RTS/CTS exchanges are (a) long, and (b) mostly irrelevant
to the actual rate being tried. If we keep hitting RTS/CTS failures then
there's something ELSE wrong on the channel, not our selected rate.
2020-05-16 05:07:45 +00:00
|
|
|
uint8_t rix0, int is_aggr, struct ath_rc_series *rc);
|
2011-02-01 08:10:18 +00:00
|
|
|
|
2004-12-08 17:34:36 +00:00
|
|
|
/*
|
|
|
|
|
* Return the transmit info for a data packet. If multi-rate state
|
|
|
|
|
* is to be setup then try0 should contain a value other than ATH_TXMATRY
|
|
|
|
|
* and ath_rate_setupxtxdesc will be called after deciding if the frame
|
|
|
|
|
* can be transmitted with multi-rate retry.
|
2020-05-13 00:05:11 +00:00
|
|
|
*
|
|
|
|
|
* maxdur is an optional return value (or -1 if not set) that defines
|
|
|
|
|
* the maximum frame duration in microseconds. This allows the rate
|
|
|
|
|
* control selection to override the maximum duration (normally 4ms)
|
|
|
|
|
* that the packet aggregation logic makes.
|
2004-12-08 17:34:36 +00:00
|
|
|
*/
|
|
|
|
|
void ath_rate_findrate(struct ath_softc *, struct ath_node *,
|
[ath] [ath_rate] Extend ath_rate_sample to better handle 11n rates and aggregates.
My initial rate control code was .. suboptimal. I wanted to at least get MCS
rates sent, but it didn't do anywhere near enough to handle low signal level links
or remotely keep accurate statistics.
So, 8 years later, here's what I should've done back then.
* Firstly, I wasn't at all tracking packet sizes other than the two buckets
(250 and 1600 bytes.) So, extend it to include 4096, 8192, 16384, 32768 and
65536. I may go add 2048 at some point if I find it's useful.
This is important for a few reasons. First, when forming A-MPDU or AMSDU
aggregates the frame sizes are larger, and thus the TX time calculation
is woefully, increasingly wrong. Secondly, the behaviour of 802.11 channels
isn't some fixed thing, both due to channel conditions and radios themselves.
Notably, there was some observations done a few years ago on 11n chipsets
which noticed longer aggregates showed an increase in failed A-MPDU sub-frame
reception as you got further along in the transmit time. It could be due to
a variety of things - transmitter linearity, channel conditions changing,
frequency/phase drift, etc - but the observation was to potentially form
shorter aggregates to improve BER.
* .. and then modify the ath TX path to report the length of the aggregate sent,
so as the statistics kept would line up with the correct bucket.
* Then on the rate control look-up side - i was also only using the first frame
length for an A-MPDU rate control lookup which isn't good enough here.
So, add a new method that walks the TID software queue for that node to
find out what the likely length of data available is. It isn't ALL of the
data in the queue because we'll only ever send enough data to fit inside the
block-ack window, so limit how many bytes we return to roughly what ath_tx_form_aggr()
would do.
* .. and cache that in the first ath_buf in the aggregate so it and the eventual
AMPDU length can be returned to the rate control code.
* THEN, modify the rate control code to look at them both when deciding which bucket
to attribute the sent frame on. I'm erring on the side of caution and using the
size bucket that the lookup is based on.
Ok, so now the rate lookups and statistics are "more correct". However, MCS rates
are not the same as 11abg rates in that they're not a monotonically incrementing
set of faster rates and you can't assume that just because a given MCS rate fails,
the next higher one wouldn't work better or be a lower average tx time.
So, I had to do a bunch of surgery to the best rate and sample rate math.
This is the bit that's a WIP.
* First, simplify the statistics updates (update_stats()) to do a single pass on
all rates.
* Next, make sure that each rate average tx time is updated based on /its/ failure/success.
Eg if you sent a frame with { MCS15, MCS12, MCS8 } and MCS8 succeeded, MCS15 and MCS
12 would have their average tx time updated for /their/ part of the transmission,
not the whole transmission.
* Next, EWMA wasn't being fully calculated based on the /failures/ in each of the
rate attempts. So, if MCS15, MCS12 failed above but MCS8 didn't, then ensure
that the statistics noted that /all/ subframes failed at those rates, rather than
the eventual set of transmitted/sent frames. This ensures the EWMA /and/ average
TX time are updated correctly.
* When picking a sample rate and initial rate, probe rates aroud the current MCS
but limit it to MCS0..7 /for all spatial streams/, rather than doing crazy things
like hitting MCS7 and then probing MCS8 - MCS8 is basically MCS0 but two spatial
streams. It's a /lot/ slower than MCS7. Also, the reverse is true - if we're at
MCS8 then don't probe MCS7 as part of it, it's not likely to succeed.
* Fix bugs in pick_best_rate() where I was /immediately/ choosing the highest MCS
rate if there weren't any frames yet transmitted. I was defaulting to 25% EWMA and
.. then each comparison would accept the higher rate. Just skip those; sampling
will fill in the details.
So, this seems to work a lot better. It's not perfect; I'm still seeing a lot of
instability around higher MCS rates because there are bursts of loss/retransmissions
that aren't /too/ bad. But i'll keep iterating over this and tidying up my hacks.
Ok, so why this still something I'm poking at? rather than porting minstrel_ht?
ath_rate_sample tries to minimise airtime, not maximise throughput. I have
extended it with an EWMA based on sub-frame success/failures - high MCS rates
that have partially successful receptions still show super short average frame
times, but a /lot/ of retransmits have to happen for that to work.
So for MCS rates I also track this EWMA and ensure that the rates I'm choosing
don't have super crappy packet failures. I don't mind not getting lower
peak throughput versus minstrel_ht; instead I want to see if I can make "minimise
airtime" work well.
Tested:
* AR9380, STA mode
* AR9344, STA mode
* AR9580, STA/AP mode
2020-05-15 18:51:20 +00:00
|
|
|
int shortPreamble, size_t frameLen, int tid, int is_aggr,
|
|
|
|
|
u_int8_t *rix, int *try0, u_int8_t *txrate, int *maxdur,
|
|
|
|
|
int *maxpktlen);
|
2004-12-08 17:34:36 +00:00
|
|
|
/*
|
|
|
|
|
* Setup any extended (multi-rate) descriptor state for a data packet.
|
|
|
|
|
* The rate index returned by ath_rate_findrate is passed back in.
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_setupxtxdesc(struct ath_softc *, struct ath_node *,
|
2005-04-02 18:54:30 +00:00
|
|
|
struct ath_desc *, int shortPreamble, u_int8_t rix);
|
2004-12-08 17:34:36 +00:00
|
|
|
/*
|
|
|
|
|
* Update rate control state for a packet associated with the
|
|
|
|
|
* supplied transmit descriptor. The routine is invoked both
|
|
|
|
|
* for packets that were successfully sent and for those that
|
|
|
|
|
* failed (consult the descriptor for details).
|
Introduce TX aggregation and software TX queue management
for Atheros AR5416 and later wireless devices.
This is a very large commit - the complete history can be
found in the user/adrian/if_ath_tx branch.
Legacy (ie, pre-AR5416) devices also use the per-software
TXQ support and (in theory) can support non-aggregation
ADDBA sessions. However, the net80211 stack doesn't currently
support this.
In summary:
TX path:
* queued frames normally go onto a per-TID, per-node queue
* some special frames (eg ADDBA control frames) are thrown
directly onto the relevant hardware queue so they can
go out before any software queued frames are queued.
* Add methods to create, suspend, resume and tear down an
aggregation session.
* Add in software retransmission of both normal and aggregate
frames.
* Add in completion handling of aggregate frames, including
parsing the block ack bitmap provided by the hardware.
* Write an aggregation function which can assemble frames into
an aggregate based on the selected rate control and channel
configuration.
* The per-TID queues are locked based on their target hardware
TX queue. This matches what ath9k/atheros does, and thus
simplified porting over some of the aggregation logic.
* When doing TX aggregation, stick the sequence number allocation
in the TX path rather than net80211 TX path, and protect it
by the TXQ lock.
Rate control:
* Delay rate control selection until the frame is about to
be queued to the hardware, so retried frames can have their
rate control choices changed. Frames with a static rate
control selection have that applied before each TX, just
to simplify the TX path (ie, not have "static" and "dynamic"
rate control special cased.)
* Teach ath_rate_sample about aggregates - both completion and
errors.
* Add an EWMA for tracking what the current "good" MCS rate is
based on failure rates.
Misc:
* Introduce a bunch of dirty hacks and workarounds so TID mapping
and net80211 frame inspection can be kept out of the net80211
layer. Because of the way this code works (and it's from Atheros
and Linux ath9k), there is a consistent, 1:1 mapping between
TID and AC. So we need to ensure that frames going to a specific
TID will _always_ end up on the right AC, and vice versa, or the
completion/locking will simply get very confused. I plan on
addressing this mess in the future.
Known issues:
* There is no BAR frame transmission just yet. A whole lot of
tidying up needs to occur before BAR frame TX can occur in the
"correct" place - ie, once the TID TX queue has been drained.
* Interface reset/purge/etc results in frames in the TX and RX
queues being removed. This creates holes in the sequence numbers
being assigned and the TX/RX AMPDU code (on either side) just
hangs.
* There's no filtered frame support at the present moment, so
stations going into power saving mode will simply have a number
of frames dropped - likely resulting in a traffic "hang".
* Raw frame TX is going to just not function with 11n aggregation.
Likely this needs to be modified to always override the sequence
number if the frame is going into an aggregation session.
However, general raw frame injection currently doesn't work in
general in net80211, so let's just ignore this for now until
this is sorted out.
* HT protection is just not implemented and won't be until the above
is sorted out. In addition, the AR5416 has issues RTS protecting
large aggregates (anything >8k), so the work around needs to be
ported and tested. Thus, this will be put on hold until the above
work is complete.
* The rate control module 'sample' is the only currently supported
module; onoe/amrr haven't been tested and have likely bit rotted
a little. I'll follow up with some commits to make them work again
for non-11n rates, but they won't be updated to handle 11n and
aggregation. If someone wishes to do so then they're welcome to
send along patches.
* .. and "sample" doesn't really do a good job of 11n TX. Specifically,
the metrics used (packet TX time and failure/success rates) isn't as
useful for 11n. It's likely that it should be extended to take into
account the aggregate throughput possible and then choose a rate
which maximises that. Ie, it may be acceptable for a higher MCS rate
with a higher failure to be used if it gives a more acceptable
throughput/latency then a lower MCS rate @ a lower error rate.
Again, patches will be gratefully accepted.
Because of this, ATH_ENABLE_11N is still not enabled by default.
Sponsored by: Hobnob, Inc.
Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
|
|
|
*
|
|
|
|
|
* For A-MPDU frames, nframes and nbad indicate how many frames
|
|
|
|
|
* were in the aggregate, and how many failed.
|
2004-12-08 17:34:36 +00:00
|
|
|
*/
|
2006-12-13 19:34:35 +00:00
|
|
|
struct ath_buf;
|
2004-12-08 17:34:36 +00:00
|
|
|
void ath_rate_tx_complete(struct ath_softc *, struct ath_node *,
|
Introduce TX aggregation and software TX queue management
for Atheros AR5416 and later wireless devices.
This is a very large commit - the complete history can be
found in the user/adrian/if_ath_tx branch.
Legacy (ie, pre-AR5416) devices also use the per-software
TXQ support and (in theory) can support non-aggregation
ADDBA sessions. However, the net80211 stack doesn't currently
support this.
In summary:
TX path:
* queued frames normally go onto a per-TID, per-node queue
* some special frames (eg ADDBA control frames) are thrown
directly onto the relevant hardware queue so they can
go out before any software queued frames are queued.
* Add methods to create, suspend, resume and tear down an
aggregation session.
* Add in software retransmission of both normal and aggregate
frames.
* Add in completion handling of aggregate frames, including
parsing the block ack bitmap provided by the hardware.
* Write an aggregation function which can assemble frames into
an aggregate based on the selected rate control and channel
configuration.
* The per-TID queues are locked based on their target hardware
TX queue. This matches what ath9k/atheros does, and thus
simplified porting over some of the aggregation logic.
* When doing TX aggregation, stick the sequence number allocation
in the TX path rather than net80211 TX path, and protect it
by the TXQ lock.
Rate control:
* Delay rate control selection until the frame is about to
be queued to the hardware, so retried frames can have their
rate control choices changed. Frames with a static rate
control selection have that applied before each TX, just
to simplify the TX path (ie, not have "static" and "dynamic"
rate control special cased.)
* Teach ath_rate_sample about aggregates - both completion and
errors.
* Add an EWMA for tracking what the current "good" MCS rate is
based on failure rates.
Misc:
* Introduce a bunch of dirty hacks and workarounds so TID mapping
and net80211 frame inspection can be kept out of the net80211
layer. Because of the way this code works (and it's from Atheros
and Linux ath9k), there is a consistent, 1:1 mapping between
TID and AC. So we need to ensure that frames going to a specific
TID will _always_ end up on the right AC, and vice versa, or the
completion/locking will simply get very confused. I plan on
addressing this mess in the future.
Known issues:
* There is no BAR frame transmission just yet. A whole lot of
tidying up needs to occur before BAR frame TX can occur in the
"correct" place - ie, once the TID TX queue has been drained.
* Interface reset/purge/etc results in frames in the TX and RX
queues being removed. This creates holes in the sequence numbers
being assigned and the TX/RX AMPDU code (on either side) just
hangs.
* There's no filtered frame support at the present moment, so
stations going into power saving mode will simply have a number
of frames dropped - likely resulting in a traffic "hang".
* Raw frame TX is going to just not function with 11n aggregation.
Likely this needs to be modified to always override the sequence
number if the frame is going into an aggregation session.
However, general raw frame injection currently doesn't work in
general in net80211, so let's just ignore this for now until
this is sorted out.
* HT protection is just not implemented and won't be until the above
is sorted out. In addition, the AR5416 has issues RTS protecting
large aggregates (anything >8k), so the work around needs to be
ported and tested. Thus, this will be put on hold until the above
work is complete.
* The rate control module 'sample' is the only currently supported
module; onoe/amrr haven't been tested and have likely bit rotted
a little. I'll follow up with some commits to make them work again
for non-11n rates, but they won't be updated to handle 11n and
aggregation. If someone wishes to do so then they're welcome to
send along patches.
* .. and "sample" doesn't really do a good job of 11n TX. Specifically,
the metrics used (packet TX time and failure/success rates) isn't as
useful for 11n. It's likely that it should be extended to take into
account the aggregate throughput possible and then choose a rate
which maximises that. Ie, it may be acceptable for a higher MCS rate
with a higher failure to be used if it gives a more acceptable
throughput/latency then a lower MCS rate @ a lower error rate.
Again, patches will be gratefully accepted.
Because of this, ATH_ENABLE_11N is still not enabled by default.
Sponsored by: Hobnob, Inc.
Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
|
|
|
const struct ath_rc_series *, const struct ath_tx_status *,
|
[ath] [ath_rate] Extend ath_rate_sample to better handle 11n rates and aggregates.
My initial rate control code was .. suboptimal. I wanted to at least get MCS
rates sent, but it didn't do anywhere near enough to handle low signal level links
or remotely keep accurate statistics.
So, 8 years later, here's what I should've done back then.
* Firstly, I wasn't at all tracking packet sizes other than the two buckets
(250 and 1600 bytes.) So, extend it to include 4096, 8192, 16384, 32768 and
65536. I may go add 2048 at some point if I find it's useful.
This is important for a few reasons. First, when forming A-MPDU or AMSDU
aggregates the frame sizes are larger, and thus the TX time calculation
is woefully, increasingly wrong. Secondly, the behaviour of 802.11 channels
isn't some fixed thing, both due to channel conditions and radios themselves.
Notably, there was some observations done a few years ago on 11n chipsets
which noticed longer aggregates showed an increase in failed A-MPDU sub-frame
reception as you got further along in the transmit time. It could be due to
a variety of things - transmitter linearity, channel conditions changing,
frequency/phase drift, etc - but the observation was to potentially form
shorter aggregates to improve BER.
* .. and then modify the ath TX path to report the length of the aggregate sent,
so as the statistics kept would line up with the correct bucket.
* Then on the rate control look-up side - i was also only using the first frame
length for an A-MPDU rate control lookup which isn't good enough here.
So, add a new method that walks the TID software queue for that node to
find out what the likely length of data available is. It isn't ALL of the
data in the queue because we'll only ever send enough data to fit inside the
block-ack window, so limit how many bytes we return to roughly what ath_tx_form_aggr()
would do.
* .. and cache that in the first ath_buf in the aggregate so it and the eventual
AMPDU length can be returned to the rate control code.
* THEN, modify the rate control code to look at them both when deciding which bucket
to attribute the sent frame on. I'm erring on the side of caution and using the
size bucket that the lookup is based on.
Ok, so now the rate lookups and statistics are "more correct". However, MCS rates
are not the same as 11abg rates in that they're not a monotonically incrementing
set of faster rates and you can't assume that just because a given MCS rate fails,
the next higher one wouldn't work better or be a lower average tx time.
So, I had to do a bunch of surgery to the best rate and sample rate math.
This is the bit that's a WIP.
* First, simplify the statistics updates (update_stats()) to do a single pass on
all rates.
* Next, make sure that each rate average tx time is updated based on /its/ failure/success.
Eg if you sent a frame with { MCS15, MCS12, MCS8 } and MCS8 succeeded, MCS15 and MCS
12 would have their average tx time updated for /their/ part of the transmission,
not the whole transmission.
* Next, EWMA wasn't being fully calculated based on the /failures/ in each of the
rate attempts. So, if MCS15, MCS12 failed above but MCS8 didn't, then ensure
that the statistics noted that /all/ subframes failed at those rates, rather than
the eventual set of transmitted/sent frames. This ensures the EWMA /and/ average
TX time are updated correctly.
* When picking a sample rate and initial rate, probe rates aroud the current MCS
but limit it to MCS0..7 /for all spatial streams/, rather than doing crazy things
like hitting MCS7 and then probing MCS8 - MCS8 is basically MCS0 but two spatial
streams. It's a /lot/ slower than MCS7. Also, the reverse is true - if we're at
MCS8 then don't probe MCS7 as part of it, it's not likely to succeed.
* Fix bugs in pick_best_rate() where I was /immediately/ choosing the highest MCS
rate if there weren't any frames yet transmitted. I was defaulting to 25% EWMA and
.. then each comparison would accept the higher rate. Just skip those; sampling
will fill in the details.
So, this seems to work a lot better. It's not perfect; I'm still seeing a lot of
instability around higher MCS rates because there are bursts of loss/retransmissions
that aren't /too/ bad. But i'll keep iterating over this and tidying up my hacks.
Ok, so why this still something I'm poking at? rather than porting minstrel_ht?
ath_rate_sample tries to minimise airtime, not maximise throughput. I have
extended it with an EWMA based on sub-frame success/failures - high MCS rates
that have partially successful receptions still show super short average frame
times, but a /lot/ of retransmits have to happen for that to work.
So for MCS rates I also track this EWMA and ensure that the rates I'm choosing
don't have super crappy packet failures. I don't mind not getting lower
peak throughput versus minstrel_ht; instead I want to see if I can make "minimise
airtime" work well.
Tested:
* AR9380, STA mode
* AR9344, STA mode
* AR9580, STA/AP mode
2020-05-15 18:51:20 +00:00
|
|
|
int pktlen, int rc_framelen, int nframes, int nbad);
|
2012-07-20 01:27:20 +00:00
|
|
|
|
2019-05-05 04:56:37 +00:00
|
|
|
/*
|
|
|
|
|
* Update rate control with a per-packet receive RSSI value.
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_update_rx_rssi(struct ath_softc *, struct ath_node *,
|
|
|
|
|
int rssi);
|
|
|
|
|
|
2012-07-20 01:27:20 +00:00
|
|
|
/*
|
|
|
|
|
* Fetch the global rate control statistics.
|
|
|
|
|
*/
|
|
|
|
|
int ath_rate_fetch_stats(struct ath_softc *sc, struct ath_rateioctl *rs);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Fetch the per-node statistics.
|
|
|
|
|
*/
|
|
|
|
|
int ath_rate_fetch_node_stats(struct ath_softc *sc, struct ath_node *an,
|
|
|
|
|
struct ath_rateioctl *rs);
|
|
|
|
|
|
2004-12-08 17:34:36 +00:00
|
|
|
#endif /* _ATH_RATECTRL_H_ */
|
