How big a (micro) SD card do you use?

My new B+ turned up with an 8GB NOOBS card. I want to get another couple of cards to play around with (including trying out NOOBS multi-boot) but can't decide how much space I should allow.

The Pi may be used as an answering/call intercept machine, or as a media player, but probably not as a file server. Media files are likely to be stored elsewhere or streamed from t'Internet. Also, I have external HDDs with USB connectors.

So what size of SD cards do people buy? Is 8GB enough, 16GB enough etc? I have seen posts from people who say they bought 128GB as that was the most reasonable priced item!

Also, speed?

TIA

Dave R

--
Windows 8.1 on PCSpecialist box
Reply to
David
Loading thread data ...

Looking at it from a different perspective you can use a minimal SD card of 2GB with just the boot and kernel files, and run your applications from the HDD.

All it takes is a small edit to cmdline.txt on the SD card.

--

Graham. 

%Profound_observation%
Reply to
Graham.

I use all different sizes of card. One Pi has 16GB, one 8GB, one 4GB, one has 2 GB plus an 80GB USB HD, and I sometimes use an 8MB card for testing my Bare Metal work. All are Class 4 apart from the last.

Class 4 cards are supposed to be more suited to Pi usage than Class 10, as C10 are optimized for continual writing of large sequential files, while Linux generally accesses multiple small random files consurrently.

Reply to
Dom

I didn't know that, but luckily, the pair of Sandisk 8GB cards I bought last week are Class 4.

--

Graham. 

%Profound_observation%
Reply to
Graham.

On Thu, 23 Oct 2014 14:32:03 +0100, Dom declaimed the following:

Even worse -- C10 are optimized to write those streaming files (optimized for video cameras) to a cleanly formatted card. While one would hope a C10 doesn't behave worse that a C6 on fragmented/multifile operations, there is no promise in the class definition (the card could, internally, work with GB "pages", meaning small files could require the card to read most of a GB to access a MB file in the middle).

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

Has anyone done actual measurements, rather than hearsay?

I've done tests on camera-use SD cards and find that SanDisk Extreme 45 MB/s are the fastest writers (using h2testw), and that SD readers based on USB 3 hubs (or USB 3 built into the PC) give the highest read and write speeds (compared to older devices based on USB 2.0).

But I've not tested on my Raspberry Pi cards. The longest job I have there (compiling NTP) appears to be CPU bound rather than I/O bound. I'm hoping that the RPi uses DMA I/O rather than programmed I/O, but again that's something I've not checked....

My cards are either 4 GB or 8 GB.

--
Cheers, 
David 
Web: http://www.satsignal.eu
Reply to
David Taylor

Ok but that is what is not so interesting, as explained above.

It does not matter how it performs when writing a long file, it matters how it performs in a Linux system that reads and writes to small files all over the place.

Reply to
Rob

The best benchmark I've found is to put it in a Windows box and run CrystalDiskMark. Then look at the 4K read/write performance.

For example, note how dire these are for writing:

formatting link

Theo

Reply to
Theo Markettos

So far, very usefully, it is suggested that Class 4 are better than CLass

10 for the Pi.

What about the intermediate classes?

I see some Class 6 cards. Interestingly there seems to be no Class 8.

Cheers

Dave R

--
Windows 8.1 on PCSpecialist box
Reply to
David

On 24/10/2014 12:00, Theo Markettos wrote: []

Thanks for the pointer, Theo! I tried that benchmark on a couple of cards here - a cheapo PNY and a SanDisk Extreme 45 MB/s, both class 10. As the PNY had been used, I retested it a second time after reformatting.

PNY 8GB class 10 Sequential Read : 28.799 MB/s Sequential Write : 8.043 MB/s Random Read 512KB : 27.608 MB/s Random Write 512KB : 6.162 MB/s Random Read 4KB (QD=1) : 5.315 MB/s [ 1297.6 IOPS] Random Write 4KB (QD=1) : 0.673 MB/s [ 164.2 IOPS] Random Read 4KB (QD=32) : 6.579 MB/s [ 1606.1 IOPS] Random Write 4KB (QD=32) : 0.901 MB/s [ 219.9 IOPS]

Test : 100 MB [I: 0.0% (0.0/1216.5 MB)] (x5) Date : 2014/10/24 14:42:24 OS : Windows 8.1 Pro [6.3 Build 9600] (x64) PNY 8GB class 10

