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

[Granitehead]

eMMC - most likely 16GB or 32GB, faster than uSD, not possible to replace, only one size available

uSD - any size/speed available, with max speeds a bit lower than eMMC's, obviously user replaceable

replaceable eMMC - most likely ED couldn't just buy finished modular eMMC memory. He would need to produce boards with a connector and an eMMC chip himself. On the Pandora main board there would be a fitting connector instead of the eMMC module. That means for each eMMC module people want, he would need to produce another batch of add on boards. That means there would be a limited amount of different eMMC modules available. This will certainly raise cost, but it's hard to judge how much.

Now this has been discussed and both eMMCs and uSDs have advantages. Unlike certain other questions, I think this really just boils down to personal usage patterns and everyone should be able to decide what is better for themselves easily.

So, vote away. :-D

It's in theory possible to get replaceable eMMC, but I think the consensus of the discussion was that it can't be obtained easily enough and it's supply isn't guaranteed for long enough. That's why I didn't include it. If it was readily available, I think most people would agree it's the best solution unless it adds to the cost a lot. But that's just irrelevant speculation.

Updated poll so you can say how much you would be willing to pay for it.

Having both at the same time would probably be too expensive, but I guess nobody would object if it was cheap (and actually possible SoC wise).

Edit: After adding the new questions already came the doubts whether it's actually the right question to ask. Maybe I'll delete it again later in favour of the right question.

Edit: So I've put some more thought in this and I think it's the best question to ask considering we're missing lots of information. Only if we had some rough idea what it would cost to produce n different flavours there would be a better one.

Only I think I'm going to add more money answers.

Edit:

No, I'm going to stick with the amounts of money available as answers now.

 

[WizardStan]

Given we've got two external SD cards I'm ok with a fixed internal storage for the operating system. Speed and cost is more important to me than size and replaceability.

 

[God Ginrai]

Given we've got two external SD cards I'm ok with a fixed internal storage for the operating system. Speed and cost is more important to me than size and replaceability.

Given that we will be installing more from the standard debian repos, and thus using our system memory more, I wish to have microSD to allow both the ability to increase the OS storage to the size we need as well as the ability to replace the storage in the case of a failure.

-God Ginrai

 

[SNESFAN]

I can definitely see an advantage of having 64gb (maybe 128gb) allocated for OS + apps and having my media on several external 128gb or 256gb cards

and who knows what level of storage will be available a couple years from now?

 

[comradekingu]

Could this be included to gauge interest http://www.hardkernel.com/main/products/prdt_info.php?g_code=G138750181426

uSD cards are the most prone to failure and dodgy items except for batteries, making both user replacable makes a lot of sense. It can be used for troubleshooting, and should something be wrong, the fault can be scrapped and a new one installed, instead of tying the whole board to the problem.  http://www.bunniestudios.com/blog/?page_id=1022

If not the replacable eMMC im tempted to vote for uSD just because they also can be upgraded, and its less of a risk for costly problems. It also brings price point of initial purchase down a little bit.

uSD sucks a bit for OS use, but its whatever tradeoff you want to make, im not opposed to making the whole thing thicker, or even shipping without internal storage.

If everything could be user replacable from a hatch at the left side, where you can insert sim, storage, and battery it would be pure win. Or if the battery is in a hatch at the bottom, maybe  a cutout in the case material above the battery could accomodate the slightly taller replacable emmc solution (compared to nand soldered in)

TL;DR  you buy the emmc size you have use for, and the prospect of doing so even gets better long term.

 

[WizardStan]

Given that we will be installing more from the standard debian repos, and thus using our system memory more, I wish to have microSD to allow both the ability to increase the OS storage to the size we need as well as the ability to replace the storage in the case of a failure.

That's why I have an SD card install.

 

[God Ginrai]

Given that we will be installing more from the standard debian repos, and thus using our system memory more, I wish to have microSD to allow both the ability to increase the OS storage to the size we need as well as the ability to replace the storage in the case of a failure.

That's why I have an SD card install.

Yea, but if I use the SD card for my install, then I give up one of my two SD card slots and am completely ignoring the storage that comes on the device. Also, if cost is what matters to you, then the microSD would be a cheaper solution, because it would allow EvilDragon to include a smaller amount of storage by default, since all the users can upgrade it if they want more space.

-God Ginrai

 

[Klumpen]

Make it fast!

(We survived some years with only 512mb, so even 8gb would be fine.)

 

[God Ginrai]

(We survived some years with only 512mb, so even 8gb would be fine.)

We weren't suggesting that people could just install things as basic as LibreOffice, the GIMP, and Firefox from the repo back then, tho'. Now we will be.

