Bug #162
Description
I see latencies as high as 60ms under load for ping [12:45]
and NEVER a packet loss.
I think I only set TX_RETRY down to 2.
yeah, with my patch i still haven’t found a decent queue length
limit
that doesn’t hurt aggregation throughput
There’s another RETRY in hardware?
but at least i’ve been able to keep the non-aggregated latency
low
without hurting throughput at all
nbd: you know me, I don’t give a F* about aggregation
throughpt…
cool [12:46]
that’s a start
I have routers going to the third world… Today.
what TX_RETRY are you talking about?
The amount of wireless-n down there is probably non-existent
-#define ATH_TXMAXTRY 13 [12:47]
+#define ATH_TXMAXTRY 2
#define ATH_MGT_TXMAXTRY 4
#define TID_TO_WME_AC(_tid) \
@ -542,7 +542,7
@
#define DEFAULT_CACHELINE 32
#define ATH_REGCLASSIDS_MAX 10
#define ATH_CABQ_READY_TIME 80 /* % of beacon interval */
-#define ATH_MAX_SW_RETRIES 10
+#define ATH_MAX_SW_RETRIES 2
ah
ATH_TXMAXTRY is unused [12:48]
except when using the ath9k rate control module
but that one’s crappy anyway
and openwrt doesn’t use it
I figured.
init.c: hw->max_rate_tries = 10;
How is germany in June? [12:49]
sigh
too late to change now, but good to know.
germany’s nice in june
History
This is a static export of the original bufferbloat.net issue
database. As such, no further commenting is possible; the
information is solely here for archival purposes.