Bug #272

Fwd: multicast really can mess up your whole day [PATCH] ath6kl: pass only unicast frames for aggregation

Added by David Taht over 1 year ago. Updated over 1 year ago.

Status:In Progress Start date:
Priority:Normal Due date:
Assignee:Dave Täht % 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 <>
Date: Mon, Sep 19, 2011 at 11:38 AM
Subject: [PATCH] ath6kl: pass only unicast frames for aggregation
To:

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 <>
---
 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'

Also available in: Atom PDF