Internal storage options


_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,390
Age
43
Location
Brussels, Belgium
About internal storage: This is another interesting task.


Basically, there are three possibilities:

  • eMMC (non-replaceable)
  • Micro-SD Card (user-replaceable)
  • Micro-SSD via SATA (non-replaceable)
Each possibility has advantages and disadvantages, and we need to find out which would be best.
If we use a Micro-SSD via SATA, we should be able to include an internal Micro-SD Card slot as well.


Using Micro-SD Card is a neat solution, as the user can replace it with a bigger card if he wants.


eMMC is the standard in most devices (and there probably is a reason for it).


How do all these compare in terms of speed, power consumption, reliability and availability (also in the future)?


That's something we need to find out.


Next week is the Embedded World in Nuremburg, and we'll be there and visit various manufacturers and distributors and try to find out the one that suits the Pyra best.
Assuming the SoC is OMAP5432, there are the following bus limits on the transfer speeds (approximately):

  • SD: 100MB/s (SDR104)
  • eMMC: 200MB/s
  • SATA: 300MB/s (SATA 2.0)
So whatever the card/chip itself can do, the speed will be capped to the bus limit anyway. Keep that in mind. In fact it may even be limited more than you would expect, e.g. a 480MB/s SATA3 SSD will work with OMAP5's SATA2 interface, but only at ~240MB/s (half speed), not at 300MB/s (see e.g. http://kb.sandisk.com/app/answers/detail/a_id/8142/~/difference-between-sata-i,-sata-ii-and-sata-iii).

For all three types of storage, the top-range cards/chips can reach those speeds for sequential reading. They tend to be slower at writing and of course at random access read/writes. In terms of capacities, all of them can be up to 128GB. The highest capacity usually has a slower speed though.

Good SD cards tend to be relatively fast at writing (write speeds close to read speeds) since they are aimed at high-res video cameras that need good write speeds.

eMMCs tend to be a bit slower at writing, but faster at reading and good at random access -- at least if you get a good one, cheap ones suck at writing.

SATA SSDs are usually good at everything, but they consume more power.

SD and eMMC are roughly the same price, SSD is more expensive. SD is obviously easily replaceable, eMMC and SSD are soldered to the PCB although the Hardkernel ODROID uses some kind of modular eMMC.

Here are some interesting data points, please add more if you find them:

- MicroSD:

SanDisk  Extreme Pro:

$35 for 16GB, $23 for 8GB (on a quick Amazon search)

claims: "Up to 95 MB/s (633X) read speed; write speed up to 90 MB/s (600X)"

benchmark: 90.9MB/s sequential read, 74.7MB/s sequential write, 87.6MB/s random read, 13.4MB/s random write

