0

TLDR; USB-3 SSD on Raspberry Pi 4 has read speeds of 322KiB/s and write of 108KiB/s, expecting MB/s at least...

I've gone through every forum on this one, using this test:
sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
I get these results:

test: (groupid=0, jobs=1): err= 0: pid=29327: Mon Oct 17 01:54:05 2022
  read: IOPS=80, BW=322KiB/s (330kB/s)(3070MiB/9752067msec)
   bw (  KiB/s): min=   32, max=  640, per=100.00%, avg=322.30, stdev=56.10, samples=19503
   iops        : min=    8, max=  160, avg=80.53, stdev=14.03, samples=19503
  write: IOPS=26, BW=108KiB/s (110kB/s)(1026MiB/9752067msec); 0 zone resets
   bw (  KiB/s): min=    7, max=  240, per=100.00%, avg=107.68, stdev=30.44, samples=19502
   iops        : min=    1, max=   60, avg=26.87, stdev= 7.61, samples=19502
  cpu          : usr=0.19%, sys=1.23%, ctx=1066066, majf=0, minf=18
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=322KiB/s (330kB/s), 322KiB/s-322KiB/s (330kB/s-330kB/s), io=3070MiB (3219MB), run=9752067-9752067msec
  WRITE: bw=108KiB/s (110kB/s), 108KiB/s-108KiB/s (110kB/s-110kB/s), io=1026MiB (1076MB), run=9752067-9752067msec

Disk stats (read/write):
  sdc: ios=785603/312743, merge=310/2356, ticks=16335446/3116502, in_queue=17370112, util=100.00%

System setup is 64-bit Ubuntu (kernel 5.4.0-1071-raspi) on raspberry pi 4 hardware, have confirmed I'm "using xhci_hcd" driver from dmesg, no errors as well.

Tried adding "usb-storage.quirks" for the device in cmdline.txt as well with no change..

SSD is

[436294.004115] usb 2-2: Product: Elements 2621
[436294.004126] usb 2-2: Manufacturer: Western Digital

Anyone else seeing this with their Pi 4 setup that can help??

3
  • 1
    Random writes are slow on any computer even with the fastest drives and CPUs. Just looking at your command line you look to be using a particularly aggressive random test which will look even worse. The WD Elements drives are HDD drives, not SSDs so them being slow and awful is expected from that front as well.
    – Mokubai
    Commented Oct 17, 2022 at 19:24
  • What do you expect when using massive parallel disk Io test (64 threads in parallel) and a extreme tiny block size of 4k?
    – Robert
    Commented Oct 17, 2022 at 21:49
  • 1
    @Mokubai thank you, the HD is in a third-party rebranded package and was marketed as "SSD"... a spinning drive explains things completely (and teaches me to buy name-brand next time)
    – ifiht
    Commented Oct 18, 2022 at 1:40

1 Answer 1

1

You are doing randrw, which is of course much slower than sequential rw operations, especially on a spinning HDD and even more over USB.

From the fio documentation:

 readwrite=str, rw=str

    Type of I/O pattern. Accepted values are:

        read
            Sequential reads.
        write
            Sequential writes.
        trim
            Sequential trims (Linux block devices and SCSI character devices only).
        randread
            Random reads.
        randwrite
            Random writes.
        randtrim
            Random trims (Linux block devices and SCSI character devices only).
        rw,readwrite
            Sequential mixed reads and writes.
        randrw
            Random mixed reads and writes.
        trimwrite
            Sequential trim+write sequences. Blocks will be trimmed first, then the same blocks will be written to. So if io_size=64K is specified, Fio will trim a total of 64K bytes and also write 64K bytes on the same trimmed blocks. This behaviour will be consistent with number_ios or other Fio options limiting the total bytes or number of I/O’s.
        randtrimwrite
            Like trimwrite, but uses random offsets rather than sequential writes.

1
  • And this can even be worse if the drive is a SMR one (which is more and more common among desktop drives).
    – PierU
    Commented Oct 17, 2022 at 20:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .