high RTT in 40 MHz channel width

[Iñaki Pascual]

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 <ipascual at cttc.cat> 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
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k