-God Ginrai

 

[urisma]

I think internal eMMC would be optimal (or internal mSATA. A guy can dream right?). Since the internal eMMC is the boot drive it should be as fast as possible. In theory, you wouldn't be putting large programs (firefox, office suite, your ROM collections) on internal eMMC, rather those should go on the SD cards. The eMMC should be for libraries and dependencies (all your .deb files) which aren't terribly large. To put it in perspective: I run linux on a chromebook with 16GB internal storage and have never had a problem fitting all the necessary dependencies, compilers, libraries, etc on it. The SD cards are perfectly suited for media, which just leaves the problems of where to put large programs. I think the idea is generally: install .deb dependencies to the internal storage and put your programs in .pnd-next files on the SD cards (most user programs will go in pnd-next files). If the Pyra follows this general pattern then I don't think it would need much more than 32 gigs of internal storage. Obviously the pnd-next system needs a lot of work, but by the time the Pyra is released it will (hopefully) be working well.

 

[Klumpen]

(We survived some years with only 512mb, so even 8gb would be fine.)

We weren't suggesting that people could just install things as basic as LibreOffice, the GIMP, and Firefox from the repo back then, tho'. Now we will be.

-God Ginrai

My Linux Mint partition currently uses 11gb including some games.

I wouldn't even need 32gb if I would be even more messy than I am.

16gb or if you deperately want it 32gb eMMC would be just fine, as long as it's fast.

Maybe 32gb would be nice for a big swap though, but I don't know, if we really need it.

 

[God Ginrai]

I think internal eMMC would be optimal (or internal mSATA. A guy can dream right?). Since the internal eMMC is the boot drive it should be as fast as possible. In theory, you wouldn't be putting large programs (firefox, office suite, your ROM collections) on internal eMMC, rather those should go on the SD cards. The eMMC should be for libraries and dependencies (all your .deb files) which aren't terribly large. To put it in perspective: I run linux on a chromebook with 16GB internal storage and have never had a problem fitting all the necessary dependencies, compilers, libraries, etc on it. The SD cards are perfectly suited for media, which just leaves the problems of where to put large programs. I think the idea is generally: install .deb dependencies to the internal storage and put your programs in .pnd-next files on the SD cards (most user programs will go in pnd-next files). If the Pyra follows this general pattern then I don't think it would need much more than 32 gigs of internal storage. Obviously the pnd-next system needs a lot of work, but by the time the Pyra is released it will (hopefully) be working well.

The repository does not play nice w/ removeable media. Installing anything from the repo onto SD, as I understand it, would be a big problem.

(We survived some years with only 512mb, so even 8gb would be fine.)

We weren't suggesting that people could just install things as basic as LibreOffice, the GIMP, and Firefox from the repo back then, tho'. Now we will be.

-God Ginrai

 My Linux Mint partition currently uses 11gb including some games.

I wouldn't even need 32gb if I would be even more messy than I am.

16gb or if you deperately want it 32gb eMMC would be just fine, as long as it's fast.

Maybe 32gb would be nice for a big swap though, but I don't know, if we really need it.

Your Linux Mint partition is likely on a hard drive that can be replaced when it dies. I only mention space because that is a concern for some users. My concern is completely for the replaceability.

-God Ginrai

 

[Klumpen]

I expect to get quality, so it shouldn't fail at all, has any Pandoras NAND ever failed?

 

[Reyhn]

16GB eMMC would be the best fit IMO, assuming reasonnable costs.

8GB might be a little tight for a full OS install to be comfortable (but still doable), 16GB is nice yet doesn't add much to the price, no real need for 32GB except in some really specific cases.
Or at least I hope so.

 

[WizardStan]

Yea, but if I use the SD card for my install, then I give up one of my two SD card slots

That's a fair argument. I personally still weigh speed against it though.

and am completely ignoring the storage that comes on the device.

Lots of things to be done there...Union mount internal storage and one SD card: see the entire thing as one giant partition, you've got the "base" OS on the internal, and any additional packages or updates get layered on the SD card. Occasionally pop out the SD card and run an update on just the base operating system and then put the SD back in and run an update on all extra install packages.

Easier than a union mount, have the base OS on the internal flash and symlink /home and /usr/share to the SD card.

Completely reverse them: treat the SD card as your operating system and the internal as data (ROM) storage. Kind of backwards and a little riskier, but as long as you aren't constantly deleting and installing new ROMs or ISOs or whatever it would be fine. I wouldn't recommend it but if you know what you're doing it'd be ok.

