net80211 / LinuxKPI: 802.11: revert / redo enum ieee80211_sta_rx_bw

The initial thought of migrating the LinuxKPI 802.11 enum into net80211
for shared use did not work out well. Currently in the ne

net80211 / LinuxKPI: 802.11: revert / redo enum ieee80211_sta_rx_bw

The initial thought of migrating the LinuxKPI 802.11 enum into net80211
for shared use did not work out well. Currently in the need for yet
another adjustment, I decided to undo/de-couple net80211 and
LinuxKPI 802.11 again.

The enum name now gets used in LinuxKPI based wifi drivers and it
turns out it is spelt differntly than what I used initially.
This creates a conflict.

net80211 still in the need to be able to express BW_320 in an uint8_t
will likely be fine with the current solution as well. Rename the
enum and prefixes in net80211 to "net80211" instead of "ieee80211".
Apart from the names/prefix we leave the values the same.

In LinuxKPI add the enum with the expected name and use it there
throughout to make modern versions of LinuxKPI based wifi drivers
compile.

Sponsored by: The FreeBSD Foundation
Fixes: ca389486a9599, 2c8b0d6205f6f
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D52064

show more ...

ath_rate_sample: fix setting HT rates

ieee80211_node_set_txrate_ht_mcsrate() takes an MCS rate from 0..76,
the high bit (IEEE80211_RATE_MCS) must not be set.

This is definitely my fault - I likely

ath_rate_sample: fix setting HT rates

ieee80211_node_set_txrate_ht_mcsrate() takes an MCS rate from 0..76,
the high bit (IEEE80211_RATE_MCS) must not be set.

This is definitely my fault - I likely didn't get to testing this
diff when I changed it from ieee80211_node_set_txrate_dot11rate()
just before landing.

Differential Revision: https://reviews.freebsd.org/D49197
Reviewed by: bz

show more ...

sys: convert ni->ni_txrate references use to the new net80211 API

This just mechanically converts things.

* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as

sys: convert ni->ni_txrate references use to the new net80211 API

This just mechanically converts things.

* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as firmware
doesn't report it up.

Differential Revision: https://reviews.freebsd.org/D48602
Reviewed by: bz, thj

show more ...

ath_rate_sample: correct the "best rate" calculation

