Skip to main content
You can access performance dashboards for boot time, system benchmarks, memory map, and product segment key performance indicators (KPIs) on the Qualcomm® Linux® reference devices. The following subsections describe the performance dashboards and measurement procedures for QCS6490, QCS5430, and Qualcomm Dragonwing™ IQ-615. For Qualcomm Dragonwing™ IQ-9075 and Qualcomm Dragonwing™ IQ-8275 performance dashboards and measurement procedures, see the corresponding addendum. The following guides provide supplementary information and these guides are available to licensed users with authorized access:

​
Boot time

The following boot time KPIs indicate system readiness at different stages:
  • Init/systemd process : The time elapsed from power-on until the system’s first user-space process (PID 1, typically systemd) starts executing. This includes the time taken by Firmware, Loader and Kernel+InitramFS.
  • Camera driver init finish : Indicates that the camera hardware has completed initialization and is ready for use.
  • Sysinit.target: The time from power-on until sysinit.target is reached — the point where all essential system initialization services (file systems mounted, kernel modules loaded, basic hardware configured) have completed.
The following table lists the measured boot time (values in seconds) on QCS6490 (flashed with UEFI firmware).
Use caseScore
Boot time till Init/systemd process3.98
Boot time till Camera driver init finish7.20
Boot time till Sysinit.target8.12
A lower boot time score is better.
Configuration 1 (qcom-multimedia-image) Configuration 1 represents the upstream package set, which includes open-source and baseline multimedia components provided as part of the standard Qualcomm multimedia image.Configuration 2 (qcom-multimedia-proprietary-image) Configuration 2 represents the downstream package set, which includes proprietary multimedia components, enhancements, and vendor-specific additions layered on top of the upstream image.For information about the measurement procedure, see Measure boot time.

​
System benchmarks

This section outlines how system performance is measured using a set of standard benchmarks. The following tables list the CPU, memory, storage, and graphics benchmark scores on QCS6490.Geekbench
BenchmarkVersionBenchmark score
Geekbench ST6.1.01184
Geekbench MT6.1.03025
CoreMark
BenchmarkScore (Iterations/sec)
CoreMark26202.02
Tiotest
TestConfigurationScore
Sequential write256 MB/thread at 512 KiB blocks (MB/second)497.29
Sequential read256 MB/thread at 512 KiB blocks (MB/second)973.18
Random write64 MB/thread at 4 KiB blocks (IOPS)58468
Random read64 MB/thread at 4 KiB blocks (IOPS)58675
GLmark2
BenchmarkScore
GLmark22249
GLmark2 1920 × 10801491
GLmark2 offscreen580
GLmark2 offscreen 1920 × 1080439
Sysbench
BenchmarkScore
CPU total time (second)3.19
Memory bandwidth (MB/second)4452.23
Thread total time (second)3.44
Mutex total time (second)0.0045
For information about the measurement procedure, see Measure system benchmarks.
A higher system benchmark score is better, except for CPU total time, thread total time, and Mutex total time where a lower value is better.

​
Memory map

The following table lists the memory consumption (values in MB) for each partition, such as non-Linux, kernel static, and applications. It also lists the total free memory available to the system after device boot and during use cases such as 4k resolution encoding at 30 fps.
Memory partitionsAfter boot
Total RAM6144
Non-Linux624
Kernel static214
Applications + framework509
Total free memory4797
For information about the measurement procedure, see Measure memory map.
A higher total free memory value is better for the system performance.

​
Use case KPIs

The following table lists the camera latency measurement data (values in seconds) for various QCS6490 camera use cases:
Use caseLatency definitionLatency
4K first snapshot latencyFirst time after boot, time taken from capturing an image to creating a snapshot0.34
A lower camera latency value is better.
For information about the measurement procedure, see Measure camera recording/snapshot latency.

​
Measurement procedures

The measurement procedures include KPIs, such as boot time, system benchmark, record latency, and snapshot latency.

​
Measure boot time

To measure boot time, do the following:
  1. Flash a build. See Flash software images to boot the device.
  2. After the device is up, reboot it.
  3. Connect to the device console using a serial cable. a. Connect a serial cable between the device and the Linux host PC. b. Connect to the UART terminal using credentials ( user: root, password: oelinux123 ). See Connect to a UART shell. c. Power-off and on the device.
