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: 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 results. Actual files were transmitted, rather than auto-generated block streams or dd images. The full stack is therefore tested together: file system , CPU, USB and networking.
Local USB 3 Read/Write Speed
A fast 128 GB memory stick was plugged into one of the Pis USB 3 ports. It was newly formatted with XFS. A large zip file (5.8 GB) was repeatedly copied to and from the drive, and the timings averaged. The purpose of this test is to determine the fastest speeds at which the drive can operate locally.
|Test No.||Description||Source||Target||Speed (Megabytes/s)||Test File|
|1||Read Test||USB Stick||/dev/null||113.1||5.8 GB|
|2||Write Test||/dev/shm||USB Stick||68.6||1.1 Gb|
Table 1. Raspberry Pi 4 Local USB 3 Read/Write tests
A 5.8 GB 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 eas done with “cp“.
Network USB 3 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 No||Description||Source||Target||Speed||Test File Size|
|3||Network Read||Pi:USB Stick||laptop:/mnt||105.0||5.8 GB|
|4||Network Write||laptop:/mnt||Pi: USB Stick||64.7||5.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.
Have a look at he network traffic during that network read test (Test 3), measured on the laptop using Gnome-system-monitor:
It can be seen that the network is transmitting at almost maximum speed 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:
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). would have expected
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/ssd disk, the iverall read speed increased 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.
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.
The test equipment was:
- A Raepberry Pi 4, 4 GB model, running Debian Buster (desktop).
- A quad core i7 laptop, model MSI cx61, with 16 GB of memory, and an internal 1 TB 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 were:
- 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 23 C.
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 No||Description||Source||Target||Speed||Test File Size|
|0||Read test 1||USB Stick||Internal SSD||118.4||5.8 GB|
|-1||Read test 2||USB Stick||/dev/null||126.5||5.8 GB|
|-2||Write test 1||Internal SSD||USB Stick||117.0||5.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.