[ 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)
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 [email protected]
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
On 04/04/2023 14:54, Marc Gonzalez wrote:
> 2) SDIO is clocked higher on vendor system, but could
> lead to instabilities on some boards?
Apparently, I remembered wrong.
For mainline, arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
bus-width = <4>;
cap-sd-highspeed;
sd-uhs-sdr50;
max-frequency = <100000000>;
For vendor, common/arch/arm64/boot/dts/amlogic/mesong12a_sei.dtsi
bus-width = <4>;
cap-sd-highspeed;
cap-mmc-highspeed;
max-frequency = <100000000>;
The vendor DTS has the following child node:
sdio {
pinname = "sdio";
ocr_avail = <0x200080>; /**VDD voltage 3.3 ~ 3.4 */
/* max_req_size = <0x20000>; */ /**128KB*/
max_req_size = <0x400>;
card_type = <3>;
/* 3:sdio device(ie:sdio-wifi),
* 4:SD combo (IO+mem) card
*/
dmode = "pio";
};
Thus, it seems that the performance delta comes from driver architecture
and different HW setup, rather than clock difference.
Regards