it would allow EvilDragon to include a smaller amount of storage by default, since all the users can upgrade it if they want more space.

That's a false comparison. It would be cheaper only because the storage would be smaller but if someone wanted the 16/32GB storage that would have come standard as an eMMC that means they'd have to then buy the larger uSD card themselves, in addition to whatever it was shipped with, or as a premium for the original sale: keeping everything equal there isn't actually any savings.
Note that I'm not discounting your opinion, I understand that being able to upgrade and replace the internal storage is important to you for the reasons you've given, they just aren't as important to me as the faster speeds, which is why I voted eMMC.

The repository does not play nice w/ removeable media. Installing anything from the repo onto SD, as I understand it, would be a big problem.

Exactly this is why the PND format was invented.

 

[God Ginrai]

it would allow EvilDragon to include a smaller amount of storage by default, since all the users can upgrade it if they want more space.

That's a false comparison. It would be cheaper only because the storage would be smaller but if someone wanted the 16/32GB storage that would have come standard as an eMMC that means they'd have to then buy the larger uSD card themselves, in addition to whatever it was shipped with, or as a premium for the original sale: keeping everything equal there isn't actually any savings.

That's not what I meant. I meant it would be cheaper for EvilDragon, and thus easier to produce. This would also bring a cheaper cost to the user as well, unless they spend money to upgrade their card. But the average user would get a cheaper cost. Also, any support problem that would involve a borked OS or OS storage would easily be fixed by using a new microSD.

The repository does not play nice w/ removeable media. Installing anything from the repo onto SD, as I understand it, would be a big problem.

Exactly this is why the PND format was invented.

Have you not seen the OS topics? All the discussion of the PND format for this future device has leaned towards using it only for games and to use the repo for everything else.

-God Ginrai

 

[comradekingu]

I expect to get quality, so it shouldn't fail at all, has any Pandoras NAND ever failed?

Of course, nand isnt infallible. Besides, smaller production technique means inherent unreliability goes up, and the need for complex controllers to keep the situation in check rises.

 

[fusion_power]

UHS-II SD's can get up to 240MB/s read/write so it would be enough for internal storage I think but of course these type of cards are still expencive. So because speed and costs are an factor for the OS storage, I guess we will not see an internal (micro)SD slot. eMMC is OK I think.

 

[Askarus]

Shouldn't the poll be:

o Speed

o Size

o Durability

o Possibility to upgrade

o Possibility to replace if broken

For me this would give a much better impression what people want.

Then we know what suits best:

Micro SD

emmc small and cheap

emmc big and more expensiv

emmc exchangeable

 

[Grench]

eMMC - most likely 16GB or 32GB, faster than uSD, not possible to replace, only one size available

uSD - any size/speed available, with max speeds a bit lower than eMMC's, obviously user replaceable

Your assumptions are not complete - there is more to the picture.

eMMC is available in 4, 8, 16, 32 and 64 GB.

Very fast bleeding edge eMMC is currently marginally faster than very fast bleeding edge microSD, but costs much more than 'normal' eMMC.

'Normal' eMMC is on-par with current class 10 UHS-I microSD cards.

Bleeding edge microSD cards are much faster than 'Normal' eMMC.

What is 'bleeding edge' on microSD today is the 'normal' card, with no in 18 months or so.

Although it would be -possible- to put a 'fast' eMMC module in the device at twice the price of a 'normal' eMMC module that would be somewhat faster than the microSD cards of today, two years from now it will likely be slower than the 'bleeding edge' microSD cards on the market - and seem pathetically small.

Personally, I would like to see a microSD card slot with an 8GB mid-range Class 10 UHS-I microSD card included to keep the costs down. It would cost about the same as a 'normal' 16GB eMMC and boot just as quickly. Then users would be free to pop in whatever they want later - giving them options.

Keep in mind, even a $8 8GB microSD card reads at 30MB/s, which is 150% of the theoretical maximum of the SD slots on the current Pandora. http://www.amazon.com/Ultra-microSDHC-8GB-Class-UHS-1/dp/B008F1BIPM

Really fast eMMC is currently topping out around 100MB/s.

'normal' eMMC is currently running around 45-60MB/s

Really fast microSD cards are currently hitting 90MB/s.

Cheap but good microSD cards are currently hitting 30MB/s

The Pandora's theoretical maximum is 20MB/s and reality is ~17.5MB/s

Using eMMC locks the device into whatever speed and capacity is chosen today.

Using microSD gives us the flexibility to use whatever speed and capacity exists now and tomorrow.

So - to me, the real question is: How fast can the eMMC/microSD connection on the SoC go?