Raspberry Pi 4 Real World Tests

The Raspberry Pi 4 was launched on 24th June and has been well received, to say the least. The spec is a big step up on previous models. It has 4 CPU cores like the Pi 2, a gigabit port like the Pi 3, plus USB 3, a better SoC, a separated bus architecture, faster memory and more of it.

Over the years, many “home” devices have been launched with Gigabit Ethernet, promising lightning fast network speeds, only to disappoint due to their lack of overall grunt. The Linkstation Live, the Sheevaplug and, to a lesser extent the Pi 3 are all on that category, unable to push their gigabit ports to more than about 14, 8 and 12 megabytes/sec respectively, due to the limitations of the CPU and the board. Is the Pi 4 the same, or can it operate as a serious NAS ?

Short answer: Yes. The Pi 4 is a *serious* NAS contender. Sustained write speeds of over 68 MB/s were obtained, and over 105 MB/s for reading, including saturation of the Gigabit network. Yes, the Pi 4 can push even a 1000 MB/s network to 100%.

Network Speed Tests

Since the Pi 4 was launched, many sites have run the usual bench marking tools, and the results are widely available. They won’t be repeated here. This article is about real world testing. That is to say, making the Pi do a realistic job and measuring the actual time taken. Real files were transmitted, rather than auto-generated block streams or “dd” images. Realistic testing exercises the full stack: file system , CPU, USB and networking.

Local USB 3 Read/Write Speed

This test measures how fast the Pi 4 can read and write to a local USB 3 connected drive (a USB stick). Local performance needs to be established in order that the later network tests are meaningful.

A fast 128 GB memory stick was plugged into one of the Pi’s USB 3 ports. It was newly formatted with XFS (a file system commonly used in NAS applications). A large zip file (5.8 GB) was repeatedly copied to and from the drive, and the timings averaged.

Test No.DescriptionSourceTargetSpeed (Megabytes/s)Test File
1Read TestUSB Stick/dev/null113.15.8 GB
2Write Test/dev/shmUSB Stick68.61.1 Gb

Table 1. Raspberry Pi 4 Local USB 3 Read/Write tests. (It might be thought that the limiting factor is the speed of the drive. Not so. See the Control Testing at the end of the article).

The zip file was read from the USB stick into /dev/null, completing in less than a minute and achieving an average read speed of 113.1 GB/s. To test USB writing speed, a smaller zip file (1.1 GB) was placed into /dev/shm, the pi’s memory-based file system. It was copied to the USB drive at an average write speed of 68.6 MB/s. In both cases the copy was done with “cp“.

Network Read/Write Speed

The USB resident XFS file system was shared out from the Pi using Samba, and mounted as a CIFS mount on a fast, gigabit-equipped laptop. A large zip file (5.8 GB) was copied from the Pi to the laptop and back again, with the following results. The copy operation was a simple “cp” on the laptop.

Test NoDescriptionSourceTargetSpeedTest File Size
3Network ReadPi:USB Sticklaptop:/mnt105.05.8 GB
4Network Writelaptop:/mntPi: USB Stick64.75.8 GB

Table 3. Raspberry Pi 4 Network Read/Write Tests. The Pi acting as a NAS.

A average write speed of 67.4 MB/s was measured, a very good result, representing about 60% of maximum gigabit speed, and barely any less than the local write speed of 68.6. In reading, the measured speed was 105 MB/s, an astonishing figure, proving that the Pi 4 is (more or less) saturating the gigabit network.

Gigabit Saturation

Have a look at he network traffic during that network read test (Test 3), measured on the laptop using Gnome-system-monitor:

Illustration 1. Raspberry Pi 4 Saturates a Gigabit Network (Test 3). Also the biggest clobbering my humble Netgear switch has ever received.

It can be seen that the network is transmitting at almost maximum speed, i.e. nearly 1 Gb/s, for much of the copy time. Between 30 and 40 seconds it appears to hit saturation point. (It was actually running at 984 out of a possible 1000 MB/s. No testing I did could improve on that. Something always hangs on to those last 16 MB/s)

Usage of the Pi 4 as a NAS

Can the Pi 4 be used as a fast NAS? Obviously yes, and then some. For example, large files could be backed up to the Pi at speeds of over 60 MB/s, which even for a commercial NAS would be a healthy throughput. Reading is even better, with speeds of over 100 MB/s, the Pi’s speedy USB hardware pushing its gigabit interface (and your gigabit switch) to the maximum.

Effect of Caching

As a point of interest. Here is another chart that shows some of the effects/benefits of the Linux cache. Before all tests above, caches were dropped with the command “echo 3 > /proc/sys/vm/drop_caches“, both on the server (the Pi) and the client (the laptop). However, if we repeat Test 3, but don’t drop the Pi’s cache first, the effect can be seen, with the network being saturated more of the time:

Illustration 2. A repeat of Test 3 without caches being dropped on the Pi.

