When people plan to use a development board for their project, they mainly focus on the requirements of the development board itself, as well as software support. But selecting the right accessories may be just as crucial for good performance and stability. For example, selecting a proper power supply is important, as the board may freeze or randmly rebooted if it is not feed at the right voltage. Part of this is selecting a micro USB cable, as you’ll want a cable with minimal resistance which can be achieved through shorter cables and/or a low AWG value. Another important item that can impact stability and performance of the systems are micro SD cards when used to run the operating system in development boards.
Understanding SD Card Performance Metrics & Classes
Until a few years ago, (Micro) SD cards were primary used to store data such as photos, videos and music. In those use cases, you have large files that benefit from high sequential read and write speeds. That’s why the SD association created different classes to specify a minimum write speed with speed class, UHS speed class, and more recently Video Speed Class.
That’s useful as you won’t need the same write speeds to copy music files, or record videos in a 4K camera, and the cards with a lower class are normally cheaper. Note that most (all?) low cost development board do not support UHS-II or UHS-III interface, so it may work, but you won’t be able to reach the maximum performance of the card. Micro SD card controllers are also often connected via SDIO which limits the sequential performance to around 23 MB/s.
However, those classes are only marginally useful for micro SD cards used in development boards, since operating systems generate a lot of small read and write operations, for example for databases and web caches, rather than handling large files. That’s why storage devices may also include read and write IOPS (I/O per seconds) which are more useful for this type of use case. The table below about Samsung eMMC and UFS flash chip shows some of those numbers.
The only problem is that until very recently, there was no way you could know minimal IOPS R/W numbers for SD cards since they were simply not made available by the manufacturers, so instead people were recommending Class 10 micro SD cards which may or may not best suited to their use in development boards. However, since the introduction of Adoptable Storage in Android, where micro SD cards could be used for apps instead of just data, IOPS values became more important, and the SD association has now introduced Class A1 & Class A2 application performance classes for SD cards specifying minimum IOPS R/W values together with a 10MB/sec minimum sustained sequential write speed.
That’s great! Problem solved then? Not quite, as manufacturers have only started to use application performance class logos in their higher-end SD cards with high capacity like 256GB, which usually cost several times the price of your typical development board. So we need to rely on the community to test IOPS R/W values, or random read and write speeds.
Software Tools for SD Cards
There are several program that can test performance. hdparm and dd are popular, but the former only test sequential speed for a very short time, and the latter only test sequential speed, and many people may not include the time it takes to flash the cache to the actual card (e.g. with sync), leading to potentially misleading results, and mostly irrelevant to our use case.
So instead, there are specific tools to tests both sequential speeds and random I/O performance. Bonnie++ is one, but recently iozone has become the reference for disk I/O testing, and that’s the one used in the benchmarks below.
Many tutorials recommend to flash firmware using Win32DiskImager in Windows, or dd in Linux. However, while I have not experience the issue myself, I’ve been told the latter may not always detect errors while flashing, and a new tool is now recommended: Etcher. It works in Windows, Linux, or Mac OS using a GUI or the command line, and will verify the SD card after flashing making sure nothing has gone wrong during the process.
SD Cards Benchmarks
With that in mind we need micro SD cards with good random R/W performance, which we can test with iozone3, and for many applications 8 to 32 GB capacities are enough. We were planning to test ourselves, but Andreas Spiess has already published a videos – embedded further below- leveraging pidramble work, with benchmarks using several micro SD cards on a Raspberry Pi 3 board. You’ll also find more results and discussion on Armbian forums. Linaro also made a survey of micro SD cards a while ago.
Here are the main takeaways from the tests:
- Larger cards are usually faster but not always (See Samsung EVO+ 64GB results).
- Benchmarks vary a lot between runs for a given card with 10 to 20% variations
- Most low cost micro SD cards / clones have really bad random write performance.
- Samsung and Sandisk cards get the best random I/O performance
- It’s not always necessary to buy the most expensive cards for usable performance.
The conclusion is that for the best performance select cards like Samsung EVO+ 32GB or Samsung Pro+ 32GB selling for respectively around $18 and about $25 on Amazon US. A cheaper card that should work decently is Sandisk Extreme Pro 8GB sold for $8.
The Problem of Fake Micro SD Cards
It looks like we have now found a decent list of micro SD cards to use with our development boards. There are still problem has some are copy, even on sites like Amazon , as manufacturer of fake card may insert them in the supply chain. One way to double check if you have an original is to check the CID (Card Identification) number. In Linux, you can do so as follows:
|
1 2 |
cat /sys/block/mmcblk0/device/cid 035344534c3038478049731d9201063d |
The first two digit represents the manufacturer ID. There’s no public list, but “1b” is for Samsung. You can decode the full CID on here.
If you’ve bought a Samsung SD card, and the Manufacturer ID is different from 0x1b, then you almost certainly have a fake Samsung SD card. If the number is 0x1b, you can’t be 100% sure you have a genuine SD card however, as the clones may have also cloned that part.
Sadly there’s no easy other way to check if a card is real or fake. Checking the performance is similar to other reports online may help confirm you have a proper card. That 2010 article by Bunnie has more details about fake SD cards.
Longevity and Reliability of microSD Cards
I’ve been using micro SD cards for about 5 years both in development boards, and my phone, and I have to say I’ve had to throw away many of them due to I/O errors after a while. I’ve also found my card readers also only last a few months. So far, I mostly bought cheaper ones, so it could be an explanation. Sadly, manufacturers do not provide any MTBF (Mean Time Between Failure) for SD cards so there’s no data like on hard drives and SSDs.
However, there are ways to limit wear and tear on micro SD cards by limited writes, either by making the rootfs read-only which is fine for embedded projects, less if you plan on using your board as a computer, or using log2ram, extending the write buffer commit interval, etc… More discussion about SD card lifespan can be found on Pete Scargill’s blog.
Some people will also encounter corrupted flash that won’t boot anymore after a power failure or a crash because the file system has been corrupted. It is not directly related to the SD card itself, and it’s more likely to occur if you have a poor power supply. Steps to reduce the probably of corruption involves the same steps as previously mentioned to limit wear and tear with a read-only file system and so on.
Another solution to avoid most the issues mentioned above is to use boards with eMMC flash, but of course going that route would mean that you’d have to avoid Raspberry Pi boards, baring the RPi Compute Module. Neverhteless, a combination of carefully selected power supply, USB cable, and micro SD card should still give you a good experience, and avoid many potential headaches, with your board.
Thanks to Karl and Thomas for tips and insights.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Meh, Samsung 960 Pro M.2 HATs with gddr5 cache sounds like the way to go with rpi.
I’d love to post my results of flashbench analysis somewhere. If you’d like that, let me know and I’ll share my Google Doc with the results. Flash varies a lot by manufacturer but all seem to respect the 4MiB erase block size that is specified for SD cards (even on USB drives).
Damn… wrote a big post that got dropped.
Basically, you have two types of USB drives: some cache all writes, some cache after you write to some fixed area an X amount of data.
First type will give you great benchmarks but very bad desktop performance (Sandisk), while the second is better if you want to tune BTRFS.
For simple desktop setups you can do:
– Buy a 16GB+ Sandisk flash drive, the bigger the better. The Ultra Fit 3.0 is one of the best, speed wise.
– mkfs.ext3 -m 10 -E stride=16,stripe_width=16
– /tmp as tmpfs
– /var/log as tmpfs
– Configure downloads to /tmp
– export XDG_CACHE_HOME=/tmp/$USER_xdg-cache. This means your browser will be quite fast.
– Configure package management to store downloads on tmpfs. OpenSUSE works much better than Ubuntu, as it also deletes the files after successful install.
Be sure Linux mounts / with “relatime” or “noatime”. Updates will still be slow but browsing is quite decent as all your writes to SQLite go to the SLC cache.
Better setups run BTRFS on drives that don’t cache writes by default (harder to find), so you can effectively use “ssd_spread” and get hit by GC much less than EXT2/3/4. Data deduplication is great here and file system compression is also good, provided they fix some bugs that exist.
@goblin
X-D
You won’t see sustained speeds there, but you WILL get the IOPS of at least an A1 rated SD card that way. Endurance will be through the roof as well.
For a Pi3, any of the higher-end USB thumbs or externals will do well for you and you can even boot from them now.
On which tests are the graphs in the large picture based? And where are these ‘Load Jessie Images’ times from (and what’s the meaning: ’00:06:22′ means what?)?
Regarding ‘boot performance’ I experienced quite the opposite. I tested with 3 different SD cards varying from really performant to ‘just crap’ to compare between ext4 and F2FS: https://forum.armbian.com/index.php?/topic/4167-f2fs-revisited/&do=findComment&comment=30835
To my surprise all results were identical (but it was all the time exactly the same Armbian image starting the first time and created from scratch — most probably things change after an OS image has been used for some time and filesystem layout and internal fragmentation start to affect numbers). Maybe partition alignment and block sizes might also affect performance a lot so if such a test as above comparing boot times of 6 different SD cards is not done in exactly the same way all the time I believe we’re talking about ‘standard benchmarking’ here (collecting numbers without meaning)?
I am not sure if this will help but in photography, using a PC running windows connect a sdcard to your PC, then select the sdcard drive properties, then tools and run error checking on the sdcard. This can often make a sdcard useable again or less error prone.
@theguyuk
Are you kidding? You can’t make SD cards ‘less error prone’ by clicking somewhere around (such voodoo only affects your expectations which is something working quite well with a lot of people). What you’re recommending is letting Windows do a chkdsk filesystem repair run on a SD card which will of course never work with the cards we’re talking here about since Windows has not the slightest idea about ext4, btrfs, F2FS or any other of the filesystems that might be used with development boards or Android devices.
But by using Windows (or macOS) you might be able to restore performance of crappy SD cards using SD Association’s ‘SD card Formattter’ since this tool allows to issue ‘ERASE CMD38’ which tells the card’s FTL (controller) that card is entirely empty (same effect as TRIM with SSDs). Using fstrim the same should be possible in Linux though.
Some more information: https://forum.armbian.com/index.php?/topic/3776-the-partition-is-not-resized-to-full-sd-card-size/&do=findComment&comment=27413
Has anyone tested RPI 3 from different batches to ensure all RPI 3 perform the same? Might be worth doing with one fixed sdcard, otherwise the results might mean nothing if different Pi boards give different sdcard read, write results.
Also which OS version is used.
Can the computer you use to create the OS card effect results as different computers can use different chips or OS versions.
I remembered something else people might try, I know of it but have not tried it.
Partitioning your SD card will allow you to protect and isolate certain sensitive files, create backups of programs and operating systems, and can even help enhance the performance of your computer or device. SD cards can be partitioned successfully on Windows and Mac computers, as well as on Android devices.
I doubt that partitions have any effect on the flash controllers wear leveling algorithm. I’m guessing partitions are virtual not physical.
That was new to me! Thank you! In other words: a dev board running Linux or a realtime OS can’t successfully partition an SD card, right? Can it use or access partitions? Maybe we should start to educate ourselves about this new partition thing that is able to increase performance, protect data and create backups! Sounds promising!
I settled with samsung Sd-cards. They give the best performance and never failed for me, sandisks already gave me a lot of problems and a lot of fsck’s.
To test if the sd-card is fake I use f3 -> http://oss.digirati.com.br/f3/
What transfer rates does the RPi3 support? If the top end speeds approach the bus transfer limit, then you’ll see compression of the results. If the tests could be run on a board that supports UHS, the results might look a bit different.
Does anyone know of a board other than the ODROID-C2 that supports UHS?
@tkaiser
The chart are based on Andreas results, which can be found in the description of his video. Those are the results of iozone using a script running hdparm, dd, and iozone: https://raw.githubusercontent.com/geerlingguy/raspberry-pi-dramble/master/setup/benchmarks/microsd-benchmarks.sh
Andreas procedure is as follows:
1. Run CrystalDiskMark in Windows 10 usign a card reader
2. Flash Debian Jessie to RPi 3 with Etcher
3. Boot Debian in the Raspberry Pi 3 (that’s where he measured the boot time)
4. Run the script with hdparm, dd, and iozone.
“00:06:22” means 6 minutes and 22 seconds… The discrepancies are really weird, that’s why I mentioned a boot chart could be useful. Based on his procedure, I understand this is the first boot, so it could be different for other boots, especially if the rootfs partition is automatically resized.
@willmore
RPi 3 will be limited, but you can check the results from CrystalDiskMark in Andreas’ spreadsheet @ https://docs.google.com/spreadsheets/d/12VD1l3yhHVl-CWYekX0NPqrQqzzF7qfCo6W9DWBbeUU/edit?usp=sharing&pageId=109491518201880821270&authuser=1
@roel
Unfortunately these days there are counterfeit cards around that do not fake capacity any more but feature the same size as advertised, report correct metadata (CID — Card Identification), allow to flash an image but start to fail with some SBC as soon as random IO patterns are written (for example the first ‘apt-get upgrade’ running). We had reports about recently bought Samsung cards in Armbian forum and my personal conclusion in the meantime is: Don’t trust in any tests any more but buy from sellers that return/refund without asking questions. Test immediately performance and capacity but also real world scenarios and if problems occur or performance looks questionable send the cards back.
I will never understand why people invest so much time to produce something useful and then hide everything in a youtube video (but maybe there’s a target audience). As I understood his procedure these are flashing times with Etcher (without verification for whatever reasons) made with a Windows PC and an USB3 card reader allowing for high sequential write speeds. It’s not about booting at all and these numbers then are correct and roughly the same I got with my MacBook Pro (supports writing with ~80 MB/s) and simply are sequential write speed tests without SBC limitations in place.
If there’s no SDIO interface limit (the typical 20-23 MB/s that can be seen on most SBC) then the 16 GB EVO cards are only half as fast as the 32/64 EVO/EVO+ but the Pro+ outperforms them easily maxing out at 80 MB/s. These times are totally irrelevant for booting but just an indication that people who flash OS images for a living might save some time by choosing more expensive cards since on a PC or Mac with sufficient card reader there is a difference (but not when running in almost all SBC any more).
@willmore
Tinkerboard for example allows for higher transfer modes even with SD cards (on most SBC this only applies to their onboard eMMC). But as usual settings matter, by choosing inappropriate cpufreq scaling settings (interactive with very low minimum clockspeed or ondemand without additional tweaks for example) you can totally destroy your storage performance: https://tinkerboarding.co.uk/forum/thread-310.html
That’s another important factor almost no one understand or even knows of. With such a test you’re always testing settings on these slow devices too and that’s why ‘numbers on the Internet’ look so weird.
In my experience, some UHS-II cards can outperform (or perform as good as) cheap eMMC when it comes to sequential BW. IOPS can be an entirely different matter, of course, though one of the new SD classification standards tires to establish some guarantees there as well.
@tkaiser
So are you saying you use a storage medium without error checking for failure?
Sdcards work with many formats including formats used by Windows, as far as I am aware chkdsk is a tool for windows file formats but you seem to suggest sdcards do not fully support windows file format as they cannot support chkdsk creating a table of bad, failing storage areas on sdcards solid state none moving drives.
Ever used a more recent Banana Pi? The cheap EOLed eMMC there maxes out at 6.5MB/s sequential writes while a cheap Samsung EVO allows for 3.5 times faster writes. Sequential reads and random IO differ of course but the former isn’t relevant for most use cases at all and if you manage to get a genuine Samsung EVO/EVO+ with 32 or 64 GB or any SanDisk Extreme Pro or Plus (not the cheaper ones) you’re fine wrt random IO too. At least when comparing with cheap onboard eMMC.
What the hell? You really should write less and read more (and at least try to understand: what the physical layer is, what the flash translation layer above is, what partitions and filesystems are and why chkdsk is pretty useless for scenarios we’re talking here about: Using SD cards not in cameras/recorders where FAT32 or VFAT are used but development boards or Android devices where different filesystems have to be used and only some partitions are accessible from Windows if at all).
If you have an SD card with ext4 or F2FS on it… how should clicking around in Windows help? Chkdsk can’t deal with that and reformatting with any of the filesystems it understands renders the card useless for our devices (though many people don’t understand that the recommendation to ‘format’ SD cards to FAT32 prior to flashing a linux image is absolutely useless if it’s not about those Raspberry Pi with their proprietary bootloader)
I suspect he in fact refers to the suggestion not to use an entire flash device in general, to leave more empty blocks never used that can be used by the flash controller to reduce fragmentation and maintain a better write performance over time (in fact limit the write performance degradation).
But obviously, simply “partitionning” will serve no purpose. The flash must first be erased, then partitionned to limit the used area. Most often, just having a large swap partition will work well enough because swap is rarely filled up and these unused blocks also serve during recycling.
That’s a nice article which will at least sensibilize users to certain traps. When I first tested my opi-pc2 board, I got very frequent freezes, SSH connections were very slow to respond (TCP OK, nothing happens for 30 seconds). I thought about an issue with entropy generation or something like this. It was just the SD card which was unable to sustain a decent write performance, probably while dumping logs at the end of boot, or even because the rootfs was not mounted with noatime/relatime.
I’d suggest to have a few trusted SD cards and only use these ones to test new dev boards, it will limit the surprizes. When buying a new one it should be first tested on a known board to confirm it works as expected.
The chapter about reliability is way to short, it is lacking Informations about the storage structure and there is a lot of information about the MTBF, just check the used storage manufacturer and type.
SLC cards are far more reliable then most MLC or TLC cards which are out there. Also clever firmware and hardware inside cards (small “USVs” for saving last blocks on power failure) are differencing cards. With increased environment temperature you will also kill a lot of cards.
@Willy
Well, when I’m told that partitions can be created ‘on Windows and Mac computers, as well as on Android’ then it’s time for some irony.
To help with internal fragmentation, wear leveling and performance we changed last year Armbian’s partition behaviour. Armbian ships with a minimized rootfs (actual size + 30% more so first ‘unattended upgrades’ run will survive) that will be expanded on first boot (within the booted Linux of course). In the beginning we always used the card’s full capacity but I changed that last year when starting to explore SD card behaviour. On cards with just 4GB or less we leave 5 percent unpartitioned, with 8 GB it’s 2% and above 1% (that’s also important since users want to clone their cards but two 16GB cards from different vendors always differ in size by a few sectors, leaving some unpartitioned spare area helps with that). So in fact some Linux distros already use partitioning to fight some of the SD card annoyances.
I could now elaborate on why partitions are an anachronistic relict from last century, how ‘things’ like ZFS and btrfs combine filesystem and lower layers (at least volume manager) so that partitions look like something stupid, that I’m quite happy to run something similar on my smartphone in the meantime (iOS 10.3 upgrade did an in-place conversion from HFS+ to APFS) but that’s just off-topic here.
Instead I simply second your suggestion to keep few trusted SD cards for ‘new device bring up’ and want to add to always burn OS images with a verify process included (just use Etcher with default settings, it does all the magic for you). Saves so much time and hassles.
And from time to time or after intensive use it’s a good idea to use ‘SD Card Formatter’ and do a full erase since this tells the SD card’s controller the card is entirely empty (normal ‘format’ won’t do) which helps restoring write performance on crappy SD cards.
@tkaiser
Yes, videos are great for watch one time, but if you want to refer to it later that’s a pain. I must have watched it three or four times to write the benchmark section, sometimes jumping to the location.
I’ve removed the “load Jessie time” section of my post, as it’s not 100% clear whether it’s boot time or flash with Etcher time. He does mention about newer cards have better “large file performance” right after that, so I guess that was indeed for Etcher’s flash time.
@tkaiser
Haha, what a “champion” that Banana Pi is! No, I don’t think I’ve ever used an eMMC below 30MB/s : ) But I can vouch for the SanDisk Extreme Plus (UHS-I) – on the XU4 that gave me 68MB/s measured sequential and very nice IOPS (subjective, from daily usage), which, while much less than the factory eMMC solution, is perfectly adequate for pretty much anything I’d want to do on such a small SBC.
Well, as shown above when doing the F2FS tests: if it’s always exactly the same image boot times should not be affected at all. And those ‘load’ times somewhat correlate with his CrystalDiskMark sequential write performance numbers. Current Raspbian image is that fat that it does not fit on normal 4GB cards any more (maybe for a good reason since there’s not a single 4GB card out there showing sufficient performance) and a PC or Mac will then write with just 11 MB/s to a 16GB EVO (not EVO+) resulting in 06:22 flashing time while a Samsung Pro+ can be written to with more than 55 MB/s which results in just 01:12 flashing time (depending on the mode Etcher uses it will be somewhat slower than a ‘write only’ benchmark when doing block based write/verify cycles)
But I agree, removing the “load Jessie time” block is a good idea since relevant only for those people flashing SD cards all day long (like me 😉 I’ve two SanDisk Extreme Pro, one SanDisk Extreme Plus and a Samsung Pro dedicated to this since all reach my card reader’s 80MB/s sequential bottleneck)
@tkaiser
Actually I understand sdcards, harddrives and memory better than you assume. Anyone that has a open mind will frankly laugh at all the testing hoops you jump through.
Why do I say that, well the video and photography users have tested and poked the subject to death. Yes I know IOP.
Any way sometimes when seeing a fly banging it’s head on the window its better to walk away and leave it.
@cnxsoft
Small Etcher addendum: At least on macOS when burning already compressed OS images the decompression task seems to run single threaded so with current Raspbian as ZIP burning on my laptop I get only 18MB/s vs. 80 MB/s uncompressed (first time bottlenecked by CPU and second time by card reader, the card in question could do a bit more). But still totally irrelevant wrt later use on dev boards with their limited implementation.
Exactly. And this whole blog post is all about what’s different when using SD cards on Android devices or dev boards compared to cameras and recorders (hint: it’s not just about those ‘IOP’ where you missed the most important ‘S’ — maybe you should take the time to read the articles you’re commenting?)
@tkaiser
Is there a sd card formatter alternative for linux. Or is there a linux version I don’t know of? Or should I do it with wine.
I have some trouble with a samsung 64gb pro when I want to boot from it it gives a filesystem corruption error. If I do a fsck it stays the same. When i put in a sd-card reader connected to my linux PC it mounts OK without issues. I burned the image already with dd and etcher with the same result. I didn’t try a windows solutions like rufus, cause I don’t have a windows PC…
Checking the card with f3 says it’s 100% OK and not fake.
@roel
Some boards only support cards up to 32GB. Can your board handle 64GB cards?
@roel
‘SD Card Formatter’ can partition SD cards, can put filesystems on it (that’s why Raspberry Pi users with larger SD cards need this tool since SDXC cards come pre-formatted with ExFAT but the primitive RPi bootloader can deal only with old FAT variants like FAT32) and can issue a ‘full erase’ (‘ERASE CMD38’) so that cards suffering from write performance degradation will get back their original performance. That’s all.
This tool doesn’t transform counterfeit cards into genuine ones. It seems in 2017 the fraudsters improved too and most recent fake cards look like genuine ones (in the past there were many Samsung fakes with black borders), report correct metadata and not BS and also show the real capacity unlike most counterfeit cards from the years before that all had a much lower capacity.
Compare please with https://forum.armbian.com/index.php?/topic/4348-problems-with-apt-get-upgrade-on-cubietruck/
The CrystalDiskMark performance numbers just look wrong (same with those from Andreas Spiess above for his 64 GB EVO+).
@cnxsoft
Yes, it worked before, but suddenly it doesn’t anymore. So I thought maybe sd card formatter could set it back to “virgin”. I bought the card with Pollin, so I assume they sell real ones.
@tkaiser
I checked the link, probably it’s a fake also, as I checked the read/write performance a few days ago and it was terrible. It surely wasn’t the minimum claimed UHS3 speeds of 30Mb/s. I thought the reason of these speeds where my usb sd-card reader. Wasted money. Those card manufacturers should put a unique code on these cards so you can register them (or something like that).
No retailer can prevent selling counterfeit cards since they get inserted into the supply chain pretty early. Just check the blog post above for ‘That 2010 article by Bunnie’ (somewhat historical but anyway you might get the idea).
If you’ve an USB3 card reader that is known to show decent performance the usual iozone run would be worth a try. And do a google search for ‘samsung 2017 evo fake’ — fun 😉
@blu
Well, those Bananas were just one example for really low-end eMMC on dev boards. FriendlyELEC for example used also rather slow eMMC on a few of their NanoPi (sequential writes limited to below 8 MB/s) but they said months ago they’ll look into the issue and maybe they use now faster.
On the bright side: I didn’t realize that this eMMC is that slow only after flashing a btrfs based OS image with a fixed size to the 8GB of a BPi M2+ and since this took +20 minutes I looked up the datasheet and ran a benchmark locally later.
But with normal use cases and appropriate settings (log2ram and high write commit interval) you won’t take notice that it’s that slow. Using Android or a Desktop Linux it might look differently and then a decent SanDisk Extreme Pro/Plus or a genuine Samsung might be the better alternative to ultra slow onboard flash storage (raw NAND implementations of older SoCs perform even worse)
This project https://hackaday.io/project/19783-sd-card-emulation looks more convenient than an SD card if you are testing a lot of builds
Another option is SD card mux: https://wiki.tizen.org/SD_MUX
I made something similar last year (more simplified, one chip only). It worked great but for unknown reason I killed 3 Sandisk Extreme Pro cards in the process. At least they were replaced in warranty.