Boot time KPIs can be measured by capturing systemd-analyze and journalctl logs after the device boots up and stabilized. 
systemd-analyze > /var/lib/systemd-analyze.txt

journalctl --output=short-monotonic -b --no-pager -l > /var/lib/journalctl.txt

grep Startup /var/lib/systemd-analyze.txt
Expected output: Startup finished in 1.697s (firmware) + 402ms (loader) + 1.693s (kernel) + 15.887s (userspace) = 19.681s 
grep "camera driver initialized rc : 0" var/lib/journalctl.txt
Expected output: [ 4.220245] iq-615-evk kernel: CAM_INFO: CAM-UTIL: cam_main_probe: 336: Spectra camera driver initialized rc : 0 
grep "Reached target System Initialization." /var/lib/journalctl.txt
Expected output: [ 4.757850] iq-615-evk systemd[1]: Reached target System Initialization. 
Boot time till Init/systemd process = Firmware + Loader + Kernel = 1.697 + 0.402 + 1.693 = __3.892s__ 

Boot time till Camera driver init finish =  Firmware + Loader + journalctl timestamp of "camera driver initialized" = 1.697 + 0.402 + 4.220 = __6.319s__

Boot time till Sysinit.target = Firmware + Loader + journalctl timestamp of "Reached target System Initialization" = 1.697 + 0.402 + 4.757 = __6.856s__
The Firmware and Loader times are taken from systemd-analyze output (1.697s + 0.402s). The kernel timestamps in journalctl are relative to kernel start, so Firmware + Loader time is added to get the absolute boot time from power-on.

​
Measure system benchmarks

These benchmarks measure the performance of subsystems such as CPU throughput, memory bandwidth, memory latency, and I/O performance. Prerequisites Before running any benchmark, complete the following setup:
ADB isn’t enabled by default on the device. To enable ADB before running these benchmarks, see Enable ADB.
  1. Flash the build.
  2. Run the following command to get root access: 
    adb root
  3. Open a shell on the device: 
    adb shell
  4. Navigate to the directory where the binary is pushed: 
    cd /usr/bin
  5. Set execute permissions on the binary: 
    chmod 777 <binary>
Geekbench Geekbench is a tool used to measure system performance against the established benchmarks. To measure system performance using Geekbench, do the following:
  1. To download Geekbench from the Linux/ARM section from upstream, see Geekbench.