It seems that the first 2 GB or so of the 5.8 GB file were copied at maximum network speed. Then there were a couple of wobbles, then max speed again until the 30 second mark (half way through the copy). This is a 4 GB Pi, with the file cache defaulting to about 3 GB in size. It might well be that half of the big file’s pages were therefore still in the cache from the first test run, accounting for the extended saturation in this repeated test. (Except you might expect the cache to hold the last half of the file, not the first).

Conclusion

Acting as a NAS, the Pi 4 achieves over 105 MB/s for reading and over 60 MB/s for writing. An excellent result. Read speeds could likely go even higher with better hardware, nearer the 125 MB/s theoretical Gigabit maximum. My Grixx USB stick was just barely fast enough for the test, and an external SSD would have been preferable.

Incidentally, if the 5.8 GB file is targeted at the laptop’s /dev/shm memory file system, rather than its ext4 formatted SSD disk, the overall read speed increases to 108.2 MB/s. However this is not a realistic test, because users don’t store their data in /dev/shm, so it isn’t documented above.

I am not sure what is limiting the write speed to 68 MB/s. It might be my USB stick (notwithstanding its 117 MB/s write performance in the control testing, below). Testing points to the USB 3 interface but that should be equally fast in either direction.

Other Configurations

Samba sharing over CIFS provided much better performance than other configurations. If you want to use the Pi 4 as a NAS, that is the configuration I would recommend, along with XFS formatting. The best I got from other configurations was:

SFTP performance was measured at about 39.9 MB/s for reading and 49.0 MB/s for writing.

SCP was slightly better with 41.8 (read) and 43.6 (write). Yes, write was faster.

Dragging and dropping in “caja” on the client (the file manager bundles with Linux Mint MATE) gave a read speed of 44.7 MB/s and wrote at 37.8 MB/s. This does not use CIFS.

Test Equipment

  • A Raspberry Pi 4, 4 GB model, running Debian Buster (desktop).
  • A quad core i7 laptop, model MSI CX61 20D, containing 16 GB of memory, and a 1 TB Samsung Evo 850 SSD drive, and USB 3, running Linux Mint 18 MATE.
  • A Netgear Gigabit switch, model GS605 v2, 5 port.
  • A 128 GB memory stick, model Grixx.

Test Conditions

  • Caches were dropped before all tests (except the last one). Caches were dropped after all tests too, and the drop time included in the measured test time.
  • All tests were carried out three times and the speeds recorded above are averages.
  • The USB drive was formatted as XFS. Testing was also carried out with EXT4 but achieved much lower speeds.
  • The Pi’s core temperature was monitored throughout testing with “vcgencmd measure_temp“, recording a maximum of 74 C during the copies. Idle temperature was 69 C. Room temperature was 23 C.

Control Information

Before testing on the Pi, the USB stick performance was measured locally on the laptop, to prove it could sustain speeds high enough for significant testing. Results were as follows.

Test NoDescriptionSourceTargetSpeedTest File Size
0Read test 1USB StickInternal SSD118.45.8 GB
-1Read test 2USB Stick/dev/null126.55.8 GB
-2Write test 1Internal SSDUSB Stick117.05.8 GB

Table 4. Proving the USB stick prior to Pi testing.

The USB stick was able to perform at 126.5 MB/s for reading, 117.4 MB/s for writing. This can be taken as maximum performance for the stick. It exceeds read and write speeds on the Pi (just), and can be taken as the maximum stick performance.

