While I'm being overly vague and general... * Doing some form of ack compression (whether in the tcp stack or in mac80211) seems useful. It's really hard to fill 4Mbytes one way and the needed number of acks the other. I'd also pointed out (on some thread on the make-wifi-fast list that I can't find right now) that drivers had a tendency to eat an entire txop for that first single ack and ping pong between empty and full on a one way tcp benchmark.
* Similarly grabbing air during the contention window. If the sender is grabbing 3x as much air as the reciever (A1 A2 A3 B1 A4 B2) * I know of one org that upped the codel target value for 802.11ac with decent results but I can't talk about it... (sort of why I asked for a cap). My problem with decreasing the pacing shift is that it makes for less interleaving (I think! have to look), where increasing the target compensates for more jittery networks. ('course my overall theme of my prior post was to reduce jittery networks with less buffering and smaller txops overall) * Is this a two device test? or a test through an AP? Looking over this thread, I see a suggestion is to expose the pacing rate via a sysctl. I don't think there's any one answer, either, but I'm not sure this is the right variable to expose. Perhaps a tunable for latency that might (one day) look at multiple variables and decide? Getting this more right is really a job for an algorithm of minstrel-like complexity. _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k