TX_RETRY still too high
|Assignee:||Andrew McGregor||% Done:||
|Category:||-||Spent time:||2.00 hours|
|Target version:||1st Public Cerowrt release|
<dtaht> I see latencies as high as 60ms under load for ping [12:45]
<dtaht> and NEVER a packet loss.
<dtaht> I think I only set TX_RETRY down to 2.
<nbd> yeah, with my patch i still haven't found a decent queue length limit
that doesn't hurt aggregation throughput
<dtaht> There's another RETRY in hardware?
<nbd> but at least i've been able to keep the non-aggregated latency low
without hurting throughput at all
<dtaht> nbd: you know me, I don't give a F* about aggregation throughpt...
<dtaht> cool [12:46]
<dtaht> that's a start
<dtaht> I have routers going to the third world... Today.
<nbd> what TX_RETRY are you talking about?
<dtaht> The amount of wireless-n down there is probably non-existent
#define ATH_TXMAXTRY 13 [12:47]>max_rate_tries = 10;
<dtaht> +#define ATH_TXMAXTRY 2
<dtaht> #define ATH_MGT_TXMAXTRY 4
<dtaht> #define TID_TO_WME_AC(_tid) \
@ -542,7 +542,7 @
<dtaht> #define DEFAULT_CACHELINE 32
<dtaht> #define ATH_REGCLASSIDS_MAX 10
<dtaht> #define ATH_CABQ_READY_TIME 80 /* % of beacon interval */
<dtaht> -#define ATH_MAX_SW_RETRIES 10
<dtaht> +#define ATH_MAX_SW_RETRIES 2
<nbd> ATH_TXMAXTRY is unused [12:48]
<nbd> except when using the ath9k rate control module
<nbd> but that one's crappy anyway
<nbd> and openwrt doesn't use it
<dtaht> I figured.
<nbd> init.c: hw
<dtaht> How is germany in June? [12:49]
<dtaht> too late to change now, but good to know.
<nbd> germany's nice in june
|duplicated by Cerowrt - Bug #216: Infiinite retry for ping||Closed||07/28/2011|