The Geekbench 6 for Linux/AArch64 is a preview build. The Geekbench versions may change and the steps mentioned in this section are for your reference. The preview builds require an active Internet connection and automatically upload benchmark results to the Geekbench browser.
  1. To measure a CPU benchmark using Geekbench, do the following:
    1. Unzip the Geekbench file and push it from the host using adb tool. The following are the example commands: 
      adb push Geekbench-6.3.0-LinuxARMPreview /var/cache/

      cd /var/cache

      chmod 777 Geekbench-6.3.0-LinuxARMPreview/*
    2. To run Geekbench, run the following commands on the device: 
      cd Geekbench-6.3.0-LinuxARMPreview

      ./geekbench_aarch64
Sysbench Sysbench measures CPU, memory, thread, mutex, and file I/O performance. To run Sysbench tests, run the following commands on the device: 
./sysbench --test=cpu run
./sysbench --test=memory run
./sysbench --test=threads run
./sysbench --test=mutex run
./sysbench --test=fileio --file-test-mode=seqwr run
./sysbench --test=fileio --file-test-mode=seqrd run
./sysbench --test=fileio --file-test-mode=rndrd run
./sysbench --test=fileio --file-test-mode=rndwr run
To run with taskset: 
taskset <taskset> ./sysbench --test=<test_name> run
Tiotest Tiotest measures storage I/O performance. To run Tiotest, do the following:
  1. Run the sequential I/O test: 
    /data/tio/tiotest -t 8 -d /data/tio -f 256 -b 524288 -k3 -k1 --direct-io sync=1
  2. Run the random I/O test: 
    /data/tio/tiotest -t 8 -d /data/tio -f 64 -b 4096 -k2 -k0 2012 -r 12500 20 --direct-io sync=1
  3. Drop the cache between iterations: 
    echo 3 > /proc/sys/vm/drop_caches
CoreMark CoreMark measures embedded processor performance. To run CoreMark, run the following command on the device: 
./coremark.exe
The following is an example output: 
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 15268
Total time (secs): 15.268000
Iterations/Sec   : 26198.585276
Iterations       : 400000
Compiler version : GCC11.4.0
Compiler flags   : -O2 -DPERFORMANCE_RUN=1  -lrt
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x65c5
Glmark2 Glmark2 measures GPU rendering and graphics performance. To run Glmark2, do the following:
  1. Configure the Wayland runtime environment:
export XDG_RUNTIME_DIR=/dev/socket/weston
mkdir --parents $XDG_RUNTIME_DIR
chmod 0700 $XDG_RUNTIME_DIR
export WAYLAND_DISPLAY=wayland-1
  1. Run the off-screen test at default resolution:
./glmark2-es2-wayland --off-screen --data-path /usr/share/glmark2
  1. Run the off-screen test at 1920x1080 resolution:
./glmark2-es2-wayland --off-screen -s 1920x1080 --data-path /usr/share/glmark2
  1. Run the on-screen test at default resolution:
./glmark2-es2-wayland --data-path /usr/share/glmark2
  1. Run the on-screen test at 1920x1080 resolution:
./glmark2-es2-wayland -s 1920x1080 --data-path /usr/share/glmark2

​
Measure memory map

A memory map provides information on how memory is allocated for different processes. A memory map measurement allows you to monitor a mapped process and troubleshoot any memory issues. To calculate the memory map, boot the device and stabilize it. Then, run the following commands to collect logs from the device: 
cat /proc/meminfo

cat /proc/iomem

cat /proc/vmstat
Non-Linux memory Use the following formula to calculate the non-Linux memory: Non-Linux = Total RAM size − Total Linux Run the following command to calculate the total RAM size: 
cat /proc/meminfo | grep -i "MemTotal"
To calculate the total Linux memory from iomem, run the following command: 
cat /proc/iomem | grep System
Kernel static Use the following formula to calculate the kernel static: Kernel static = Total Linux − MemTotal Application + framework memory calculation Use the following formula to calculate the memory used by the applications and framework: Application + framework = MemTotal − Free memory Free memory calculation Use the following formula to calculate the free memory: Free memory = MemFree + (Cached − shmem) + buffer + ION cache To obtain the free memory details, run the following command: 
cat /proc/meminfo
To check the vmstat logs for ION cache, run the following command: 
cat /proc/vmstat

​
Measure camera recording/snapshot latency

This topic describes the camera recording/snapshot latency measurement procedure. To complete the prerequisites on every reboot, run the following commands on the device: 
mount -t debugfs none /sys/kernel/debug

setprop persist.qmmf.kpi.debug 2
First record latency To capture the logs, follow these steps:
  1. Boot the device and wait for it to stabilize.
  2. In one shell, run the following command: 
    cat /sys/kernel/debug/tracing/trace_pipe > trace.log
  3. In another shell, run the use case.
  4. Stop the trace log.
  5. See the reference table below to measure the record latency.
First snapshot latency
  1. Boot the device.
  2. After the device stabilizes, in one shell, run the following command: 
    cat /sys/kernel/debug/tracing/trace_pipe > trace.log
  3. In another shell, run the use case.
  4. Stop the trace log.
  5. See the reference table below to measure snapshot latency.
Reference table for measurement
Use casesLog markerCalculation
Record latency273.082629: tracing_mark_write: B|Connect
273.119992: tracing_mark_write: B|StartCamera
276.722946: tracing_mark_write: B|CreateVideoTrack
276.731158: tracing_mark_write: B|StartVideoTrack
277.306283: tracing_mark_write: E|FirstVidFrame|1		Connect to Start Camera = StartCamera − Connect
StartCamera to CreateVideoTrack = CreateVideoTrack − StartCamera
CreateVideoTrack to StartVideoTrack = StartVideoTrack − CreateVideoTrack
StartVideoTrack to FirstVidFrame = FirstVidFrame − StartVideoTrack
Rec latency = sum of above all
Snapshot latency303.975067: tracing_mark_write: S|FirstCapImg|0
304.544265: tracing_mark_write: S|SnapShot-Shot|0		Snapshot latency = snapshot − FirstCapimg