"A2 promises even better performance with 4000/2000 read/write IOPS minimum but there's a problem since as outlined by the SD Association A2 cards show "much higher performance than A1 performance by using functions of Command Queuing and Cache".
Cache and Command Queuing require host (driver) support since the host needs to activate those new features first. The cache feature on A2 rated cards makes use of volatile RAM on the card requiring the host to learn new commands to issue flushing the cache (involving the risk of data losses -- for details see especially chapter 4.17 in Physical Layer Simplified Specification 6.0)"
What good is a performance designation (A2) if no device in the real world supports it?
I imagine Android would benefit the most (and phones also don't suffer from sudden power outages, which is the biggest risk with enabling this), so someone may try looking if mmc core in androind kernel has patches to support this.
Phone batteries die, and the battery remaining percentages are only an estimate so writing code to react to that condition can be fickle.
Perhaps you have never dropped your phone, but in my experience, on a dropped phone the battery cover and the battery often go flying.
this is often the case for new hardware specs/protocols..
see also: any SATA/SCSI rev N+1, TCQ/NCQ, UASP, PCI n+1, etc.
With A2, so far I have not seen any way any consumer (or anyone, really) could achieve 2000/4000 IOPS.
That would be like selling a SATA 2400 drive for 2x the cost of an SATA 600 drive... but not selling any kind of controller that could use more than SATA 600 bandwidth.
Spec/code is open. I'm just sort of surprised noone tried it yet.
If you need disk performance on the Pi 4, wouldn't it make more sense to only keep the kernel,initrd on the sdcard and mount the primary filesystem off a USB3 device (like an mSATA-2-USB enclosure), that is if you have the space to spare for it in your project/enclosure?
I did something similar with one of the SolidRun devices, but I had to scuttle it due to other hardware problems:
Data collection is mostly done by sending it to the cloud for storage there.
Nononono, what has the world come to?
However 'edge processing' and 'edge storage' are hot topics
Meaning "how it used to be done when hardware was a hundred times slower"?
just because the overall package is large doesn't mean the embedded designers are allocated a large portion of that.
and the upstream suppliers are always going to be pushing to be a bit smaller, so they can fit into more things, and get more sales.
Fun engineering decisions: It can use RAM from the hosting computer to store its logical block mapping tables so it doesn’t have to have DRAM onboard for that. That’s a clever way to use what the host has in abundance to avoid putting it on the price and volume constrained microSD card.
Now… how you are going to get the heat out of it when it is running at 1GB/sec. I wonder if we will see new microSD sockets with integrated heat sinks.
Though in my testing, it's still not a night-and-day performance difference, if judged by the Pi 3B+. I am not sure if the Pi 4's USB 3.0 port bandwidth will give that much of an improvement.
It would be quite nice to have any form of drive supported more directly, NVMe, m.2, whatever.
Maybe even a lower end nvme ssd + usb enclosure would be the way to go to get the best performance.
Unless there's something about the USB interface itself that kills random 4k r/w performance?
Raspberry Pi has supported direct USB boot on most boards for a while now (Pi 4 awaiting a boot firmware update), no need to also use a uSD.
Glad to hear I'm not the only one who had a nightmare experience trying to use the ClearFog Pro as a router :).
It seems that the only think that is lacking on RPi is flash memory storage. Most smartphones have a lot of it, and it seems that 1GB of storage would be enough for the RPi and would not necessarily be so expensive.
They are typically marketed toward video surveillance systems and dash cams. I'm not sure how the rest of a Raspberry Pi's performance would be effective.
Also eMMC chips are no magic. There are crappy ones and good ones. Guess which ones you're going to get for little money?
I have not had any problems when using a reliable power supply. I'm guessing the 'endurance' or 'industrial' cards some people claim are lifesavers are just doing something to guard against flaky power input when doing reads and writes, so it masks the issue.
My most recent additions are a Samsung Evo card and a Samsung Endurance. I am curious to see which dies first.
(Or actually even supported, IIRC)
Hopefully that will get fixed soon.
Enough for what? A typical Raspbian install not takes a bit more than 4GB. I don't think that the Lite version (no GUI or applications) would fit either. I'd suggest 8GB, if that's a convenient size. As flash density increases, more and more goes on a single chip and that's where production is going. Consider the price of SD cards or USB sticks. Below about 16 or 32GB they don't get much cheaper and I suspect is is for this reason.
And IAC, the RPi foundation is working hard to keep the price of the board at $35US so adding something like this probably means something else would have to be eliminated.
Most consumer cards are designed around media storage so they don't last as long.
Early iterations of the RPi boards apparently had some bad design choices in the power circuitry, which makes the problem worse.
I have three RPis in abusive conditions, and they haven't had a single SD card issue. Two RPi 3b's running as a car entertainment system, with no form of battery backup/safe shutdown. They are on the ignition power, and once the car turns off, they hard shut down. These have been in place for nearly 2 years with the same Samsung Evo 16GB cards.
The other is attached to a digital signage with less frequent hard shut downs, but still has at least one per week, and been in place since late 2017. Also running a Samsung Evo card (I think it's a 32GB since that's what I had on hand).
Both have high quality power supplies, which may help. The in-car systems have Anker car USB chargers that have been de-cased and soldered in place, while the signage one has an Anker wall charger and a standard micro-b cable.
The failed ones were all running media servers with actual media storage on external drives, but indexing done on the SD card.
I ended up aggressively moving write loads to external storage and most of my RPis are running with read-only mounted SD cards these days.
The cards that die quickest for me are either written excessively like a GoPro or Pi based data loggers written constantly. The GoPros are just burning out the cards but the data loggers corrupt the disk images during unexpected power loss.
FWIW I have several Pis running 24x7 and have not had a single SD card failure. I usually buy high end cards but I also buy cheap cards (4GB cards)and a few Micro-Center house brand, for which I don't know the quality.
I've had one that has been running years, I think. Drives a monitor, looping a video where my wife works.
The only SD card failure I have experiences was in a camera.
they are "at most" some speed. What even is the point of writting such spec?
the car analogy would be if you measure some car going down a hill (doesn't even matter if tumbling and killing everyone inside), measuring that it was 300mph and then advertising it as "speeds of 300mph!!!"
And it's not like that everywhere, the UK has started what I hope develops into a trend: https://www.bt.com/broadband/deals/
If the UK had deployed fit-for-purpose tech like Fibre-To-The-Home (FTTH), there would be much less need for the UK's advertising regulations. (Obviously speeds are never guaranteed on residential connections, but advertised fibre speeds are a much more accurate predictor of internet experience than DSL or cable.)
"But", you might say, "that BT page is advertising 'Superfast Fibre'!". Well, yes, in the UK it is legal for telcos to lie to their customers. When they say fibre, they mean Fibre-To-The-Cabinet - and VDSL the rest of the way. Would anyone call their 3G mobile service "Superfast Fibre" because the tower is fibre-fed? No. For whatever reason, though, this is totally okay in the UK.
What you'll actually get is determined by factors entirely out of their control. Whether that's an install engineer using a reel of Cat5e because that's what was in the truck even though the work order said crappy Category 3 phone cable would do, or even the neighbours are all using the most expensive package and that causes electrical interference that reduces everybody's bandwidth.
You can measure your actual characteristics, and the ISP will offer to do a half decent estimate of that, that's useful to at least decide which service to buy but the average is essentially worthless.
Small single board computers should move towards m.2 2280 nvme drive support, or at least one sata 6 gbps interface.
I always see the argument “but the Pi has the best community support!” trotted out, and I don’t disagree. However, it’s all normally just sane Linux distros on the Pi at the end of the day. Whatever instructions/advice someone has written for a given Pi project will likely be applicable on a non-Pi board anyway.
Jeff's benchmarks are accurate in my experience. If you try saving single images from a camera at even 5-10fps, the card quickly bottleneck and you start dropping frames. If you buffer and store (in my case 16-bit raw), you can essentially saturate USB bandwidth if you're also using a USB camera.
What I would really like to see is RPi configurations optimized to reduce writes. For example mount the whole SD card read-only, mount a few essential filesystems as ramfs (/var, /tmp, /run), and have, say only one partition like /srv mounted read-write (+ noatime). If you run a webserver, and serve files off /srv you can still update them whenever with no hassle, but when the webserver is otherwise just serving the files, there should be zero writes.
The trick is dealing with stateful apps (e.g. sensors) that write continuously. Power outages are painful on SD cards. Lately I've moved to a separate USB drive for writing bulk sensor data with Pi's. Then the application data partition on the SD card can be used for backup sensor readings -- probably summarized data written rarely to reduce chance of SD card corruption. Mostly when I've had SD card issues its with just the RW partition, specifically the database I'm using gets checksum errors. Never had one not boot due to a bad SD.
Though I'm contemplating trying out BTRFS mirror'ing on a single USB drive, though bcachefs looks promising once mainlined. It's cheaper to buy two 32GB USB Thumbdrives (mirrored) or even a full usb based ssd than buying an SD card with a large amount of SLC based storage. The new Pi's will be a significant upgrade in speed with external USB SSD/Thumbdrives.
Moving up in the market segnment there are in fact higher-end solutions:
- the Odroid XU4 has an eMMC port (for those who want a compact solution but don't care
about long-term durability)
- again, the XU4 supports a SATA bridge
- the Odroid has both eMMC and SATA ports
- the Odroid XU4 has an eMMC port [...] a compact *and faster* solution [...]
- the Odroid *H2* has both eMMC and SATA ports
Remember RPi 1-3 use a plain SPI interface, and even the new 4 only has UHS-1.
Except the article showed the exact same performance in both places.
It started with: Why don't these cards designed for things like RPi actually show any improvement? Oh, they don't show improvement on any device at all, they are full of crap.
So the first step is to show how the cards behave in an environment with no artificial performance limitations. This is the baseline "peak performance".
The next step is to show whether the RPi's performance ceiling is below that baseline, or if any specific card behave particularly poorly on the RPi. 2 cards may be equal on a high performing machine but for some reason have big differences when running in the RPi.