All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wen Gong <wgong@codeaurora.org>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: ath10k@lists.infradead.org, johannes@sipsolutions.net,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
Date: Fri, 27 Jul 2018 17:29:00 +0800	[thread overview]
Message-ID: <e5f8de75e2464393e8664d8bf913a827@codeaurora.org> (raw)
In-Reply-To: <87zhye1aqg.fsf@toke.dk>

On 2018-07-26 19:45, Toke Høiland-Jørgensen wrote:
> Wen Gong <wgong@codeaurora.org> writes:
> 
>> Upstream kernel has an interface to help adjust sk_pacing_shift to 
>> help
>> improve TCP UL throughput.
>> The sk_pacing_shift is 8 in mac80211, this is based on test with 11N
>> WiFi chips with ath9k. For QCA6174/QCA9377 PCI 11AC chips, the 11AC
>> VHT80 TCP UL throughput testing result shows 6 is the optimal.
>> Overwrite the sk_pacing_shift to 6 in ath10k driver.
> 
> When I tested this, a pacing shift of 8 was quite close to optimal as
> well for ath10k. Why are you getting different results?

the default value is still 8 in the patch:
https://patchwork.kernel.org/patch/10545361/

In my test, pacing shift 6 is better than 8.
The test is for ath10k/11AC WiFi chips.
Test result is show in the commit logs before.
> 
>> Tested with QCA6174 PCI with firmware
>> WLAN.RM.4.4.1-00109-QCARMSWPZ-1, but this will also affect QCA9377 
>> PCI.
>> It's not a regression with new firmware releases.
>> 
>> There have 2 test result of different settings:
>> 
>> ARM CPU based device with QCA6174A PCI with different
>> sk_pacing_shift:
>> 
>>  sk_pacing_shift  throughput(Mbps)             CPU utilization
>>          6            500(-P5)      ~75% idle, Focus on CPU1: ~14%idle
>>          7            454(-P5)      ~80% idle, Focus on CPU1: ~4%idle
>>          8               288        ~90% idle, Focus on CPU1: ~35%idle
>>          9              ~200        ~92% idle, Focus on CPU1: ~50%idle
> 
> Your tests do not include latency values; please try running a test 
> that
> also measures latency. The tcp_nup test in Flent (https://flent.org)
> will do that, for instance. Also, is this a single TCP flow?
> 

It is not a single TCP flow, it is 500Mbps with 5 flows.

below is result show in commit log before:
5G TCP UL VTH80 on X86 platform with QCA6174A PCI with sk_packing_shift
set to 6:

   tcp_limit_output_bytes            throughput(Mbps)
  default(262144)+1 Stream                 336
  default(262144)+2 Streams                558
  default(262144)+3 Streams                584
  default(262144)+4 Streams                602
  default(262144)+5 Streams                598
  changed(2621440)+1 Stream                598
  changed(2621440)+2 Streams               601

> -Toke

WARNING: multiple messages have this Message-ID
From: Wen Gong <wgong@codeaurora.org>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: johannes@sipsolutions.net, linux-wireless@vger.kernel.org,
	ath10k@lists.infradead.org
Subject: Re: [PATCH 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
Date: Fri, 27 Jul 2018 17:29:00 +0800	[thread overview]
Message-ID: <e5f8de75e2464393e8664d8bf913a827@codeaurora.org> (raw)
In-Reply-To: <87zhye1aqg.fsf@toke.dk>

On 2018-07-26 19:45, Toke Høiland-Jørgensen wrote:
> Wen Gong <wgong@codeaurora.org> writes:
> 
>> Upstream kernel has an interface to help adjust sk_pacing_shift to 
>> help
>> improve TCP UL throughput.
>> The sk_pacing_shift is 8 in mac80211, this is based on test with 11N
>> WiFi chips with ath9k. For QCA6174/QCA9377 PCI 11AC chips, the 11AC
>> VHT80 TCP UL throughput testing result shows 6 is the optimal.
>> Overwrite the sk_pacing_shift to 6 in ath10k driver.
> 
> When I tested this, a pacing shift of 8 was quite close to optimal as
> well for ath10k. Why are you getting different results?

the default value is still 8 in the patch:
https://patchwork.kernel.org/patch/10545361/

In my test, pacing shift 6 is better than 8.
The test is for ath10k/11AC WiFi chips.
Test result is show in the commit logs before.
> 
>> Tested with QCA6174 PCI with firmware
>> WLAN.RM.4.4.1-00109-QCARMSWPZ-1, but this will also affect QCA9377 
>> PCI.
>> It's not a regression with new firmware releases.
>> 
>> There have 2 test result of different settings:
>> 
>> ARM CPU based device with QCA6174A PCI with different
>> sk_pacing_shift:
>> 
>>  sk_pacing_shift  throughput(Mbps)             CPU utilization
>>          6            500(-P5)      ~75% idle, Focus on CPU1: ~14%idle
>>          7            454(-P5)      ~80% idle, Focus on CPU1: ~4%idle
>>          8               288        ~90% idle, Focus on CPU1: ~35%idle
>>          9              ~200        ~92% idle, Focus on CPU1: ~50%idle
> 
> Your tests do not include latency values; please try running a test 
> that
> also measures latency. The tcp_nup test in Flent (https://flent.org)
> will do that, for instance. Also, is this a single TCP flow?
> 

It is not a single TCP flow, it is 500Mbps with 5 flows.

below is result show in commit log before:
5G TCP UL VTH80 on X86 platform with QCA6174A PCI with sk_packing_shift
set to 6:

   tcp_limit_output_bytes            throughput(Mbps)
  default(262144)+1 Stream                 336
  default(262144)+2 Streams                558
  default(262144)+3 Streams                584
  default(262144)+4 Streams                602
  default(262144)+5 Streams                598
  changed(2621440)+1 Stream                598
  changed(2621440)+2 Streams               601

> -Toke

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

  parent reply	other threads:[~2018-07-27 10:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-26  7:21 [PATCH 0/2] Change sk_pacing_shift in ieee80211_hw for best tx throughput Wen Gong
2018-07-26  7:21 ` Wen Gong
2018-07-26  7:21 ` [PATCH 1/2] mac80211: Save sk_pacing_shift to ieee80211_hw Wen Gong
2018-07-26  7:21   ` Wen Gong
2018-07-26 14:52   ` kbuild test robot
2018-07-26 14:52     ` kbuild test robot
2018-07-27  8:35     ` Wen Gong
2018-07-27  8:35       ` Wen Gong
2018-07-27  9:30       ` Kalle Valo
2018-07-27  9:30         ` Kalle Valo
2018-07-26  7:21 ` [PATCH 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips Wen Gong
2018-07-26  7:21   ` Wen Gong
2018-07-26 11:45   ` Toke Høiland-Jørgensen
2018-07-26 11:45     ` Toke Høiland-Jørgensen
2018-07-26 13:02     ` Michał Kazior
2018-07-26 13:02       ` Michał Kazior
2018-07-27  9:39       ` Wen Gong
2018-07-27  9:39         ` Wen Gong
2018-07-27 12:33         ` Michał Kazior
2018-07-27 12:33           ` Michał Kazior
2018-07-27  9:29     ` Wen Gong [this message]
2018-07-27  9:29       ` Wen Gong
2018-07-27 20:06       ` Toke Høiland-Jørgensen
2018-07-27 20:06         ` Toke Høiland-Jørgensen
  -- strict thread matches above, loose matches on Subject: below --
2018-07-26  7:16 [PATCH 0/2] Change sk_pacing_shift in ieee80211_hw for best tx throughput Wen Gong
2018-07-26  7:16 ` [PATCH 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips Wen Gong
2018-07-26  7:16   ` Wen Gong

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=e5f8de75e2464393e8664d8bf913a827@codeaurora.org \
    --to=wgong@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=toke@toke.dk \
    --subject='Re: [PATCH 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips' \
    /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

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.