Hi Michael,
no, we did not try changing a-msdu/a-mpdu limits. We will take a look at
this, thanks.
Regarding the setup, these tests were run with two machines with three
ath10k devices each (QCA988x 802.11ac Wireless Network Adapter).
Kernel and firmware versions:
driver: ath10k_pci
version: 4.2.0+
firmware-version: 10.1.467-ct-com-full-014-96d543
We just enabled one interface on each machine and configured them in
ibss mode. Then we run hping3 (TCP and UDP) from one to another. The
equipments are at 4 meters distance with good line view.
Bests,
Iñaki
On 05/05/16 12:47, Michal Kazior wrote:
On 29 April 2016 at 19:12, Iñaki Pascual <[email protected]> wrote:
Hi,
I am measuring TCP and UDP latency (actually RTT) and I am getting too high
values when working with channels with 40MHz (also with 80MHz) width.
I am using hping3 for testing and these are the RTT avg values:
BW 20 MHz: TCP 0.9 UDP 1.1
BW 40 MHz: TCP 7.7 UDP 1.3
BW 80 MHz: TCP 3.5 UDP 1.3
Just 2cc. Did you try changing the a-msdu/a-mpdu limits in firmware?
You can tune it via debugfs file:
echo 3 64 > /sys/kernel/debug/ieee80211/phy0/ath10k/htt_max_amsdu_ampdu
The "3" stands for A-MSDU limit, "64" stands for A-MPDU limit. "3 64"
is the default. You can test, e.g.
- "1 64"
- "3 8"
- "1 1"
- "1 8"
And see if this changes TCP RTT in any way.
You didn't really tell your setup (or I missed it). Are you using
ath10k as AP, client, or both (i.e. have two ath10k supported
devices)?
Are you bridging traffic or is to locally generated? Perhaps there's a
problem with hw offloaded ip/tcp checksumming. You might want to
remove it from the driver (manually) to verify that or check tcpdump
to confirm whether OTA frames have correct checksums.
Michał
_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k
_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k
