Re: System on a chip - performance relative size and setup (how can the (Debian) setup make a difference?)
Hi Erik,
On Fri, Jun 21, 2019 at 03:02:46PM +0200, Erik Josefsson wrote:
> Maybe flashbench cannot tell me anything about that anyway?
>
> Are there other tools?
I'm not familiar with flashbench. I like fio. It's available in
Debian.
I like to do the following tests. Example fio command line follows
for each.
- sequential read speed (MB/sec)
$ fio --name="seqread" \
--filename="/mnt/fioscratch" \
--ioengine=libaio \
--readwrite=read \
--direct=1 \
--numjobs=2 \
--bs=4k \
--iodepth=4 \
--size=1g \
--runtime=300s \
--gtod_reduce=1 \
--group_reporting | tee -a /home/$USER/fio.txt
- sequential write speed (MB/sec)
$ fio --name="seqwrite" \
--filename="/mnt/fioscratch" \
--ioengine=libaio \
--readwrite=write \
--direct=1 \
--numjobs=2 \
--bs=4k \
--iodepth=4 \
--size=1g \
--runtime=300s \
--gtod_reduce=1 \
--group_reporting | tee -a /home/$USER/fio.txt
- random 4KiB reads (IOPS)
$ fio --name="randread" \
--filename="/mnt/fioscratch" \
--ioengine=libaio \
--readwrite=randread \
--direct=1 \
--numjobs=2 \
--bs=4k \
--iodepth=4 \
--size=1g \
--runtime=300s \
--gtod_reduce=1 \
--group_reporting | tee -a /home/$USER/fio.txt
- random 4KiB writes (IOPS)
$ fio --name="randread" \
--filename="/mnt/fioscratch" \
--ioengine=libaio \
--readwrite=randwrite \
--direct=1 \
--numjobs=2 \
--bs=4k \
--iodepth=4 \
--size=1g \
--runtime=300s \
--gtod_reduce=1 \
--group_reporting | tee -a /home/$USER/fio.txt
Explanation:
name: Identifies the block of test output in the results output
file.
filename: This file will be written out and then read from or
written to. So your test device needs to be mounted on
/mnt first. As long as your user has write access there,
fio does not need to be run as root.
readwrite: Sets the mis of reads and writes and whether they are
sequential or random.
direct: Use direct IO, bypassing Linux's page cache. If you don't
use this, you'll only be testing Linux's cache which would
distort results since you're only testing 1GiB of data which
could well fit entirely within your RAM. Note that many
storage devices have their own cache, but this probably
isn't relevant for your case.
numjobs: Spawn two processes each of which will be doing the same
thing at once.
bs: Use 4KiB sized IOs. If you can benchark your real application
you may find it uses different-sized IOs, but if you don't know
then 4KiB is a reasonable start.
iodepth: Each process will issue 4 IOs at once, rather than issuing
one and then waiting for it to complete.
size/runtime: The tests will read or write 1GiB of data but there is
also a time limit of 5 minutes and if that runs out
first then the test will stop. I don't think you need
to do many hours of testing here. After 5 minutes I
should think the card will be showing its reasonable
performance.
gtod_reduce: Don't do some tests that require the gettimeofday
system call. Without this, fio can spend a lot of its
CPU time calling that system call instead of
benchmarking, and you rarely require the info it gives
back anyway. Run without this option once to see if you
really require it.
group_reporting: Aggregate results from all jobs (processes) within
the test.
| tee -a …: Output the results both to the screen and append to a
file in your home directory.
Of those figures, I consider the random ones more important in most
configurations. i.e. if I had to choose between a device that
supported a bit higher sequential read/write but much lower random
read/write, I'd rather have the random read/write, because that
tends to have more impact on interactive usage than sequential.
SD cards tend to have poor random IO speed so I would never use one
for general purpose computing if I could use an HDD or SSD instead.
To give you some idea of what decent SSDs manage:
http://strugglers.net/~andy/blog/2019/05/29/linux-raid-10-may-not-always-be-the-best-performer-but-i-dont-know-why/
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Reply to: