Bug #272
Fwd: multicast really can mess up your whole day [PATCH] ath6kl: pass only unicast frames for aggregation
| Status: | In Progress | Start date: | |||
|---|---|---|---|---|---|
| Priority: | Normal | Due date: | |||
| Assignee: | % Done: | 10% |
|||
| Category: | Networking | Spent time: | 20.00 hours | ||
| Target version: | Cerowrt-1.0-rc8 | Estimated time: | 200.00 hours |
Description
multicast really can mess up your whole day.
---------- Forwarded message ----------
From: Kalle Valo <kvalo@qca.qualcomm.com>
Date: Mon, Sep 19, 2011 at 11:38 AM
Subject: [PATCH] ath6kl: pass only unicast frames for aggregation
To: linux-wireless@vger.kernel.org
When pinging form ar6003 to the AP RTT was high even when power save was
disabled:
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. This
improves RTT:
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 <kvalo@qca.qualcomm.com>
---
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
b/drivers/net/wireless/ath/ath6kl/txrx.c
index fffd929..348c646 100644
--- a/drivers/net/wireless/ath/ath6kl/txrx.c
+++ b/drivers/net/wireless/ath/ath6kl/txrx.c@ -1230,9 +1230,15 @ void ath6kl_rx(struct htc_target *target,
struct htc_packet *packet)
ath6kl_data_tx(skb1, ar->net_dev);
}
- if (!aggr_process_recv_frm(ar->aggr_cntxt, tid, seq_no,
- is_amsdu, skb))
- ath6kl_deliver_frames_to_nw_stack(ar->net_dev, skb);
+ datap = (struct ethhdr ) skb->data;
if (is_unicast_ether_addr(datap->h_dest) &&
+ aggr_process_recv_frm(ar->aggr_cntxt, tid, seq_no,
+ is_amsdu, skb))
+ / aggregation code will handle the skb */
+ return;
ath6kl_deliver_frames_to_nw_stack(ar->net_dev, skb);
}
static void aggr_timeout(unsigned long arg)@ -1249,10 +1255,6 @ static void aggr_timeout(unsigned long arg)
if (!rxtid->aggr || !rxtid->timer_mon || rxtid->progress)
continue;
- /*
- * FIXME: these timeouts happen quite fruently, something
- * line once within 60 seconds. Investigate why.
- */
stats->num_timeouts++;
ath6kl_dbg(ATH6KL_DBG_AGGR,
"aggr timeout (st %d end %d)\n",
History
Updated by Jim Gettys over 1 year ago
- Category set to Performance
Updated by David Taht over 1 year ago
I'd sent this comment to the list:
"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?"
Updated by Dave Täht over 1 year ago
I note that this is not a specific to cerowrt bug, just a note to myself to check the multicast routine for correctness overall.
Updated by Dave Täht over 1 year ago
- Category changed from Performance to Networking
- Status changed from New to In Progress
- Assignee set to Dave Täht
- Target version set to Cerowrt-1.0-rc8
- % Done changed from 0 to 10
- Estimated time set to 200.00
I checked the multicast handling throughout linux actually/ Oh, god, this needs to be handled with more intelligence.
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'