PNY 8GB class 10 (after clean format) Sequential Read : 28.870 MB/s Sequential Write : 17.783 MB/s Random Read 512KB : 27.685 MB/s Random Write 512KB : 6.875 MB/s Random Read 4KB (QD=1) : 4.211 MB/s [ 1028.2 IOPS] Random Write 4KB (QD=1) : 0.632 MB/s [ 154.4 IOPS] Random Read 4KB (QD=32) : 5.506 MB/s [ 1344.1 IOPS] Random Write 4KB (QD=32) : 0.858 MB/s [ 209.4 IOPS]

Test : 100 MB [I: 0.0% (0.2/7679.0 MB)] (x5) Date : 2014/10/24 15:04:32 OS : Windows 8.1 Pro [6.3 Build 9600] (x64) PNY 8GB class 10 (after clean format)

SanDisk Extreme 8GB 45Mb/s class 10 Sequential Read : 47.404 MB/s Sequential Write : 40.376 MB/s Random Read 512KB : 45.953 MB/s Random Write 512KB : 35.718 MB/s Random Read 4KB (QD=1) : 9.264 MB/s [ 2261.8 IOPS] Random Write 4KB (QD=1) : 3.097 MB/s [ 756.1 IOPS] Random Read 4KB (QD=32) : 10.121 MB/s [ 2470.8 IOPS] Random Write 4KB (QD=32) : 2.555 MB/s [ 623.8 IOPS]

Test : 100 MB [I: 0.0% (0.1/7572.0 MB)] (x5) Date : 2014/10/24 14:50:33 OS : Windows 8.1 Pro [6.3 Build 9600] (x64) SanDisk Extreme 8GB 45Mb/s class 10

The "SanDisk Extreme 45 MB/s" is about twice as fast on 4K reads and about three times faster on 4K writes. Note this was on a USB 3.0 attached card reader which may, in part, account for some of the higher speeds.

--
Cheers, 
David 
Web: http://www.satsignal.eu
Reply to
David Taylor

====snip====

That would certainly account for sustained read/write speeds going north of the 30MB/s mark of USB2. ISTR speeds up to 35MB/s for 1TB HDDs - the bits of paper in my little pile on the desk with my speed test results (stopwatch timings on gigabyte sized file transfers) seem to have vanished so I can't quote any _actual figures.

--
J B Good
Reply to
Johny B Good

Let's see then...

Samsung "evo" class 10:

100MB file at 9.2637 MB/s 1024 100K files at 2.15172 MB/s

Samsung class 6:

100MB file at 6.30748 MB/s 1024 100K files at 1.65883 MB/s

No-name class 4:

100MB file at 4.88597 MB/s 1024 100K files at 1.53906 MB/s

So it would seem that the higher the class the better.

