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

And is there a way to determine the class of a card that isn't marked?

I have 4 cards used to run RISC OS on RPI. Three were bought as Sandisk class 10, one was bought as a carrier for RISC OS from ROOL. Copying files to these rpis shows a considerable variation of speed - the "class 10" card machines are 2 to 3 times faster when copying about 30 files each of a few KBytes. It would be nice to see what each actually is.

--
Alan Adams, from Northamptonshire 
alan@adamshome.org.uk 
http://www.nckc.org.uk/

Op 25 Oct 2014 21:11:48 +0100 (BST) schreef Theo Markettos:

The first computer I bought in 1981 was the Cosmac Elf II and had a 1802 processor. With 32 K ram I ran Figforth on it with cassette interface, as I had no diskdrive. My video was 64 x 16, nice for blocks without line numbers. It was rather slow, most instructions needed 16 clockticks, with 1.79 Mhz it performed 0,112 Mips. I now run Brad Rodriguez' CamelForth it in an emulator (link at CamelForth page) under Linux, maybe a hundred times faster.

--
Coos 

CHForth, 16 bit DOS applications 
http://home.hccnet.nl/j.j.haak/forth.html

Op Sun, 26 Oct 2014 00:22:13 +0200 schreef Coos Haak:

Sorry, wrong news group

--
Coos

Hmm. I'd have thought that 100K was already down close to being a single-block operation, but I can try smaller. I think I've got a Lexar chip somewhere so I should be able to test it this evening.

How does it come out using 4K random read and writes rather than 100K ?

---druck

So this if what I get with 4k files, fully synced writes and reads. It does seem that the Samsung "evo" Class 10 does well with small file writes.

Lexar 16G "Premium" class 10: Write 100MB at 9.8795 MB/s Read 100MB at 17.3429 MB/s Write 1000x4KB at 23.5016 files/s Read 1000x4KB at 82.2523 files/s

Samsung 16G "evo" class 10: Write 100MB at 10.9808 MB/s Read 100MB at 17.0124 MB/s Write 1000x4KB at 35.8376 files/s Read 1000x4KB at 81.3463 files/s

Integral 32G class 10: Write 100MB at 8.02849 MB/s Read 100MB at 17.5296 MB/s Write 1000x4KB at 20.4309 files/s Read 1000x4KB at 81.697 files/s

Samsung 4G class 6: Write 100MB at 6.38561 MB/s Read 100MB at 16.164 MB/s Write 1000x4KB at 27.8269 files/s Read 1000x4KB at 81.3462 files/s

No-name 8G class 4: Write 100MB at 4.87222 MB/s Read 100MB at 17.3839 MB/s Write 1000x4KB at 28.508 files/s Read 1000x4KB at 81.8914 files/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 \" 100/($end-$start) \" MB/s\"}" start=$(date '+%s.%N') fil=$(cat wrtf/large) end=$(date '+%s.%N') awk "BEGIN {print \"Read 100MB at \" 100/($end-$start) \" MB/s\"}" start=$(date '+%s.%N') for j in {0001..1000}; do dd conv=fsync bs=4K count=1 if=/dev/zero of="wrtf/f$j" &> /dev/null done end=$(date '+%s.%N') awk "BEGIN {print \"Write 1000x4KB at \" 1000/($end-$start) \" files/s\"}" start=$(date '+%s.%N') for j in {0001..1000}; do fil=$(cat "wrtf/f$j") done end=$(date '+%s.%N') awk "BEGIN {print \"Read 1000x4KB at \" 1000/($end-$start) \" files/s\"}" rm -r wrtf

Oh, and I'll add that Dom's assertion that Class 4 cards do well with small files is evidently correct too. Sorry for my skepticism. Although the class 4 card was beaten by the Samsung class 10, it was faster than the other two class 10 cards for 4K writes.

Thanks for that. It's good to have it confirmed with real-world facts :)

There is definitely something different about the way the "Evo" Class 10 cards work, as there were recently some issues when using 32GB Samsung EVO cards that caused data corruption while running. Those issues have been fixed by a change to the bootcode/"firmware".

It was something along the lines of the write response times being almost too fast for the bus to handle.

100KB is about right for a *flash* block (128KB is plausible) but *filesystem* blocks are 4KB or thereabouts. The point being that you have to read-modify-write a 128KB flash block in order to write a 4KB FS block. That means you waste a lot of time writing flash. Better cards have more buffer RAM, so they can cache some of these writes and then coalesce them into fewer, larger, writes, or stream them out when they have a moment. Or the architecture has smaller flash blocks so this is less of an issue.

It's particularly an issue on SD/microSD cards as they're physically constrained - USB devices often have more physical space to play with so can include more buffer RAM if they desire (but often they're cheap and nasty so they don't).

Theo

If you're in Linux, poke about in /sys or /proc looking for mmc (I can't remember the exact location, something like /sys/bus/mmc )

If you're on a RISC OS, try *SDIODevices

Theo

You said in a previous thread that you couldn't distinguish much via USB adaptors, since they just appeared as mass storage. Do you know if the Pi's SD interface allows you to probe some SD card details? udevadm doesn't provide anything understandable to my eye:

$ udevadm info --query=all --name=/dev/mmcblk0 P: /devices/platform/mmc_host/mmc0/mmc0:0001/block/mmcblk0 N: mmcblk0 S: disk/by-id/memstick-00000_0x65c90e88 E: DEVLINKS=/dev/disk/by-id/memstick-00000_0x65c90e88 E: DEVNAME=/dev/mmcblk0 E: DEVPATH=/devices/platform/mmc_host/mmc0/mmc0:0001/block/mmcblk0 E: DEVTYPE=disk E: ID_BUS=memstick E: ID_DRIVE_FLASH_SD=1 E: ID_DRIVE_MEDIA_FLASH_SD=1 E: ID_PART_TABLE_TYPE=dos E: ID_SERIAL=00000_0x65c90e88 E: MAJOR=179 E: MINOR=0 E: SUBSYSTEM=block E: UDEV_LOG=3 E: UDISKS_PARTITION_TABLE=1 E: UDISKS_PARTITION_TABLE_COUNT=2 E: UDISKS_PARTITION_TABLE_SCHEME=mbr E: UDISKS_PRESENTATION_NOPOLICY=0 E: USEC_INITIALIZED=6516401

Aha. Found that mmc location. That does look more interesting:

# cd /sys/bus/mmc/devices/mmc0:0001 # find * -maxdepth 0 -type f -exec sh -c 'echo -n {}=; cat {};' \; cid=1b534d30303030301065c90e8800e600 csd=400e00325b590000751f7f800a404000 date=06/2014 erase_size=512 fwrev=0x0 hwrev=0x1 manfid=0x00001b name=00000 oemid=0x534d preferred_erase_size=4194304 scr=02b5800200000000 serial=0x65c90e88 type=SD uevent=DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=00000 MODALIAS=mmc:block

file "SDIOdevices" not found on RO5.20 on Iyonix.

Is this only present in the rPi version?

--
Alan Adams, from Northamptonshire 
alan@adamshome.org.uk 
http://www.nckc.org.uk/

On Tue, 28 Oct 2014 11:52:43 GMT, Alan Adams declaimed the following:

Note the spelling... SDIODevices vs SDIOdevices

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

However this is RISC OS so commands are not case sensitive.

I've now tried it on rPi, where the command does exist. Unfortunately it doesn't tell me anything I find useful.

With the Fast 8GB card inserted I get

*sdiodevices Bus Slt RCA Fun Description Capacity Vendor Product Rev Date 0 0 AAAA 0 SDHC card 7 Gbytes SanDisk SU08G 8.0 2012-12

With the slower 2GB card I get

*sdiodevices Bus Slt RCA Fun Description Capacity Vendor Product Rev Date 0 0 B368 0 SD card 1898 Mbytes Unknown SMI 1.0 2012-09

I can't see anything there which tells me the class of the card. Am I missing it.

(Incidentally another nice RO feature - I simply swapped the cards with RO running and repeated the command. RO doesn't need the disc (SD card) present once it has booted. It just got the information from the card currently present without a hiccup.)

--
Alan Adams, from Northamptonshire 
alan@adamshome.org.uk 
http://www.nckc.org.uk/

[snip]

AFAIK the 'class' is a marketing thing - it's what they stamp on the outside. I haven't seen anywhere you can read it from the card. What those do give you is the vendor/product information, which you can use from Google to find the marketing information. The point is that sometimes what's printed on the outside doesn't match up with what the card actually is - the vendor/product is a closer way of finding that out. However that doesn't always work because fake cards can also fake up the vendor/product information - though often they don't bother. Other telltales for fake cards are looking at the serial numbers - low value serial numbers are somewhat fishy. I don't know if RISC OS tells you those, but /sys/bus/mmc on Linux does.

Theo

Thanks for all the input. I have decided, rightly or wrongly, to restrict my choice to Samsung cards which are available from Amazon.

[I am also shopping for larger cards for a couple of Samsung phones.]

Even with this filter the pricing is quite confusing e.g. a microSD card plus an adapter is cheaper than the apparently equivalent (same branding, same colour, same speed spec.) full size SD card.

Also some with the adapter are cheaper than the same card without the adapter!

It also isn't clear why the same manufacturer has cards with the same speed specification at such wildly differing prices.

Anyway, I'll get UHS-1 Class 10 for the phones, plus one for the Pi and a Class 6 for speed comparison.

Rough price list: [Samsung Evo MicroSDHC UHS-I Grade 1 Class 10.]

So the 'bangs per buck' are slightly better with increased size, but price is almost linear.

Now trying to decide if I need anything larger for the phones. I've had a Galaxy S3 for 2 years and not filled the 8GB card so probably not.

Also trying to work out why the Evo range is cheaper. I know that my B+ won't be able to use the 'go faster' features of UHS-I but still (assuming there is no downside to running in normal mode) it looks promising.

Cheers

Dave R

--
Windows 8.1 on PCSpecialist box

Make sure they are ones fulfilled by Amazon, and not just some company trading in the Amazon market place.

It's a good choice, the performance is great, and I've not had one fail on me yet, although I've been using them on phones a lot longer than in the Pi.

The EVO brand ties in with their SSD range (got one in the laptop), and like them it uses the cheaper TLC (tri-level) flash they pioneered.

---druck

Thanks - ordered 3 of the EVO 16GB UHS-I Class 10 and two of the standard Class 6 16GB.

When/if I get time I'll test them for speed.

I did make sure they were all from Amazon itself, and on SuperSaver delivery.

Cheers

Dave R

--
Windows 8.1 on PCSpecialist box