Linux-Amlogic Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Armstrong <neil.armstrong@linaro.org>
To: linux-amlogic@lists.infradead.org
Subject: Re: [RESEND] Throughput & CPU usage of WiFi download
Date: Tue, 4 Apr 2023 15:36:34 +0200	[thread overview]
Message-ID: <3d5980b4-670d-0d13-f74e-e689d37ca653@linaro.org> (raw)
In-Reply-To: <f2344e2e-2b53-9f57-d15a-25e5b03b3029@free.fr>

On 04/04/2023 14:54, Marc Gonzalez wrote:
> [ Re-sending, because gmail blocks messages with img extension, even within archives
>    Great job Microsoft for inferring file type based on file extension... ]
> 
> Hello everyone,
> 
> I've been benchmarking various aspects of an SEI530 board,
> and wanted to share some of the results with the list.
> 
> The main objective was to compare WiFi download performance
> on mainline/BR2 and vendor/android systems.
> 
> (Mainline system was generated using pop-br2-ext-tree.zip.
> brcmfmac4359-sdio.* left out for size.)
> 
> https://pixeldrain.com/u/qH3YotXP
> 
> 
> HW spec
> Board: SEI530 (SEI510 variant)
> SoC: S905X2
> WiFi: AP6398SR3-J (SDIO BCM4359/9)
> 
> Test setup
> WiFi AP using 5Ghz channels 120 (primary) + 116 (secondary)
> BENCHMARK = "curl --silent -o /dev/null http://192.168.1.254:8095/fixed/10G"
> Kernel booted with
> 1) performance governor (no DVFS)
> 2) nohlt (keep counting cycles in idle)
> 
> 
> (Full results at the end)
> 
> Observations:
> - vendor system manages 245 Mbps, using 40% CPU
> - mainline system manages 60 Mbps, using 10% CPU
> - vendor system limited to 62 Mbps, uses 9% CPU
> 
> 1) Neil Armstrong mentioned that vendor kernel reaches
> higher throughput by playing tricks with some pads?
> (Not sure I understood that well, haven't looked at the code)

Vendor kernel uses the SDCard controller by swapping the SDIO lines,
so they use a fully functional controller unlike mainline.

And you should use the same Vendor BCMDHD driver on mainelin.

So the comparison isn't fair.

> 
> 2) SDIO is clocked higher on vendor system, but could
> lead to instabilities on some boards?
> 
> Interesting possible followups
> - try clocking SDIO higher on mainline system
> - measure CPU usage at 120 Mbps, does it scale linearly to 20%?
> - android curl seems to use smaller buffers?
> 
> 
> TEST RESULTS
> 
> -- mainline/BR2 (v6.2)
> 
> time perf record -a -F 1009 $BENCHMARK
> perf report -s pid -n --header
> 
> 10_GB in 1338.127552_s = 59.8_Mbps
> 
> # Overhead       Samples      Pid:Command
>    90.0445%       4863024        0:swapper = IDLE
>     7.2362%        390807       56:irq/17-ffe03000
>     1.9282%        104136       59:kworker/u9:0-br
>     0.6965%         37616      142:curl
>     0.0722%          3897      114:ksdioirqd/mmc2
>     0.0168%           908      141:perf
> 
> 
> -- vendor/android (4.9.180 + vendor patches)
> 
> time simpleperf record -a -f 1009 $BENCHMARK
> simpleperf report --sort pid,comm
> 
> 10_GB in 326.54_s = 245_Mbps
> 
> Overhead  Sample  Pid    Command
> 59.43%    680339  0      swapper = IDLE
> 12.59%    156593  15378  curl
> 11.42%    136024  4392   dhd_rxf
> 7.57%     88047   4391   dhd_dpc
> 2.52%     29977   2094   irq/51-meson-am
> 1.38%     16467   10541  system_server
> 0.75%     10394   17     ksoftirqd/1
> 0.73%     9282    15377  simpleperf
> 0.60%     9226    6      ksoftirqd/0
> 0.38%     4701    14865  kworker/0:0
> 0.14%     2055    29     ksoftirqd/3
> 0.13%     1636    3411   HwBinder:3411_1
> 0.13%     1760    23     ksoftirqd/2
> 0.12%     1484    10782  dmx_data_thread
> 0.12%     1469    3381   composer@2.3-se
> 0.10%     1329    15425  Jit thread pool
> 
> 
> Same benchmark, rate limited to 8 MB/s
> time simpleperf record -a -f 1009 $BENCHMARK --limit-rate 8M
> simpleperf report --sort pid,comm
> 
> 10_GB in 1290.22_s = 62 Mbps
> 
> Overhead  Sample   Pid    Command
> 91.68%    3687632  0      swapper = IDLE
> 2.67%     107057   4392   dhd_rxf
> 1.90%     74721    4391   dhd_dpc
> 1.00%     41650    22975  curl
> 0.70%     29239    10541  system_server
> 0.68%     27406    2094   irq/51-meson-am
> 0.58%     24781    22974  simpleperf
> 0.10%     4222     17     ksoftirqd/1
> 0.10%     4070     10782  dmx_data_thread
> 
> 
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  reply	other threads:[~2023-04-04 13:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-04 12:12 Throughput & CPU usage of WiFi download Marc Gonzalez
2023-04-04 12:54 ` [RESEND] " Marc Gonzalez
2023-04-04 13:36   ` Neil Armstrong [this message]
2023-04-04 15:42   ` Marc Gonzalez

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=3d5980b4-670d-0d13-f74e-e689d37ca653@linaro.org \
    --to=neil.armstrong@linaro.org \
    --cc=linux-amlogic@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox