New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#44 - Ath9k - TX performance regression on greater coverage settings #6030
Comments
xback: Gathered more data:
--> same procedure for 14400m It seems less frames get queued in the TX queue for some reason .. See attached PDF |
Bluse: Hi, While reading through your report, the following question comes to my mind. Greetings Bluse ps: Please provide the Lede version/commit your test setup is running on in order to reproduce on my side |
xback: Hi Bluse, Thanks for your response. You can take the latest available trunk when reading this. No, In my setup using BarrierBreaker release, the expected (and measured) performance penalty is about 10%
On the latest trunk, the penalty is 83% Also, before anyone suggests:
I've spend nearly a week trying to fix it, but until now only can report some details seen:
The attached log in previous comment shows that actually less frames get scheduled, so it makes sense less frames get aggregated. 3 thinks I can think about causing it:
Thanks for you help. Koen |
xback: Hi Bluse, Were you able to reproduce this? Thanks again, Koen |
Bluse: Hi Koen, Your observation is by design of the standard and not a malfunction, check IEEE 802.11-2007 17.3.8.6 [[http://www.ie.itcr.ac.cr/acotoc/Ingenieria/Lab%20TEM%20II/Antenas/Especificacion%20802%2011-2007.pdf|IEEE 802.11-2007]]: So the coverage class set by UCI distance will increase the ack timeout and the slottime. A increased slottime will decrease throughput as the channel access timings are relaxed. Greatings from Berlin |
xback: Hi Bluse, Thanks again for your time looking into this. When I encountered this "bug", this was the first part I checked :) So it's not the reason for the regression. I'll upload the mac80211 (incl ath9k) from both my builds tomorrow and provide a link. I've checked and compared the full ath9k driver to search for the rootcause, When this bug occurs (coverage increases) mac80211 is re-calling this functions at a lower pace. Thanks again, Koen |
Bluse: Hi Koen, I just set up a two router experiment on my desk. on AP: disbale Minstrel_HT ratecontrol and set fixed rate to MSC 15 scenario 1: distance set to 50 scenario 1: distance set to 14000 So throughput got halved when I go to 14000m and aggragation shows the same amount of packets per aggregate and obviously half of overall aggregates as throughput is halved. I do not have a feeling of how much decrese in throughput to expect when coverage class goes up and slottime is increased, but it looks like a results I would expect somehow. Could you re-run your experiment with the slottime adjustment patch reverted ? Greetings from Berlin |
xback: Hi Bluse, //2,4 GHz HT20// I'm testing on 5GHz IBSS mode //on Laptop A: iperf -s -u Could you try: //scenario 1: distance set to 14000 Did you restart the iperf client on B after increasing the Cov Class? In my case:
When checking this part: //aggregates ~ 2000 (from xmit) In step1: Avg Aggregated frames: ~6.5 step1 bw: [ 4] 17.00-18.01 sec 8.57 MBytes 71.4 Mbits/sec 0 400 KBytes step2 bw: [ 4] 13.00-14.00 sec 8.49 MBytes 71.3 Mbits/sec 0 387 KBytes Step3 bw: [ 4] 215.00-216.00 sec 905 KBytes 7.41 Mbits/sec 0 31.1 KBytes IBSS wpa_supplicant config settings for both ends: ctrl_interface=DIR=/tmp/run/wpa_supplicant GROUP=root Please let me know if you need more info, Koen |
Bluse: Hi Koen, In order to troubleshoot your performance decrease I suggest to disable control loops on differnt network layers which try to adapt the throughput in a certain manner. -use UDP and not TCP for your testsetup, to saturate the IP packet transfer What does 50m and 14000m provide on throughput / packets per aggregate ? Greetings from Berlin |
xback: Bug in kernels starting from 3.19.0. I've made a patch which fixes the issue waiting for approval from the initial patch creator. |
xback: The patch will not be accepted as it basically reverts this commit. The main issue is that TCP does not ramp-up as mac80211 queueing introduces delay on TCP ack which is amplified if coverage distance is increased. Therefore TCP is stuck at this low rate. I exchanged some mails with Eric Dumazet, and he points out that mac80211/ath9k should complete TX faster in order to ramp-up TCP speed. At this point, I lack the detailed knowledge to properly investigate/fix this. Hopefully later on .. |
xback: For archival reasons, I'll post my custom patch below which fixes single-stream TCP performance issues on greater coverage distances. [1] Since the change in the TCP stack which causes this, an ACK should be received within 1ms in order to ramp-up speed which is nearly impossible to satisfy on this kind of setup. Also, a nice discussion can be found here: [2] After this post, I'll request for closure as this is not a LEDE issue. [1] --- a/net/ipv4/tcp_output.c
[2] |
xback:
Synopsis:
When increasing coverage distance on the transmitting device, frame aggregation is heavily reduced.
Even when conditions are perfect.
This is regression compared to the BarrierBreaker release.
Hardware used:
2x cns3xxx GW-2388, each containing a single SR71-15
Setup:
Repro rate:
100%
Repro steps:
Obervations:
Other observations:
When stopping and restarting iperf it drops again to 7Mbit/s
In barrierbreaker release, increasing coverage distance to 10000m dropped to the throughput to ~50Mbit iso 7
The text was updated successfully, but these errors were encountered: