[poll; updated] eMMC vs. uSD; modular eMMC

[vcoleiro1]

@comradekingu

Are you  forgetting that how much of the OS loads into RAM is arbitrary as it depends on how much RAM the apps you are running use + free space.  Also, if you  ever load an OS > 2GB , that argument goes out the window. To say that the OS will load totally into RAM , and that it wont read to the OS on storage anymore , is missleading to say the best. But at least you acknowledged the load time.

 

[Natsu]

I gave a real world example where it'd matter.


It's good knowing that you can rely on accessing thousands of files at a rate beyond a few dozen files per second. There are real software implications. I'm not satisfied with the answer that the user who replaces their card with one that has crappy random access performance deserves whatever unexpected effects happen. You will be hearing about it when your program performs badly because of it and you will be blamed.

Well, that one of the things that should be explain when they first boot into the OS,


so they have no one to blame, but themselves.

How is Pyra's SIM card slot accessible anyway? From the PCB shot it looks like it's inserted from the side or something.

Even if that's the case, it's still easily accessible. Which is my point. Though it would be kind of strange to have it external when it's not something you pull out constantly.

@Natsu,


You missed the point completely , we already have 3 removeable and expandeable stoarge options that can be used for whatever reason you want.  To make the internal storage removebale also, you give up something, you give up faster read times for the OS and better latency.   What do you get in return, another removeable storage option going from 3 to 4.   No one is forcing you to use any of the external storage options by the way, its only for those that want to boot an OS thats larger than the eMMC we use.  Given that 16GB (we may end up with 32GB) can handle practically all OS including windows 8.1 for mobile - how many people are going to want to use and swap a uSD?.   For that minority, they can use one of the three already available options and not impose slower speeds on everyone. Even if you use one of the available options, that still still leaves you with 2 free slots.   Honestly , how many do you need.  This would be a whole different ball game if we had no expandeable options already  - but we do , we have 3.

3 to 4? Two SD and one Micro SD. What's is this already third option? USB?

USB isn't the same as having SD cards in slots. That's a whole different thing to

carry.

I know no one forcing me, but I still don't want any of my SD memory to be taken up by the Default OS, if any OSES at all. For any large files, I'll use a SD, not just for OSES. Why wouldn't they want to swap a uSD if the option is there?


I get your point about speeds greatly trumping the Micro SD, but I'm not using that as my main storage anyway and if the Micro SD fails, I can easily replace it.

 

[comradekingu]

Just being able to load faster doesn't translate directly to better startup time, stats another metric that gets saturated before bus speed. The task can be parallelized, but that also means higher queue depth, cutting available read speed between multiple files, see http://www.bootchart.org/  and systemd-analyze if you use that

That limited space is limited in the sense that you can use it up and that performance is rooted in ability, is nothing new.

Booting debian from ram is based on experience, unless you don't have debian in mind, there is ample space to make that feasible with 4GB of ram, and plenty leftover for userspace.

I know some dont think uSD or eMMC fails, but it does, even best case, using ram for writes alleviates this. Also http://linux.cloudibee.com/2007/11/linux-performance-tuning-vm-swappiness/

 

[vcoleiro1]

@Natsu -> I don't think you read my post at all.  Why would any external slot be used for your default OS?.   Read what I wrote about that.

 

[Natsu]

@Natsu -> I don't think you read my post at all.  Why would any external slot be used for your default OS?.   Read what I wrote about that.

A mistake on my part (probably from being slightly tired), but you kind of ignored everything else written.


I don't think we are getting anymore than 2GB of ram.


Apparently Toshiba's Exceria Pro SDHC does goes higher, but it will cost a lot. lol

 

[vcoleiro1]

@Natsu -> I don't think you read my post at all.  Why would any external slot be used for your default OS?.   Read what I wrote about that.

A mistake on my part (probably from being slightly tired), but you kind of ignored everything else written.


I don't think we are getting anymore than 2GB of ram.


Apparently Toshiba's Exceria Pro SDHC does goes higher, but it will cost a lot. lol

Useless though when the OMAP5 bus for uSD limits you to 100MB/s. $377 for 32GB is a fortune though -  wow, that's a lot. 

 

