All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Iñaki Pascual" <ipascual@cttc.cat>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: "ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: high RTT in 40 MHz channel width
Date: Thu, 5 May 2016 13:05:08 +0200	[thread overview]
Message-ID: <572B28E4.1000906@cttc.cat> (raw)
In-Reply-To: <CA+BoTQ=gkuKBfryb5_E6sB9NxhbRZVyzuTa4LMEo58OSmBs6DQ@mail.gmail.com>

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@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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

      reply	other threads:[~2016-05-05 11:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-29 17:12 high RTT in 40 MHz channel width Iñaki Pascual
2016-04-30 16:39 ` Jose Núñez-Martínez (CTTC)
2016-04-30 16:50   ` Ben Greear
2016-05-05 10:36     ` Iñaki Pascual
2016-05-05 10:47 ` Michal Kazior
2016-05-05 11:05   ` Iñaki Pascual [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=572B28E4.1000906@cttc.cat \
    --to=ipascual@cttc.cat \
    --cc=ath10k@lists.infradead.org \
    --cc=michal.kazior@tieto.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.