SoylentNews is people
SoylentNews
from the stocking-stuffer-reference-items dept.
In my experience, one of the highest-impact upgrades you can perform to increase Raspberry Pi performance is to buy the fastest possible microSD card—especially for applications where you need to do a lot of random reads and writes.
There is an order-of-magnitude difference between most cheap cards and the slightly-more-expensive ones (even if both are rated as being in the same class)—especially in small-block random I/O performance. As an example, if you use a normal, cheap microSD card for your database server, normal database operations can literally be 100x slower than if you used a standard microSD card.
Because of this, I went and purchased over a dozen different cards and have been putting them through their paces. Here are the results of those efforts...
Visit TFA for the full table. The overall winner seems to be OWC Envoy SSD (USB), with hdparm buffered: 34.13 MB/s; dd write: 34.4 MB/s; 4K rand read: 7.06 MB/s; 4K rand write: 8.20 MB/s
takyon: The value winner in the article is the Samsung Evo+ 32 GB (purchased for $9.99 from Best Buy) with decent/passable speeds.
(Score: 2) by Snotnose on Saturday December 05 2015, @12:30AM
Some 10-15 years ago I had to write an SDCC driver. Details are fuzzy, but for version 1.0 you had flowcharts on how to read/write/erase/etc. Violating the flowchart resulted in a timeout instead of an error more often than not. Then cards larger than what 1.0 could support came out and the flowcharts had to be updated. How, you ask? Early in the process you sent the SDCC card a command that 1.0 didn't recognize but 2.0 did. Then waited to see if it timed out, if it did you had a 1.0 chip. Whoops, some vendors of 1.0 chips added a status bit that, when set, indicated WTF; but they returned that error fairly quickly. Then cards larger than what 2.0 supported came out. Again, add a command that neither 1.0 nor 2.0 recognized, but 3.0 did. Wait for a timeout and act accordingly. This is in addition to lots of fuzzy timing requirements, and some states had exits that weren't accounted for in the flowchart.
Now consider each timeout is several milliseconds long, and it wasn't uncommon to get 3-4 timeouts when starting up, things got real slow real fast. Didn't help that my first driver was for 1.0, then modified for 2.0, then modified for 3.0, etc. Would have been better to rewrite it to assume 3.0 and, if that failed, revert to the slower earlier versions.
I've written maybe 50 device drivers over the last 30 years, the SDCC driver was one of the more challenging ones. I gained a lot of respect for what Microsoft had to put up with, all my other drivers had the chip I was talking to soldered to the board.
When the dust settled America realized it was saved by a porn star.