This should be a *9 rather than a *10 so higher stream MCS rates
(eg comparing MCS0 and MCS8) that have slightly longer average transmit
times (b

ath_rate_sample: correct the "best rate" calculation

This should be a *9 rather than a *10 so higher stream MCS rates
(eg comparing MCS0 and MCS8) that have slightly longer average transmit
times (but better burst transmit times) get considered.

This mirrors what the later code does when considering if a rate
change is needed.

Locally tested:

* AR9280, AP mode
* AR9380, AP mode

Differential Revision: https://reviews.freebsd.org/D47988
Reviewed by: imp

show more ...

net80211 / LinuxKPI 802.11: use enum ieee80211_sta_rx_bw for ni_chw

net80211 node ni_chw currently encodes the channel width as Mhz number.
LinuxKPI 802.11 uses enum ieee80211_sta_rx_bw for the same

net80211 / LinuxKPI 802.11: use enum ieee80211_sta_rx_bw for ni_chw

net80211 node ni_chw currently encodes the channel width as Mhz number.
LinuxKPI 802.11 uses enum ieee80211_sta_rx_bw for the same.

Rather than keeping the "20" and "40" throughout the code (eventually
expanded to 80/160/320) switch them over to use the enum throughout
and add a print mask for debug output. While designed as bitmask it
is not supposed to be used as such; the bitmask is only used to be
able to use %b with a print mask.

Once we get to 320Mhz channel widths we would otherwise also need to
extend the uint8_t in struct ieee80211_node; making
enum ieee80211_sta_rx_bw __packed allows us for three more channel
widths without breaking the KBI (if we were not to use %b with a
print_mask but use a lookup function for the string we could extend
it for a long time).

Sponsored by: The FreeBSD Foundation
MFC after: 14 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D47891

show more ...

ath: Handle errors from copyout() in ath_rate_fetch_node_stats()

MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43096

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

ath: clean up empty lines in .c and .h files

[ath_rate_sample] Obey the maximum frame length even when using static rates.

I wasn't enforcing the maximum packet length when using static rates
so although the driver was enforcing it itself OK,

[ath_rate_sample] Obey the maximum frame length even when using static rates.

I wasn't enforcing the maximum packet length when using static rates
so although the driver was enforcing it itself OK, the statistics were
sometimes going into the wrong bin.

Tested:

* AR9380, STA mode

show more ...

[ath_rate_sample] Fix correct status when completing frames with short failures.

My preivous logic was a bit wrong. This caused transmissions that failed due
to a mix of short and long retries to c

[ath_rate_sample] Fix correct status when completing frames with short failures.

My preivous logic was a bit wrong. This caused transmissions that failed due
to a mix of short and long retries to count intermediate rates as OK if the
LONG retry count indicated some retries had made it to this intermediate rate,
but the SHORT retry count was the one that caused the whole transmit to fail.

Now status is passed in again - and this is the status for the whole transmission -
and then update_stats() does some quick math to see if the current transmission
series hit its long retry count or not before updating things as a success
or failure.

show more ...

[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

[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.

show more ...

[ath_rate_sample] Fix logic for determining whether to bump up an MCS rate.

* Fix formatting, cause reasons;
* Put back the "and the chosen rate is within 90% of the current rate" logic;
* Ensure th

[ath_rate_sample] Fix logic for determining whether to bump up an MCS rate.

* Fix formatting, cause reasons;
* Put back the "and the chosen rate is within 90% of the current rate" logic;
* Ensure the best rate and the current rate aren't the same; this ...
* ... fixes the packets_since_switch[] tracking to actually conut how many
frames since the rate switched, so now I know how stable stuff is; and
* Ensure that MCS can go up to a higher MCS at this or any other spatial stream.
My previous quick hack attempt was doing > rather than >= so you had to go
to both a higher root MCS rate (0..7) and spatial stream. Eg, you couldn't
go from MCS0 (1ss) to MCS8 (2ss) this way.

The best rate and switching rate logic still have a bunch more work to do
because they're still quite touchy when it comes to average tx time but at least
now it's choosing higher rates correctly when it wants to try a higher rate.

Tested:

* AR9380, STA mode

show more ...

[ath] [ath_rate_sample] le oops, trim out an #if 1 that I didn't fully delete.

Cool, so now I know it's about 3 weeks between starting on freebsd coding
and breaking the build again. Queue dunce cap.

[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

[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

show more ...

[ath] [ath_rate] Add some extra data into the rate control lookup.

Right now (well, since I did this in 2011/2012) the rate control code
makes some super bad choices for 11n aggregates/rates, and it

[ath] [ath_rate] Add some extra data into the rate control lookup.

Right now (well, since I did this in 2011/2012) the rate control code
makes some super bad choices for 11n aggregates/rates, and it tracks
statistics even more questionably.

It's been long enough and I'm now trying to use it again daily, so let's
start by:

* telling the rate control code if it's an aggregate or not;
* being clearer about the TID - yes it can be extracted from the
ath_buf but this way it can be overridden by the caller without
changing the TID itself.

(This is for doing experiments with voice/video QoS at some point..)

* Return an optional field to limit how long the aggregate is in
microseconds. Right now the rate control code supplies a rate table
and the ath aggr form code will look at the rate table and limit
the aggregate size to 4ms at the slowest rate. Yeah, this is pretty
terrible.

* Add some more TODO comments around handling txpower, rate and
handling filtered frames status so if I continue to have spoons for
this I can go poke at it.

show more ...

Merge r358179 through r358238.

PR: 244251

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (7 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marke

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (7 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.

This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Mark all low hanging fruits as MPSAFE.

Reviewed by: markj
Approved by: kib (mentor, blanket)
Differential Revision: https://reviews.freebsd.org/D23626

show more ...

MFHead @347527

Sponsored by: The FreeBSD Foundation

[ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking at rate control

These are some fun issues I've found with my upstairs wifi link at such a ridiculous
low signal level (lik

[ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking at rate control

These are some fun issues I've found with my upstairs wifi link at such a ridiculous
low signal level (like, < 5dB.)

* Add per-station tx/rx rssi statistics, in potential preparation to use that
in the RX rate control.

* Call the rate control on each received frame to let it potentially use
it as a hint for what rates to potentially use. It's a no-op right now.

* Do ANI calibration during scan as well. The ath_newstate() call was disabling the
ANI timer and only re-enabling it during transitions to _RUN. This has the
unfortunate side-effect that if ANI deafened the NIC because of interference
and it disassociated, it wouldn't be reset and the scan would never hear beacons.

The ANI configuration is stored at least globally on some HALs and per-channel
on others. Because of this a NIC reset wouldn't help; the ANI parameters would
simply be programmed back in.

Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe,
if I'm feeling clever, I need to reset the ANI parameters on a given channel
during a transition through INIT or if the VAP is destroyed/re-created.
However for now this gets me out of the immediate weeds with connectivity
upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this
stuff up in subsequent commits.

Tested:

* AR9344 (Wasp), 2G STA mode

show more ...

net80211 / LinuxKPI: 802.11: revert / redo enum ieee80211_sta_rx_bw

The initial thought of migrating the LinuxKPI 802.11 enum into net80211
for shared use did not work out well. Currently in the ne

net80211 / LinuxKPI: 802.11: revert / redo enum ieee80211_sta_rx_bw

The initial thought of migrating the LinuxKPI 802.11 enum into net80211
for shared use did not work out well. Currently in the need for yet
another adjustment, I decided to undo/de-couple net80211 and
LinuxKPI 802.11 again.

The enum name now gets used in LinuxKPI based wifi drivers and it
turns out it is spelt differntly than what I used initially.
This creates a conflict.

net80211 still in the need to be able to express BW_320 in an uint8_t
will likely be fine with the current solution as well. Rename the
enum and prefixes in net80211 to "net80211" instead of "ieee80211".
Apart from the names/prefix we leave the values the same.

In LinuxKPI add the enum with the expected name and use it there
throughout to make modern versions of LinuxKPI based wifi drivers
compile.

Sponsored by: The FreeBSD Foundation
Fixes: ca389486a9599, 2c8b0d6205f6f
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D52064

show more ...

ath_rate_sample: fix setting HT rates

ieee80211_node_set_txrate_ht_mcsrate() takes an MCS rate from 0..76,
the high bit (IEEE80211_RATE_MCS) must not be set.

This is definitely my fault - I likely

ath_rate_sample: fix setting HT rates

ieee80211_node_set_txrate_ht_mcsrate() takes an MCS rate from 0..76,
the high bit (IEEE80211_RATE_MCS) must not be set.

This is definitely my fault - I likely didn't get to testing this
diff when I changed it from ieee80211_node_set_txrate_dot11rate()
just before landing.

Differential Revision: https://reviews.freebsd.org/D49197
Reviewed by: bz

show more ...

sys: convert ni->ni_txrate references use to the new net80211 API

This just mechanically converts things.

* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as

sys: convert ni->ni_txrate references use to the new net80211 API

This just mechanically converts things.

* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as firmware
doesn't report it up.

Differential Revision: https://reviews.freebsd.org/D48602
Reviewed by: bz, thj

show more ...

ath_rate_sample: correct the "best rate" calculation

This should be a *9 rather than a *10 so higher stream MCS rates
(eg comparing MCS0 and MCS8) that have slightly longer average transmit
times (b

ath_rate_sample: correct the "best rate" calculation

This should be a *9 rather than a *10 so higher stream MCS rates
(eg comparing MCS0 and MCS8) that have slightly longer average transmit
times (but better burst transmit times) get considered.

This mirrors what the later code does when considering if a rate
change is needed.

Locally tested:

* AR9280, AP mode
* AR9380, AP mode

Differential Revision: https://reviews.freebsd.org/D47988
Reviewed by: imp

show more ...

net80211 / LinuxKPI 802.11: use enum ieee80211_sta_rx_bw for ni_chw

net80211 node ni_chw currently encodes the channel width as Mhz number.
LinuxKPI 802.11 uses enum ieee80211_sta_rx_bw for the same

net80211 / LinuxKPI 802.11: use enum ieee80211_sta_rx_bw for ni_chw

net80211 node ni_chw currently encodes the channel width as Mhz number.
LinuxKPI 802.11 uses enum ieee80211_sta_rx_bw for the same.

Rather than keeping the "20" and "40" throughout the code (eventually
expanded to 80/160/320) switch them over to use the enum throughout
and add a print mask for debug output. While designed as bitmask it
is not supposed to be used as such; the bitmask is only used to be
able to use %b with a print mask.

Once we get to 320Mhz channel widths we would otherwise also need to
extend the uint8_t in struct ieee80211_node; making
enum ieee80211_sta_rx_bw __packed allows us for three more channel
widths without breaking the KBI (if we were not to use %b with a
print_mask but use a lookup function for the string we could extend
it for a long time).

Sponsored by: The FreeBSD Foundation
MFC after: 14 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D47891

show more ...

ath: Handle errors from copyout() in ath_rate_fetch_node_stats()

MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43096