ThomasKaiser
commented
2 months ago could you please share some information of the tool you're using for IO benchmark?
He's using https://raw.githubusercontent.com/geerlingguy/pi-cluster/master/benchmarks/disk-benchmark.sh to be called as explained in any of his sbc-review issues, e.g. this
There are at least three problems with this script, one being a major one:
- for whatever reasons the script determines sequential read performance with
fioand 4 jobs in parallel while sequential write performance will be measured withiozonein a different fashion and as such both numbers don't match (just tested: whenfioreports 85 MB/s sequential reads with 4 concurrent jobs,iozonewill measure just ~75 MB/s with a single job).fiodoes allow for non-destructive write testings with also 4 concurrent jobs (which BTW is a synthentic benchmark scenario not matching real-world situations of SBC users), no idea why Jeff doesn't switch to bothfiofor writes (creating another unrealistic number) or toiozonefor both numbers (all that's needed is another-i 1added to command line) - 1M block size and only 100M data size for the
iozonetests will not show real performance on many devices - but most importantly:
disk-benchmark.shis in realitydisk-settings-benchmark.shsince it trusts in whatever (stupid) settings the OS image is running with.
To talk about disk performance a switch to performance governor would be needed prior to execution [1]
Quick test on a Rock 5 ITX with an 256 GB EVO Plus A2 SD card comparing three different settings:
performance (this represents 'storage performance w/o settings involved'):
READ: bw=87.2MiB/s (91.4MB/s), 87.2MiB/s-87.2MiB/s (91.4MB/s-91.4MB/s), io=999MiB (1048MB), run=11459-11459msec
random random
kB reclen write rewrite read reread read write
102400 4 2848 2924 12238 2971
102400 1024 62283 62087 77176 61358In contrast Radxa's defaults since 2022 and Armbian defaults until 2024: ondemand with io_is_busy=1:
READ: bw=81.4MiB/s (85.4MB/s), 81.4MiB/s-81.4MiB/s (85.4MB/s-85.4MB/s), io=935MiB (980MB), run=11482-11482msec
random random
kB reclen write rewrite read reread read write
102400 4 2838 2940 11663 2921
102400 1024 60790 62549 77639 60492 We see small drops in performance everywhere and also a bit of results variation since 2940 KB/s with ondemand compared to 2924 KB/s with performance can't be the result of settings since no other governor can 'outperform' performance:
Retesting with schedutil since being the new Armbian default from 2024 on and also what many SBC vendors might be using since for their OS images they usually don't think a single second about kernel config but just ship with the Android kernel the SoC vendor has thrown at them:
READ: bw=85.1MiB/s (89.3MB/s), 85.1MiB/s-85.1MiB/s (89.3MB/s-89.3MB/s), io=978MiB (1026MB), run=11490-11490msec
random random
kB reclen write rewrite read reread read write
102400 4 2062 2193 8973 2165
102400 1024 54671 53655 61013 54159 Compared to ondemand with the respective tweaks the important 4K performance dropped by 25%, with larger block sizes it's not that drastic and the fio test with the unrealistic 4 concurrent read jobs even improves (but since we haven't measured at least 3 times we have no idea whether these different numbers are due to different settings or more probably: 'results variation'. Running a benchmark only once is almost always wrong, it has to be repeated at least three times, then standard deviation has to be calculated and if too high either more measurements or results go into trash).
But what these synthetic benchmarks don't tell anyway: real-world storage performance that is easily halved by the switch to schedutil since unlike benchmarks with continuous storage access where the cpufreq driver has a chance to ramp up clockspeeds in real-world situations the clockspeeds will remain low when only short I/O accesses happen. That's what you get when you switch a central setting without any evaluation and obiously 'just for fun' :)
At least it should be obvious that disk-benchmark.sh is not able to report about disk performance but only 'disk performance tampered by some default settings' in its current form.
One might argue using 'OS defaults' would be the right thing since that's what they ship and users have to live with but me as someone who only does 'active reviews' (not just reporting numbers but improving numbers) can't disagree more since the best idea is to run the test in both modes: OS image defaults vs. performance and then pointing the OS image makers at the difference and hint at how to fix this (worked all the time, just not with the Banana Pi and Armbian guys).
[1] for Cluster in /sys/devices/system/cpu/cpufreq/policy* ; do [[ -e "${Cluster}" ]] || break; echo performance >"${Cluster}/scaling_governor"; done
geerlingguy
axiopaladin
teodoryantcheff
pfriedel
lolren
celly
Radxa sells an updated version of their Penta SATA HAT for $45, and it includes four SATA drive connectors, plus one edge connector for a 5th drive, 12V power inputs (molex or barrel jack) to power both the drives and the Pi 5 via GPIO, a cable for the 5th drive, an FFC cable to connect the HAT to the Pi 5, and screws for the mounting.
It looks like the SATA controller is a JMB585 PCIe Gen 3x2 SATA controller, so it could benefit from running the Pi 5's PCIe lane at Gen 3.0 speeds (setting
dtparam=pciex1_gen=3in/boot/firmware/config.txt). Radxa sent me a unit for testing.