While playing around with rate scaling, and testing behaviour when
increasing the distance to the AP, I noticed that a lot of successfully
received frames end up getting stuck or discarded in the block ack
buffer logic.
In this situation, I see icmp echo replies arrive in the output
of tcpdump -i iwm0 -y IEEE802_11_RADIO -v, but those replies don't
reach the ping program in userspace. And when they do, they arrive
with a huge delay (up to several seconds).
This diff tunes block ack parameters to vastly reduce buffering timeout.
With this, as long as we receive echo replies, they are very likely to
reach the ping program. In my testing, some pings still get lost and
some get delayed, but it seems latency now depends mostly on how fast
the AP chooses a lower data rate -- and once the incoming rate settles
at 1Mbit/s, traffic flows smoothly again.
Under ideal wifi signal conditions, this diff should make no difference.
OK?
Index: ieee80211_node.h
===================================================================
RCS file: /cvs/src/sys/net80211/ieee80211_node.h,v
retrieving revision 1.63
diff -u -p -r1.63 ieee80211_node.h
--- ieee80211_node.h 21 Sep 2016 12:21:27 -0000 1.63
+++ ieee80211_node.h 18 Nov 2016 13:10:59 -0000
@@ -146,13 +146,13 @@ struct ieee80211_rx_ba {
u_int16_t ba_winsize;
u_int16_t ba_head;
struct timeout ba_gap_to;
-#define IEEE80211_BA_GAP_TIMEOUT 300 /* msec */
+#define IEEE80211_BA_GAP_TIMEOUT 5 /* msec */
/* Counter for consecutive frames which missed the BA window. */
int ba_winmiss;
/* Sequence number of previous frame which missed the BA window. */
uint16_t ba_missedsn;
/* Window moves forward after this many frames have missed it. */
-#define IEEE80211_BA_MAX_WINMISS 8
+#define IEEE80211_BA_MAX_WINMISS 3
uint8_t ba_token;
};