[Natsu]

Useless though when the OMAP5 bus for uSD limits you to 100MB/s. $377 for 32GB is a fortune though -  wow, that's a lot.

That's for SD. SanDisk Extreme Pro seems to be the fastest for uSD.

Do we really need something faster than that?

 

[comradekingu]

Post to actual benchmarks, pleeeeeeeeeease.

The answer to your quesiton i think is we dont need anything more expencive than whats available for 20 dollar in the way of samsung plus uSD. If 20 dollar is something you can not afford, you are then settled with that option, in that you get nothing and pay for nothing, instead supplying your own. (or booting from network)

If we could have something better than the prospect of this, i would think that its something im unaware of, or better answered by more memory.

In the sense that price for you _isnt_ an issue, go ahead with the no-sd option and uSD extreme pro hatchback 1000x

This is my current view, and it does cover anyone i can think of. I understand that its not 100% for everyone, but it isn't zero for anyone, which is the option here.

It solves a lot of problems, and it only creates difficulty in exchanging the already available sim slot bay with a dual option, plus of cource sourcing parts, which is equally hard, but a gamble with no options for total disaster in the case of uSD.

 

[_wb_]

One other advantage in having a non-replaceable eMMC is that you know that the performance won't vary from user to user and therefore you can rely on a baseline. For example, in DraStic there's a file information cache that stores data about ROMs in the directory. On one of my SD cards it takes over a minute to create this file for a huge directory, while on another SD card it just takes a few seconds. If we were using an eMMC card that had even better IOPS than the SD card I used then chances are I wouldn't even have to bother with this cache.

I don't think this is a very good argument: it assumes that people have to use the eMMC for data files like emulator roms. Of course you can do that, but then the limited size of a fixed eMMC will really become an issue over time.

 

[Exophase]

I don't think this is a very good argument: it assumes that people have to use the eMMC for data files like emulator roms. Of course you can do that, but then the limited size of a fixed eMMC will really become an issue over time.

I was trying to make a broader point that latency can matter in software by using an example. Not "we need this for cataloging ROMs!" If you REALLY need me to come up with a hypothetical use case that would still apply to eMMC I'm sure I can manage something.

 

[Natsu]

If 20 dollar is something you can not afford, you are then settled with that option, in that you get nothing and pay for nothing, instead supplying your own. (or booting from network)

I don't think there anything worthwhile under $30 for Micro SD Cards.

 

[comradekingu]

I dont think you linked to any numbers, so i have no idea what kind of argument that even is, nor why it makes sense. What are you comparing it to?

I assumed wrongly again, turns out memory isnt cheap nowadays

4X http://www.digikey.com/product-detail/en/MT41K1G8TRF-125:E/MT41K1G8TRF-125:E-ND/4315802 would run 100 dollar for 4GB

4gb density chips run 40 dollars for 2GB.

 

[Natsu]

I dont think you linked to any numbers, so i have no idea what kind of argument that even is, nor why it makes sense. What are you comparing it to?

Sorry, between wrong description, sales ,different names and whatnot, I had some confusion.

In any case,looking around, you'll only can get 8GB for the speed we are looking for near that price.

http://www.walmart.com/ip/SanDisk-SDSDQXP-008G-A46-Extreme-Pro-8GB-microSDHC-CL10/30098715

16gb at those speeds seem worthwhile. Those are around $40.

 

[_wb_]

I don't think this is a very good argument: it assumes that people have to use the eMMC for data files like emulator roms. Of course you can do that, but then the limited size of a fixed eMMC will really become an issue over time.

I was trying to make a broader point that latency can matter in software by using an example. Not "we need this for cataloging ROMs!" If you REALLY need me to come up with a hypothetical use case that would still apply to eMMC I'm sure I can manage something.

Of course latency matters. I just think it's not a good idea to make software that relies on fast storage to work properly, because we don't want to force people to store their stuff [whatever stuff, not necessarily ROMs] on the fast internal storage whose latency is known, but allow them to use the SD slots or an USB drive or whatever.

