———- Forwarded message ———-
From: Kalle Valo email@example.com
Date: Mon, Sep 19, 2011 at 11:38 AM
Subject: [PATCH] ath6kl: pass only unicast frames for aggregation
When pinging form ar6003 to the AP RTT was high even when power save
100 packets transmitted, 97 received, 3% packet loss, time 99125ms
rtt min/avg/max/mdev = 1.875⁄46.733⁄795.506⁄139.181 ms
After some investigation one reason for this was that received
multicast traffic confused the aggrecation logic and caused 400 ms
timeouts when receiving multicast frames from AP.
A simple way to fix is to pass only unicast frames for aggregation.
100 packets transmitted, 99 received, 1% packet loss, time 99144ms
rtt min/avg/max/mdev = 2.083/13.084/403.390⁄56.794 ms
Signed-off-by: Kalle Valo firstname.lastname@example.org
drivers/net/wireless/ath/ath6kl/txrx.c | 16 **+——-
1 files changed, 9 insertions(+), 7 deletions(-)
diff –git a/drivers/net/wireless/ath/ath6kl/txrx.c
index fffd929..348c646 100644
@ -1230,9 +1230,15@ void ath6kl_rx(struct htc_target *target,
struct htc_packet *packet)
static void aggr_timeout(unsigned long arg)
@ -1249,10 +1255,6@ static void aggr_timeout(unsigned long arg)
if (rxtid->timer_mon || rxtid->progress)
“I note that while the improvement above is enormous, a 403ms RTT for
a packet is the rough equivalent of a detour around all of planet Earth…
between your couch and the AP.
Can outliers of this sort be improved?
At what point are packets dropped?”
One - multicast should be scheduled separately in the general case.
I have come up with a string of methods to make handling multicast much, much saner, but it pees on many levels of the stack, at the moment. That said, I think the pieces are falling in place, with the new ‘birthday free mac classifier’