(I recall that the first public release of a Debian-based Linux for the Pi, pre-Raspbian, whatever it was called, had a timing bug that caused it to fail with class 10, but that's history now.)

Here's the test script:

#!/bin/bash # test write time of large single and several small files mkdir wrtf start=$(date '+%s%N') dd conv=fsync bs=1M count=100 if=/dev/zero of=wrtf/large &> /dev/null end=$(date '+%s%N') awk "BEGIN {print \"100MB file at \" 1e11/($end-$start) \" MB/s\"}" start=$(date '+%s%N') for j in {0001..1024}; do dd conv=fsync bs=100K count=1 if=/dev/zero of="wrtf/f$j" &> /dev/null done end=$(date '+%s%N') awk "BEGIN {print \"1024 100K files at \" 1e11/($end-$start) \" MB/s\"}" rm -r wrtf

Reply to
Dave Farrance

I'll note that the tests that I carried out on the Pi suggest that it can only drive class 10 writes at just under 10MB/s since that's what I get with a Samsung "evo" which has a high write speed if some special interface mode is available, which the Pi evidently doesn't have.

Reply to
Dave Farrance

I don't think that's true for all class 4 versus all class 10 cards. It depends on the small block read/write optimisations. Also, class 10 may just be inherently faster despite being optimised for large block i/o.

Reply to
A. Dumas

I'd never heard the suggestion that Class 4 might be superior in some way. Class 10 generally indicates newer designs so the all-round improvement that I found didn't come as a surprise to me. I've added a bit to my test to check the read speeds on the Pi as well.

Samsung "evo" class 10: Write 100MB at 12.0864 MB/s Read 100MB at 17.2509 MB/s Write 1024x100K at 2.3964 MB/s Read 1024x100K at 5.64239 MB/s

Samsung class 6: Write 100MB at 6.47419 MB/s Read 100MB at 17.7931 MB/s Write 1024x100K at 1.67887 MB/s Read 1024x100K at 5.75534 MB/s

No-name class 4: Write 100MB at 4.82874 MB/s Read 100MB at 16.4866 MB/s Write 1024x100K at 1.48781 MB/s Read 1024x100K at 5.63036 MB/s

#!/bin/bash # test read/write time of large single and several small files mkdir wrtf start=$(date '+%s%N') dd conv=fsync bs=1M count=100 if=/dev/zero of=wrtf/large &> /dev/null end=$(date '+%s%N') awk "BEGIN {print \"Write 100MB at \" 1e11/($end-$start) \" MB/s\"}" start=$(date '+%s%N') fil=$(cat wrtf/large) end=$(date '+%s%N') awk "BEGIN {print \"Read 100MB at \" 1e11/($end-$start) \" MB/s\"}" unset fil start=$(date '+%s%N') for j in {0001..1024}; do dd conv=fsync bs=100K count=1 if=/dev/zero of="wrtf/f$j" &> /dev/null done end=$(date '+%s%N') awk "BEGIN {print \"Write 1024x100K at \" 1e11/($end-$start) \" MB/s\"}" start=$(date '+%s%N') for j in {0001..1024}; do fil=$(cat "wrtf/f$j") done end=$(date '+%s%N') awk "BEGIN {print \"Read 1024x100K at \" 1e11/($end-$start) \" MB/s\"}" unset fil rm -r wrtf

Reply to
Dave Farrance

One might say that for RPi use, the premium paid for fast cards is probably not worth it.

Did you try & subtract the execution time (especially of the loops) to get the actual writing time? Maybe with "nocreat" flag on dd.

Reply to
A. Dumas

There's no reason to pick and choose between class 10 cards, if that's what you mean, because the enhanced extra speed requires something that the Pi doesn't have -- I've not looked into the details. But class 10 is becoming the competitively-priced standard if you buy online from the more reputable Ebay vendors or Amazon, rather than buying from supermarkets. And class 10 seems noticeably better than class 4 or 6.

No. I just made sure that the read/writes were synced so that the filesystem operations were by far the most time-consuming operations. The execution times wouldn't affect the relative difference between cards except for scaling the result a bit. And it would probably be less than the jitter between runs, which was noticeable with the class 10 large file write varying between 9 and 13 MB/s, presumably due to the Pi attending to other random tasks.

Reply to
Dave Farrance

It may be the available interrupt capacity on the pi.

I cannot get the pi above around 23 mbit/second on network I/O without saturating the cpu on I/O. For disks (or "disks") this may go significantly higher; as you use blocks of 4 or 8 k instead of the normal 1500 byte network packets.

If you use 8k; as a standard formatted ext3/4 linux partition has; you get 23 mbit / 8 * 8192 / 1500 = 15 mbit/second as the max available bandwidth.

I see no difference at all in performance between 85, 45 and

25 mbyte/second sd cards on the pi, except the former gives a little lower user cpu and a little higher irq cpu on top.

On the hardkernel cpus the difference is marked, and there is a lot more I/O speed available.

-- mrr

Reply to
Morten Reistad

I can easilly get Ethernet traffic to over 95Mbit/sec using e.g. iperf.

How are you testing? If using ssh/rsync/sftp, then the overhead is the encryption which is done in the cpu

I can read from most of my SD cards (class 6 and 10) at ~20MBytes/sec. Writing at about 16MByes/sec. I have Sandisk Ultra III class 6's and Kingston Class 4's. (And whatever the foundation ship with noobs on it - I think they're class 6's)

Gordon

Reply to
Gordon Henderson

100K isn't a 'small block' operation. When booting, for instance, there's lots of files in /etc to read and lots of shell scripts to execute. Most of those are 4K or less.

I always buy the Samsung cards since they tend to have decent small-block performance as well as reasonable large block operation (class 10 or UHS-1).

One advantage of Samsung is they make their own flash, while Lexar, Transcend and friends, that seem to have worse performance, appear to buy their flash from whoever is cheap this week.

Theo

Reply to
Theo Markettos

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.