What about my proposal to use a small embedded SATA SSD for internal storage (fixed capacity, relatively small but fast) and microSD for secondary internal storage (upgradeable, not so fast but can still be quite good if you pay for it)? It can be significantly faster than eMMC, and the SoC has SATA lines available anyway that would otherwise not be used. See this post:

http://boards.openpandora.org/topic/15682-a-physical-dummy-power-usage-and-mipi/page-2#entry315789

 

[Askarus]

What about my proposal to use a small embedded SATA SSD for internal storage (fixed capacity, relatively small but fast) and microSD for secondary internal storage (upgradeable, not so fast but can still be quite good if you pay for it)? It can be significantly faster than eMMC, and the SoC has SATA lines available anyway that would otherwise not be used. See this post: http://boards.openpa...e-2#entry315789

As I've said in the thread I like the idea a lot.

 

[Natsu]

What about my proposal to use a small embedded SATA SSD for internal storage (fixed capacity, relatively small but fast) and microSD for secondary internal storage (upgradeable, not so fast but can still be quite good if you pay for it)? It can be significantly faster than eMMC, and the SoC has SATA lines available anyway that would otherwise not be used. See this post:

http://boards.openpandora.org/topic/15682-a-physical-dummy-power-usage-and-mipi/page-2#entry315789

Gees... Even I got call memory overload. Does it really make any sense to having both?How much would this even cost?

Would be less likely that it will fail vs eMMC?

 

[Askarus]

What about my proposal to use a small embedded SATA SSD for internal storage (fixed capacity, relatively small but fast) and microSD for secondary internal storage (upgradeable, not so fast but can still be quite good if you pay for it)? It can be significantly faster than eMMC, and the SoC has SATA lines available anyway that would otherwise not be used. See this post:

http://boards.openpandora.org/topic/15682-a-physical-dummy-power-usage-and-mipi/page-2#entry315789

Gees... Even I got call memory overload. Does it really make any sense to having both?
How much would this even cost?


Would be less likely that it will fail vs eMMC?

It makes a lot sense to me.

Fast for booting and the programs that should load fast.

Micro SD for home and all the DATA you want on the Pyra.

Even if the advantage that you have your whole system on the micro SD and can place it in any other Pyra gets lost it's the best solution I think.

 

[_wb_]

For example, compare SanDisk iNAND Extreme (their best eMMC) and SanDisk iSSD i110 (their smallest SATA SSD):

Both are available in sizes from 8GB to 128GB. If there's also a microSD slot behind the battery, we don't need a large size: 8GB or 16GB is enough.

Sequential writing: 45MB/s for the eMMC, 450MB/s for the iSSD

Sequential reading: 150MB/s for the eMMC, 350MB/s for the iSSD

I couldn't find numbers for random access but iSSD should be much faster.

Only downsides I can think of: it's probably more expensive, and it probably consumes more power (they say 55mW typical average power consumption, which seems OK to me).

What about my proposal to use a small embedded SATA SSD for internal storage (fixed capacity, relatively small but fast) and microSD for secondary internal storage (upgradeable, not so fast but can still be quite good if you pay for it)? It can be significantly faster than eMMC, and the SoC has SATA lines available anyway that would otherwise not be used. See this post:
http://boards.openpandora.org/topic/15682-a-physical-dummy-power-usage-and-mipi/page-2#entry315789

Gees... Even I got call memory overload. Does it really make any sense to having both?
How much would this even cost?

Would be less likely that it will fail vs eMMC?

Well obviously there would be no need to ship it with a microSD card, so the extra cost of that is negligible.

SSD would be more expensive than eMMC, but since internal storage would still be upgradeable through microSD, we don't need a large capacity. So all in all it might even be the cheapest option to use a small SSD.

 

[Natsu]

Both are available in sizes from 8GB to 128GB. If there's also a microSD slot behind the battery, we don't need a large size: 8GB or 16GB is enough.

I can deal with 16GB, but I think 32 would be awesome.

Well obviously there would be no need to ship it with a microSD card, so the extra cost of that is negligible.

Well, can't argue with that. Really just a space issue now.

 

[xiongxioi]

I kinda want to have a ssd in my pyra. Not sure if it is too much to ask, but it is certainly more useful than some crappy webcam.


Not sure what one can do with it though.