10 thoughts on “Raspberry Pi 4 Real World Tests

  1. First off thanks for all the testing you’ve done! I was initially disappointed with the NAS / Samba performance of the Pi 4 as I was using a NTFS formatted 4TB 5400rpm HDD which only gave 54MB/s sequential reads, 28MB/s writes. I had tried using ext4 formatting but had seem similar & in some cases worse performance.

    Now using XFS, I’m able to get 75MB/s Read, 64MB/s Write to the same drive, with the exception of cached data which reads at a consistent 113MB/s. Big improvement thanks!

    In an attempt to replicate your 100MB/s+ sustained read I tried using a NVME SSD in a usb 3.1 gen 2 enclosure (XFS formatted) and somehow ended up with 34MB/s Read / 33MB/s Write, don’t suppose you might know whats going on there?

  2. Hi John,

    Cheers. Like you, I found that NTFS performance was very poor. NTFS isn’t native to Linux though, so it probably isn’t too surprising, as the data has to go through an extra stack of driver code.

    With your XFS, 75/64 MB/s isn’t a bad speed, over the network, for a 5400 RPM. An SSD or fast thumb drive (like the one I used) might achieve faster speeds, perhaps even a 7200 RPM spinning disk.

    Not sure why your SSD topped out at 34/33 MB/s. How was the data being transferred ? To get the 105 MB/s sustained, I was running Samba on the Pi 4, and using it to share out the USB 3 connected thumb drive. This was mounted on another Linux system (gigabit laptop) as a CIFS mount. Then a big file was copied into (and out of) the mounted area with a “cp” command, issued on the laptop.

    The CIFS mount gave the fastest speeds. All other arrangements seemed to result in transfer rated of 30 to 50 MB/s. Thanks for commenting, and good luck!

    Jim

  3. Hello how about 4K content sharing to TV? Because when I stream 4K video, it buffering some times, disk it is a 1GB USB 3.0 ext4, on the router it is work ok.

    • Hi poczesaniec1. Sorry for the lateness in replying, which has been due to personal illness. TV pictures at 4K require a bandwidth of 15 to 25 Megabits/sec. The Pi4 can easily supply this (tests above gave better than 1000 Megabits/sec), so you shouldn’t see any buffering, unless, perhaps your house network is being heavily loaded with other traffic. Make sure the connection between the Pi and your TV is gigabit end-to-end. Also, I would recommend using XFS on the disk drive, rather than EXT4. Cheers, Jim.

  4. Hi. Thanks for publishing this. It’s proved useful to me as I was finding the write speed of the Pi 4 (1GB memory) somewhat less than I’d expected. I’m using an fast XQD (440MB/s in theory) in a reader over one USB 3 port and a 1TB Samsung T5 to write to over the other. My test case is copying approx 45GB of photos (roughly 25-30 MB per file) from one to the other for photo backup purposes (using rsync for this). In repeated tests I get a max sustained throughput of 64MB/s. Using a MacBook Pro with exactly the same cards & cables I comfortably get around the 160 MB/s (but using the regular ‘copy’ (drag & drop) command. From the above comments and your findings, the 63-68 MB/s mark looks fairly consistent. That makes me feel, it’s not something I’m doing but it does seem that there is some internal constraint in the Pi 4 that is the bottleneck here rather than attached devices. For the moment, I’m not too bothered as that’s about ‘good enough’ for my needs and the Pi 4 an effective tool for my needs but faster would be even nicer. Richard

    • Hi Richard. As I understand it, you are testing local transfer speeds on the Pi (no network involved). You are writing from a memory card to an SSD drive, all via USB3. The transfer involves rsyncing from one to the other and the speed is about 64 MB/s. This is fairly close to my local test above (test 2, 68.6 MB/s).

      In comparison, a Macbook Pro gives 160 MB/s with the same test, except that the copy is straightforward, and does not involve rsync.

      The Macbook is likely to be alot faster due to the much more expensive/powerful internal hardware. That is, the components and overall architecture connecting them. Also, the Mac was performing a simple copy, but the Pi was doing an rsync. For a proper comparison, they should both ideally be doing a straight copy (ie. no rsync).

      Can you run the tests again, but using a straight copy on the Pi, rather than rsync ? I guess the results will be similar, maybe a touch faster. Also, what happens if the copy is done in the other direction?

      Notwithstanding, it looks like 68 MB/s or so might be the maximum write speed on the Pi. It is hard to know exactly where the bottleneck is. The USB 3 bus doesn’t care if it is reading or writing. Your Macbook test proves the external hardware (cables etc.). Not quite sure.

      Cheers,
      Jim

  5. I don’t know how you guys tested. Running samba 4.10.8 and WD 5400rpm hdd connected via USB3 I copied an ISO file that is 6GB and saturated my Gigabit connection 112MB/s. Your samba server is likely not configured correctly. Not surprising given almost every guide out there is wrong, especially about socket_options. They are all outdated, and the current ones are based on the old ones. Here’s my config for reference:
    [global]
    workgroup = WORKGROUP
    server string = MyRPi4
    netbios name = MyRPi4
    security = user
    map to guest = Bad User
    load printers = no
    disable spoolss = yes
    log file = /var/log/samba/%m.log
    max log size = 50
    socket options = IPTOS_THROUGHPUT SO_KEEPALIVE
    deadtime = 30
    use sendfile = Yes
    write cache size = 262144
    min receivefile size = 16384
    aio read size = 16384
    aio write size = 16384

    [Public]
    path = /media/mystorage
    read only = no
    public = yes
    writable = yes
    force user = root

    • Hi Oleg. I can’t really comment on your test, as you haven’t given enough detail. You haven’t even told is if it was reading or writing.

      Anyway, I tried the Samba parameters you suggest, repeating exactly tests 3 and 4 above. The results were: read speed 48.4 MB/s, write speed 2.8 MB/s. That compares to 105 and 67.7 in the article. In other words, the new Samba parameters made reading 2 times slower and writing 24 times slower. Not good.

      There might be scope for improving the Pi 4 write speed with Samba tuning. But Samba tuning is a big subject. I would not recommend anyone try it on live systems. Not without extreme caution and exhaustive testing. It is too easy to damage the TCP stack, or to break Linux’s built in optimizations.

      Incidentally, 112 MB/s is not “saturating” a gigabit network. Saturation at about 125 MB/s can be checked with network monitor, you didn’t say if you used one.

      Jim.

      • Hi !

        Amazing achievement ! There are not many commercial NAS that can reach such speeds (in the real world) !

        Would you be so kind to share your smb configurations ?

        With kind regards,

        Huitante

        • Hi huitante. The SMB configuration (/etc/samba/smb.conf) was just the standard one distributed with Raspbian Buster. There were no special settings.

          The share was:

          [Grixx_B]
          comment = Test
          path = /mnt
          guest ok = yes
          public = yes
          writable = yes
          printable = no

          Note that “guest ok” and “public” are synonymous.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.