(source: http://www.storagereview.com/sandisk_extreme_pro_microsdhc_review)

Toshiba EXCERIA type HD:

$31.80 for 32GB, $17.85 for 16GB, $11.35 for 8GB

claims: 95MB/s read speed, 30MB/s write speed

Of course there are plenty of cheap and slower cards too. E.g. for $9.45 (shipping not included) you can get a 32GB class 10 microSD card. If you don't care much about boot speed, that may well be good enough.

- eMMC:

ODROID eMMC module:

$79 for 64GB, $39 for 16GB, $25 for 8GB

claims: "Read speed is up to 160MB/sec in the real world."

benchmark: 128MB/s sequential read, 30MB/s sequential write, 12.7MB/s random read, 4.5MB/s random write

(source: https://www.linux.com/learn/tutorials/752860-benchmarking-the-odroid-xu-a-fast-clocked-quad-a15-arm-machine)

SanDisk iNAND Extreme:

claims: 300MB/s sequential read [capped: 200MB/s?], 70MB/s sequential write, 24MB/s random read, 12MB/s random write

benchmark: ?

Kingston eMMC prices as given by ED:


$100 for 64GB, $41 for 32GB, $19 for 16GB, $18 for 8GB, $8 for 4GB

specs and benchmark results unknown

[The Google Nexus 7 has a Kingston eMMC (an older one by now I guess), according to http://www.anandtech.com/show/6073/the-google-nexus-7-review/6 this are its benchmark results: 23.1MB/s sequential read, 8.43MB/s sequential write, 4.77MB/s random read, 0.32MB/s random write]

- tiny SSD:

SanDisk iSSD i110:

claims: 450MB/s sequential read, 350MB/s sequential write [capped: 230MB/s, 180MB/s?]

max power: 2.7W

benchmark: ?

Innodisk nanoSSD 3SE:

$140.4 for 8GB (4ch), $254.6 for 16GB (4ch)

(source: http://www.jampel.it/Modules/ListFiles/Files/2013-03-12-02-55-59_IT.pdf)

claims: 480MB/s sequential read, 175MB/s sequential write [capped: 240MB/s, 175MB/s?]

max power: 0.99W

benchmark: ?

Innodisk nanoSSD 3ME:

$33.8 for 8GB (1ch), $47.8 for 16GB (2ch), $69.8 for 32GB (4ch), $133.8 for 64GB (4ch)

claims: 480MB/s sequential read, 90MB/s sequential write [capped: 240MB/s, 90MB/s?]

max power: 0.99W

benchmark: ?

My conclusions so far (but I'm willing to adjust them if I see more data points):

- SSD is overkill and too expensive for us (unless we can find a cheaper, slower one; anything above 300MB/s cannot be used anyway; it's not easy to find a cheap one that is also small and low-power enough)

- microSD can be better than eMMC both in speed and in price, even taking the bus limit advantage of eMMC into account

- it makes most sense to use microSD only for internal storage.
 
I've seen no proof outside what is on paper that uSD is faster than eMMC solutions. currently at least on the omap5 dev board doing real operations it shows it's half the speed of eMMC on the benchmarks I shared. I can try different uSD cards when I get a chance. I need to reinstall my rootfs after my attempt to upgrade to Debian Jessie ended in tears.
 
Do anyone know the bus limits on Allwinner a80 and Snapdragon 800/805?
 
I've seen no proof outside what is on paper that uSD is faster than eMMC solutions. currently at least on the omap5 dev board doing real operations it shows it's half the speed of eMMC on the benchmarks I shared. I can try different uSD cards when I get a chance. I need to reinstall my rootfs after my attempt to upgrade to Debian Jessie ended in tears.
If I recall, the uSD that you benchmarked was a generic type of unknown age or lineage - and there was some doubt if the clock on the SD bus was even set properly. That doesn't really count in this conversation beyond, "Look! I can make it read/write!"
 
If I recall, the uSD that you benchmarked was a generic type of unknown age or lineage - and there was some doubt if the clock on the SD bus was even set properly. That doesn't really count in this conversation beyond, "Look! I can make it read/write!"
True enough, if someone is willing to help me figure out what my clock speed on the SDIO bus is then we can get some real benchmarks going. If the bus speed is faster than 300Mhz my scope isn't capable of measuring it, also my scope is from the early 80's so I'm not sure if it's still operating ideally. So I'm willing to buy an ideal fast uSD card or two(depending on costs) for testing. I'll make a USB thumb drive boot up so the OS isn't running on an SD or eMMC for the test.

I rather see some real tests instead of just speculation and on paper theories of what can be done.

Edit: May also see about doing some actual current measurements.
 
Last edited by a moderator:
If I recall, the uSD that you benchmarked was a generic type of unknown age or lineage - and there was some doubt if the clock on the SD bus was even set properly. That doesn't really count in this conversation beyond, "Look! I can make it read/write!"
True enough, if someone is willing to help me figure out what my clock speed on the SDIO bus is then we can get some real benchmarks going. If the bus speed is faster than 300Mhz my scope isn't capable of measuring it, also my scope is from the early 80's so I'm not sure if it's still operating ideally. So I'm willing to buy an ideal fast uSD card or two(depending on costs) for testing. I'll make a USB thumb drive boot up so the OS isn't running on an SD or eMMC for the test.

I rather see some real tests instead of just speculation and on paper theories of what can be done.

Edit: May also see about doing some actual current measurements.
The two uSD cards that keep popping up are Toshiba's Exceria uSD and a SanDisk card of similar claims. I can never keep SanDisk's naming conventions straight.

There are quite a few cards showing up in that speed range now.

http://www.tomshardware.com/charts/microsd-cards-2014/-1-Sequential-Read-MB-s,3480.html

The harder ones to test are likely the eMMC variations since you can't just pop one on the dev board and try it.
 
The problem with 2x SD and 1x uSD is you run out of SDIO bus, which means the combo wifi/bt has to be usb.
That's false. The OMAP5 has 4 SDIO. That allows for 1 to be used for Wifi, 2 for SD, and 1 for microSD. The comments about running out of SDIO in other threads were in relation to trying to fit both eMMC and microSD on the board together.

-God Ginrai
 
The two uSD cards that keep popping up are Toshiba's Exceria uSD and a SanDisk card of similar claims. I can never keep SanDisk's naming conventions straight.
I just ordered these: "Toshiba MicroSDHC Micro SD Card TF UHS-I 16GB Class10 Max 95M/s" and "SanDisk Extreme Pro 8 GB microSDHC Class 10 UHS-I 95MB/s" Both were between $20-$25 dollars.. although the SanDisk I had to get an 8GB instead of 16GB too keep my cost down. I figure after the testing the 16GB one can end up replacing the SD card in my phone and I'll use the 8GB on the dev board instead of the mystery card.
 
Last edited by a moderator:
The two uSD cards that keep popping up are Toshiba's Exceria uSD and a SanDisk card of similar claims. I can never keep SanDisk's naming conventions straight.
I just ordered these: "Toshiba MicroSDHC Micro SD Card TF UHS-I 16GB Class10 Max 95M/s" and "SanDisk Extreme Pro 8 GB microSDHC Class 10 UHS-I 95MB/s" Both were between $20-$25 dollars.. although the SanDisk I had to get an 8GB instead of 16GB too keep my cost down. I figure after the testing the 16GB one can end up replacing the SD card in my phone and I'll use the 8GB on the dev board instead of the mystery card.
Cool - I'm glad you're able to defray/reuse the costs on those.

I'm looking forward to the results!
 
I believe this..in fact I think the most rational thing is to dispense with internal storage completely..it would be strange to have microSD and SD in the same device, why not go for 100% SD?
 
I believe this..in fact I think the most rational thing is to dispense with internal storage completely..it would be strange to have microSD and SD in the same device, why not go for 100% SD?
Why is it strange to have microSD and SD in the same device? I don't think that is any stranger than having, say, USB and micro-USB ports in the same device.
 
I feel like if benchmarks are quoted the same one really has to be used to be fair. Although they're supposed to be measuring the same thing they're really not all equal. It also needs to be ensured that they're running on the same operating system under the same file system and if possible, under similar pre-existing loads.

I don't think there's an actual precedent for SD cards having better write speed than eMMC, historically they've had much slower write than read just as well. It's a fundamental aspect of the technology that you need to do more work for writes. There just now happens to be a specialty card with very fast writes. uSD probably does support more potential for enthusiast models that perform higher than average, but it comes with a substantial price premium.

I also don't like the claim "microSD can be better than eMMC both in speed and in price", when even the numbers given here support that it can be better in speed OR better in price - pick one but not both. That Exceria doesn't suggest better performance.

Personally I consider sequential read speed to be the most important performance metric, since it determines how quickly things load, and no, you won't have all the stuff you want to load always sitting in RAM. If we're talking about uncompressing 512MB ROMs then read speed is a huge deal, a much bigger one than the time it took to write that ROM - the write speed still matters but not nearly as much. Similarly, read IOPS are a lot more important than write IOPS.
 
 We have 2 threads already with arguments re the storage, why do we need another?.  As was mentioned previously, let ED do some tests and let him decide .

Secondly,  the figures quoted for eMMC are missleading.  it comes across that those odroid modules are the cost of the eMMC it uses - it isn't

If you look at page 2 of the emmc vs uSD poll thread, it was established that the 16GB version of of the 160MB/s (128MB/s real test) eMMC used in the oDroid is this Toshiba one :>  THGBM5G7A2JBAIM.  It sells for $22 or $16.8 for orders over 500.   ie $16.8 NOT $39 > http://avnetexpress.avnet.com/store/em/EMController/Flash-Card/Toshiba/THGBM5G7A2JBAIM/_/R-5003562200198/A-5003562200198/An-0?action=part&catalogId=500201&langId=-1&storeId=500201

 Also, of note:  the 16GB eMMC ED is looking at has a claimed top speed of 166MB/s seq read - no real test figures yet, ED needs to test it - this eMMC costs $19 probably lower for bulk orders.

_wb_ , I don't see a random read test for that  eMMC in this link https://www.linux.com/learn/tutorials/752860-benchmarking-the-odroid-xu-a-fast-clocked-quad-a15-arm-machine)

Unless your quoting that 12780 number in the table for which there are no units to designate what the figures are ? .   It should be noted that figure, whatever it is , is for 4KB random reads. If it is 12.7MB/s 4KB random read  . Then compare it below to the random read the Sandisk uSD gets for 4KB ie 2.7MB/s.  

The stat I have on the Sandisk 4KB Random Read test is as follows - note it's important in these tests to know the data sizes being accessed, that way you can compare against stats for other products on an equal playing field.

Sandisk Extreme Pro (633x)

Random read test for 4KB ->  2.7MB/s  http://www.tomshardware.com/charts/microsd-cards-2014/-5-Random-Read-4-KB-QD-1-MB-s,3484.html

If we were to compare uSD to eMMC on those stats , it would be

For around the same price (using the cheaper toshiba uSD price) ~ $17 for both eMMC and uSD

Toshiba 16GB eMMC -  Claimed max of 160MB/s Seq read, tested at 128MB/s seq read , tested at 12.7MB/s - 4KB random Read

Toshiba 16GB uSD  - Claimed max of 95MB/s seq read, tested at 96.2MB/s seq read, tested at 3.1MB/s - 4KB random read

Note:  the seq read speeds for uSD are for  a 1000MB data chunk, they smooth out storage access latency.  On the other hand the eMMC seq read is for 4KB chunks, which doesn't hide access latency.  It's incorrect to compare the seq read figures in the way they have been above for this reason.

But of course this all means nothing, as we can't confirm the figures above, or indeed that the tests are on a level playing field.  That's why its important for ED to do his tests and decide , not just on speed but all the other factors he mentioned.

@Trashy_MG,  Unless you are going to buy an eMMC module for your dev board similiar to the one ED is looking at or at least the odroid toshiba one.  The only thing you can do is compare your figures on those uSD against the odroid toshiba eMMC  published figure. But even then , you would need to do exactly the same tests (as near as possible anyway - including platform and data read sizes) as they did for the comparison to make sense.  
 
Last edited by a moderator:
 If we're talking about uncompressing 512MB ROMs then read speed is a huge deal, a much bigger one than the time it took to write that ROM - the write speed still matters but not nearly as much.
Are people really going to keep roms on internal storage though? I mean, I can see you doing it as you code the stuff and granted, people could "DL" the roms from the Pyra, but I wonder how many people would do that? It is just so much eaiser for most people to copy the roms they already have to their SD card and be done with it. For most people to use the internal storage for roms, that will mean copying it to an SD card, and then copying it to the internal one again.

Of course, I could be wrong, I do know that if I were to give one of these to anyone I know, they would just use the SD cards, but that doesn't mean everybody would, but it seems likely from my experience. Every use case is different though, if I am wrong let me know.
 
@Trashy_MG,  Unless you are going to buy an eMMC module for your dev board similiar to the one ED is looking at or at least the odroid toshiba one.  The only thing you can do is compare your figures on those uSD against the odroid toshiba eMMC  published figure. But even then , you would need to do exactly the same tests (as near as possible anyway - including platform and data read sizes) as they did for the comparison to make sense.  
Well obviously I'm not going to depopulate the eMMC module that's already on the device I would most definitely ruin the board trying to do so.. If the fastest uSDs on the market can't keep up with the SanDisk eMMC onboard the omap5 dev board I think it will still say something. Also hat exactly does the odroid toshiba eMMC have to do with anything?
 
^ I think you took what I said the wrong way, I was only saying that perhaps we should try and compare the results of the fastest uSD cards you bought against the fastest eMMC we know (at the $17 price point - the toshiba one). And importantly to try and use the same measures if possible as other published tests.   I wasn't having a go at what your doing what so ever.

I agree your slow old eMMC may show some things against the latest  uSD you bought.   4KB seq and random reads would be interesting
 
Last edited by a moderator:
Are people really going to keep roms on internal storage though? I mean, I can see you doing it as you code the stuff and granted, people could "DL" the roms from the Pyra, but I wonder how many people would do that? It is just so much eaiser for most people to copy the roms they already have to their SD card and be done with it. For most people to use the internal storage for roms, that will mean copying it to an SD card, and then copying it to the internal one again.

Of course, I could be wrong, I do know that if I were to give one of these to anyone I know, they would just use the SD cards, but that doesn't mean everybody would, but it seems likely from my experience. Every use case is different though, if I am wrong let me know.
Given a 16GB storage space where often less than half of that would be used by OS/distro packages? Sure, I expect people to put their most accessed stuff there if they have space, I don't think they'd just keep it empty. Maybe it'd take a few cases of the load time being noticeably annoying before they copy something over but I could definitely see it happening.

People will more often than not start out with SD cards they have lying around, if they're a couple years old they're probably going to be much slower than these really high performance cards out now, so the difference could be very pronounced. We could be talking about waiting over half a minute. It's definitely annoying on Pandora.
 
Last edited by a moderator:
Back
Top