An omnipresent characteristic of current single-board computers (SBCs) is the use of SD cards to provide mass storage functionality, either for system boot or data storage purposes. Unfortunately, SD cards are not particularly reliable devices, and their intended purpose is storing pictures as they are captured by a digital camera – perhaps the most sequential storage access task that could possibly be imagined. Booting an operating system (OS) exhibits a much more randomized access pattern, as I have previously discussed in the case of marginally better USB storage "sticks" [1], presenting the device with challenges to the processing of allocations and deletions at sustained rates.

That article examined the performance difference between USB storage with high-end brand names and more generic devices and compared the resulting write performance. Today, I am examining the limits of SD performance in a specific SBC instead: the all-in-one Raspberry Pi 400. (Figure 1). The Raspberry Pi 400 [2] is a custom board redesign (for cooling reasons) of the Raspberry Pi 4 in the once popular "computer in a keyboard" form factor of days past. Board layout aside, it can be thought of as a Raspberry Pi 4 SBC with 4GB of RAM, WiFi access, and some additional layout changes to expose the GPIO connector at the back of the keyboard.

Figure 1: The modern take on the in-keyboard computer: the Raspberry Pi 400.

Definitions and Standards

The inscriptions on SD cards include details on storage capacity, format, bus interface, and more [3]. For our purpose here, I am particularly interested in the speed class. The most basic speed class is a number in an uppercase letter C, most commonly 10, indicating that the card is rated for a minimum read and write speed of 10MBps. Older devices may have numbers as low as 2 in this class notation, denoting a guaranteed performance of 2MBps (Figure 2).

Figure 2: SD cards of various sources test your label-reading skills [5].

A newer speed specification is the ultrahigh speed (UHS) class. The speed class is now enclosed in a U symbol, with UHS 1 (U1) corresponding to the older class C10 performance of 10MBps. A higher U3 classification is now commonly available, promising the user a minimum performance of 30MBps. The newest notation format is a video class specification, denoted by the letter V. In this case, V10 once again delivers 10MBps, with the higher V60 or V90 (90MBps) intended for high-rate or high-definition video capture.

Bus specification could be a bottleneck for very high I/O speeds, but it is not generally a limiting factor for SBC computers. Ultrahigh speed I (UHS I), denoted by an "I" marking, delivers a bus speed ranging between 50 and 104MBps.

These metrics focus on sequential operations. A distinct random access performance metric is defined by the Application Class (letter A), commonly found in the A1 notation. An Application Class 1 SD card will deliver at least 1,500 input/output operations per second (IOPS) of random read performance and 500 IOPS in random writes. Although not as impressive, a card guaranteeing A1-level performance will not encounter problems during OS boot because of system logging, as some cheaper cards have been known to. A higher specification of A2 exists, but it requires additional hardware to operate.

Testing the Theory

Our old friend gnome-disks [4] makes a return, its convenient visualization of results still unrivaled. Running a benchmark on the SDHC medium supplied by the Raspberry Pi Foundation with the computer (a SanDisk C10, U1, A1 microSDHC I with 16GB of capacity) shows the card handily exceeding its specified minimum limits (Figure 3). Testing demonstrated approximately 45MBps of throughput with a read latency of half a millisecond. This test did not include a write component because I could not unmount the boot device as required by the built-in benchmark, but an equivalent test can be carried out at the command line if using some care.

Figure 3: The gnome-disks read benchmark on a SanDisk A1 U1 card.

Entering dd [6] to a valid path on the filesystem, you avoid testing the performance of a virtual filesystem like /tmp and purge all caches, as discussed in the previous article, to avoid interference in the measurements (Figure 4). The resulting 21.2MBps matches the hard limit of the Raspberry Pi SD card reader, which is rated at a maximum of 25MBps and reportedly cannot exceed 22MBps in actual use. The Embedded Linux wiki maintains an extensive library of SD card performance results from a variety of vendors [7], as measured on Raspberry Pi devices, and it is a useful resource to keep in mind.

Figure 4: Testing the boot volume write performance from the terminal.