[Make-wifi-fast] [PATCH] killing retries harder, perhaps

[Make-wifi-fast] [PATCH] killing retries harder, perhaps

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

ATH_TXMAXTRY is now unused.

ATH_MAX_SW_RETRIES is insanely high by default.

I finally have some good (well, horrible) data in a consistently noisy
environment and would like to try knocking this down a little in a
future test run. There's smarter ways to do it (like, if you are at
the lowest rate, retry once, higher rates, 4).

I have tried in the past values as low as 2 for soft retries.

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 331947b..304976d 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -91,8 +91,7 @@ int ath_descdma_setup(struct ath_softc *sc, struct
ath_descdma *dd,
 #define ATH_RXBUF               512
 #define ATH_TXBUF               512
 #define ATH_TXBUF_RESERVE       5
-#define ATH_TXMAXTRY            13
-#define ATH_MAX_SW_RETRIES      30
+#define ATH_MAX_SW_RETRIES      4

 #define TID_TO_WME_AC(_tid)                            \
        ((((_tid) == 0) || ((_tid) == 3)) ? IEEE80211_AC_BE :   \



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

[-- Attachment #2: reduce_retry_insanity.diff --]
[-- Type: text/plain, Size: 609 bytes --]

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 331947b..304976d 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -91,8 +91,7 @@ int ath_descdma_setup(struct ath_softc *sc, struct ath_descdma *dd,
 #define ATH_RXBUF               512
 #define ATH_TXBUF               512
 #define ATH_TXBUF_RESERVE       5
-#define ATH_TXMAXTRY            13
-#define ATH_MAX_SW_RETRIES      30
+#define ATH_MAX_SW_RETRIES      4
 
 #define TID_TO_WME_AC(_tid)				\
 	((((_tid) == 0) || ((_tid) == 3)) ? IEEE80211_AC_BE :	\

Re: [Make-wifi-fast] [PATCH] killing retries harder, perhaps

[Dave Taht]

Also at one point or another I'd knocked these down to 2 or 3 from 8.
No point in servicing a G station to this depth.

#define ATH_NON_AGGR_MIN_QDEPTH    8
#define ATH_TX_COMPLETE_POLL_INT   1000
#define ATH_TXFIFO_DEPTH           8

(yea, yea, code freeze in lede, but I've been dying to try this kind
of stuff harder after things stablized)

On Thu, Feb 2, 2017 at 3:47 PM, Dave Taht <dave.taht@gmail.com> wrote:
> ATH_TXMAXTRY is now unused.
>
> ATH_MAX_SW_RETRIES is insanely high by default.
>
> I finally have some good (well, horrible) data in a consistently noisy
> environment and would like to try knocking this down a little in a
> future test run. There's smarter ways to do it (like, if you are at
> the lowest rate, retry once, higher rates, 4).
>
> I have tried in the past values as low as 2 for soft retries.
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
> b/drivers/net/wireless/ath/ath9k/ath9k.h
> index 331947b..304976d 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -91,8 +91,7 @@ int ath_descdma_setup(struct ath_softc *sc, struct
> ath_descdma *dd,
>  #define ATH_RXBUF               512
>  #define ATH_TXBUF               512
>  #define ATH_TXBUF_RESERVE       5
> -#define ATH_TXMAXTRY            13
> -#define ATH_MAX_SW_RETRIES      30
> +#define ATH_MAX_SW_RETRIES      4
>
>  #define TID_TO_WME_AC(_tid)                            \
>         ((((_tid) == 0) || ((_tid) == 3)) ? IEEE80211_AC_BE :   \
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Make-wifi-fast] [PATCH] killing retries harder, perhaps

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht@gmail.com> writes:

> ATH_TXMAXTRY is now unused.
>
> ATH_MAX_SW_RETRIES is insanely high by default.
>
> I finally have some good (well, horrible) data in a consistently noisy
> environment and would like to try knocking this down a little in a
> future test run. There's smarter ways to do it (like, if you are at
> the lowest rate, retry once, higher rates, 4).
>
> I have tried in the past values as low as 2 for soft retries.
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
> b/drivers/net/wireless/ath/ath9k/ath9k.h
> index 331947b..304976d 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -91,8 +91,7 @@ int ath_descdma_setup(struct ath_softc *sc, struct
> ath_descdma *dd,
>  #define ATH_RXBUF               512
>  #define ATH_TXBUF               512
>  #define ATH_TXBUF_RESERVE       5
> -#define ATH_TXMAXTRY            13
> -#define ATH_MAX_SW_RETRIES      30
> +#define ATH_MAX_SW_RETRIES      4

Note that this is not tested until *after* the initial retry chain has
been exhausted. So Minstrel may still (and usually will) define a retry
chain that is a lot longer than 4; meaning that the net effect of this
change is that you'll just drop any packets that are kicked back to the
driver after the retry chain fails... Not that this is necessarily a bad
thing, just something to keep in mind.

-Toke

Re: [Make-wifi-fast] [PATCH] killing retries harder, perhaps

[Dave Taht]

The net effect of
http://mirrors.bufferbloat.net/~kevindb/999-daves-special-patch.patch
of:

#define ATH_NON_AGGR_MIN_QDEPTH    2
#define ATH_MAX_SW_RETRIES      2
#define ATH_TXFIFO_DEPTH           3

was to disable ampdu generation entirely, and ship pure MPDUs instead,
which gives me a solid bound of about 15Mbits transfers in my noisy
tests (where I'd see anywhere from 4Mbit to 80mbit with ampdus).

http://pastebin.com/WU390GFL

I note: I have *always* wanted to measure these with aggregation
completely out of the loop, so this is kind of inadvertently awesome.

root@archer-atf:/sys/kernel/debug/ieee80211/phy1/ath9k# cat xmit
                            BE         BK        VI        VO

MPDUs Queued:                0          0         0      1234
MPDUs Completed:       6402806          0         0      1234
MPDUs XRetried:             19          0         0         0
Aggregates:                  0          0         0         0
AMPDUs Queued HW:            0          0         0         0
AMPDUs Completed:            0          0         0         0
AMPDUs Retried:              0          0         0         0
AMPDUs XRetried:             0          0         0         0
TXERR Filtered:            115          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:           6402825          0         0      1234
TX-Bytes-All:       1171739830          0         0    178778
HW-put-tx-buf:         3213134          0         0      1233
HW-tx-start:                 0          0         0         0
HW-tx-proc-desc:       6402825          0         0      1234
TX-Failed:                   0          0         0         0




http://pastebin.com/WU390GFL

Re: [Make-wifi-fast] [PATCH] killing retries harder, perhaps

[Dave Taht]

And my aha! moment was that in the middle of the week, I'd turned off
wmm, which limits the rate set to the old style up to 58mbits.

My principal objective for the past week was to "make it crash", and
this is the longest the archer has ever survived intensive testing.
wmm on and off, multiple stations, 3 different distances, two to six
different clients, multicast rates set higher, ath9k and ath10k,
routed vs bridged (haven't returned to bridged), through the device,
to the device, channel scans, no channel scans, single queue vs
multi-queue, through sqm (with cake or fq_codel) and over the local
lan, ecn vs noecn, and I haven't got to blowing up multicast with
uftpd yet nor thc-ipv6.

Figuring out *why* things behaved badly was secondary, and kind of
hard, when they did. But no cases of RUD since jan 30.

thank ghu (and toke) for flent! And things are looking the most solid
they've ever been. As for whether this patch actually accomplished
anything or not...
tell you in 24 hours.