Ram & eMMC costs / power drain

[comradekingu]

Educate yourself.

 

[matzesu]

What if you make a "Low Power Mode" where the OS Only Adresses 2gb Ram, and a "Hight Speed Mode" where the 4 gb are getting use??
This way, you can have 4 gb if you need,
But if you dotnt need 4 gb, its runs whit 2 gb or less..

 

[Mr_Loon]

Actually, I doubt any image or video editing solution that needs more than 2GB RAM would run pleasantly with the CPU we have.
That stuff is not only memory but also CPU hungry, and not (yet) suited for any mobile processors IMO.

This is not the case for image editing, from my experience with Photoshop (can't imagine gimp is any different) it is not overly processor intensive but very hungry for Ram when editing multi layer images and maintaining an edit history. I can see why the processor would be more important for video editing.

However please let people know the cost & battery implications for Ram & cost implications for eMMC so they can make an informed decision based on their own needs & desires rather than simply following the dogma that '2GB is enough for me so it's enough for you'.

I still fail to see how a good decision can be made without knowing the cost implications.

So instead of covering what most people do and use, we should build a device that purely fits your specs and what you will use it for, ignoring the extra costs involved, and battery drain.

Certainly not, what this post is requesting is actual figures relating to cost & battery so they can be considered rather than ignored.

 

[Swordfish II]

I guess my position is this:

2GB has been proven to be more than enough in all current cases with room to grow. 4GB would be nice provided it has minimal extra cost (<$100) and no substantial power drain.

 

[levi]

A few years down the road, ED will probably have replacement CPU boards for sale, and those can contain significantly more RAM if people's use cases change to need it. For now, I think I'll be happy with 4 times the RAM than I've got on my Pandora.

Edit: But if it make commercial sense for ED to supply more RAM to compete with alternative solutions, and it doesn't impact battery life significantly, or make the Pyra unaffordable, then it's probably a good idea even if I don't currently have a use for it. As at the head of this thread, typical power consumption and cost stats are still needed (but I'm happy with only ED seeing those numbers and just announcing what he'll go for, if that's simpler).

 

[ible]

@comradekingu: there's no right or wrong here. you have good arguments, but we're trying to rationalize what we'll probably be stuck with.

 

[Mr_Loon]

@comradekingu: there's no right or wrong here. you have good arguments, but we're trying to rationalize what we'll probably be stuck with.

What I would like to see is a rational argument that explains why it is better to make the decision without also knowing the cost / battery implications.....

 

[Agricola]

And again an argument is running in circles with insults coming up a few times...
Yes, 4GiB would be A LOT for this device, but it definitly could be used, eventhough just in rather extreme ways. As I said earlier, loading a full GD-ROM image into RAM and still have enough free for reicast would be a fantastic feature, and with OS'es like Puppy or FatDogARM it'd even have cool everyday uses for more or less normal consumers. And if it could be deactivated and reactivated on the go, cost is the only determining factor.

But as long as hot plugging RAM is not tested for the Pyra, there's just no foundation for a good argument for both sides. Also, nobody knows how much energy is exactly used by the 1GiB chips in comparison to the 512MiB ones.

Let's just wait for the test results and have a rational discussion then.

 

[levi]

Even a GDROM is only 1GB or thereabouts anyway. Although it's not really necessary to load something that's designed to be loaded from slow disc media to fast RAM. The dreamcast itself only had 26MB of system ram (combined main RAM, VRAM and audio RAM).

But perhaps being able to hold a GDROM in RAM might help with things like compressing the iso file. Certainly when I tried compressing 2.4GB GC isos on a machine with only 0.5GB of RAM, it took over half an hour per iso.

 

[comradekingu]

Its not really necessary to buffer audio-tracks either, as the CDs they came from were designed to read small 16bit chunks real-time.

The dreamcast itself was/is a finite target, with known-footprint games. When you try to emulate them, its no longer exactly as clear cut. And you might be doing a whole lot of other things concurrently.

The Linux kernel, or any program running under it, doesn't by neccessity target the pyra with the same level of adaptation.
So once you run out of L1 cache, you have ram at your disposal to make up for it. Or, in case you don't, it will be dog slow. You could argue the rarity of the event, but consider it as it just happened, from the users perspective. An out of the ordinary pain in the ass is not one easily forgotten.

Any engineer will make the compromise available at the time. And Its not the 80s or the 00s anymore.

 

[_jr_]

Any engineer will make the compromise available at the time. And Its not the 80s or the 00s anymore.

No, it's '2G is enough for anybody' time

 

[Agricola]

Even a GDROM is only 1GB or thereabouts anyway.

About 1,4GiB, combining that with graphics, an OS and cellphone apps to use the 4G module all the time would for sure use more than 2GiB. Yes, that is a rather extreme use case, but I personally would definitly do something like that if I had a Pyra with 4GiB (if the SoC doesn't give up before). But I would be completely ok with "just" 2GiB, SD cards are also fast enough for everything aforementioned and with Linux you can swap like a madman with the eMMC. Compressing GC ISOs and editing media files are things I've never really done before, so I can't say anything about it.

The dreamcast itself only had 26MB of system ram (combined main RAM, VRAM and audio RAM).

I'm always amazed by the capabilities of old hardware through the necessity of software optimization.
Even back then the Dreamcast's RAM was small in comparison to PCs or the PS2. It used a lot of texture compression, no one would do that nowadays and I don't think emulators try to safe the space by leaving everything just as compressed in the video memory. Still, of course, the decompressed textures are at maximum 32MiB big if we can trust Sega's advertisement from that time, plus 16MiB CPU and 2MiB Audio RAM.

So yeah, 4GiB would probably be overkill for most of my uses, but an overkill I'd gladly accept and even pay some money for, as long as it can be deactivated to safe power. And if others can actually use that space reasonably, 4GiB would definitly get my vote. Now, if only that was worth something...

 

[lukey]

And Flash is still very fast.

 

[Faust]

Is it possible to boot from the internal micro sd card and use the eMMC as RAM at the same time?

 

[Agricola]

No, only one can be accessed at a time as they share the same connections to the SoC. But you could boot from another SD card and swap to the eMMC.

My plan: Use one SD card as boot medium for FatDogARM and the whole eMMC as swap, then set swappiness to 100. That sure makes sense...

Edit: Theoretically, you could boot from the µSD, load your whole OS into RAM and change the connections to the eMMC and use it as swap. But then you could neither use the huge memory of the µSD nor the fast boot of the eMMC, so...
Also, last time I looked, hot-plugging eMMC/µSD was still unconfirmed.

 

[Grench]

Is it possible to boot from the internal micro sd card and use the eMMC as RAM at the same time?

That depends on your definition of 'same time'. To my understanding both should be visible to the OS, but attempting to use one while the other is in use will result in some wait for the resource to flip over.

However, it isn't an 'all or nothing' scenario on the NAND either. You can boot from the NAND AND use a /SWAP assigned to a file on the same partition or should be able to multi-partition the NAND drive to have a dedicated /SWAP partition.

Being able to use both the NAND and the eMMC during the same session is a new/novel idea that ED floated a few months ago. It should be noted that working from both at the same time should result in a performance hit. Even with this performance hit, it should, in theory, be far faster to both media than the Pandora was.

My plan is to boot and swap and sleep (write memory to disk) on the eMMC and use the uSD for Pyra programs, keeping the SD slots open for media files.

 

[Swordfish II]

No, only one can be accessed at a time as they share the same connections to the SoC. But you could boot from another SD card and swap to the eMMC.

My plan: Use one SD card as boot medium for FatDogARM and the whole eMMC as swap, then set swappiness to 100. That sure makes sense...

Edit: Theoretically, you could boot from the µSD, load your whole OS into RAM and change the connections to the eMMC and use it as swap. But then you could neither use the huge memory of the µSD nor the fast boot of the eMMC, so...
Also, last time I looked, hot-plugging eMMC/µSD was still unconfirmed.

IIRC ED stated you could boot of the eMMC AND use the µSD for storage

 

[lukey]

Create loopback devices on every Storage Device (so zram, Left/Right SD Card, eMMC, 2 USB Sticks and an eSATA Drive(if you use it as Desktop otherwise an third USB-Stick)) and RAID-0 them together. With this you can get large Data Rates and Flash-Wear is distributed evenly.

 

[levi]

IIRC ED stated you could boot of the eMMC AND use the µSD for storage

IIRC he said it was something they'd look into, but my reading of the situation was that getting the timings right to keep everything in sync are likely to turn out to be a bit of work, so don't expect it from the first release is my advice.
[doublepost=1458682198,1458681579][/doublepost]

Create loopback devices on every Storage Device (so zram, Left/Right SD Card, eMMC, 2 USB Sticks and an eSATA Drive(if you use it as Desktop otherwise an third USB-Stick)) and RAID-0 them together. With this you can get large Data Rates and Flash-Wear is distributed evenly.

Technically, if you RAID 0 them together, your total size will be the size of the smallest unit (probably the eMMC, discounting the zram, cos RAID 0 certainly can't cope with drives of variable size) times the number of drives, so say the eMMC is 4GB you'll only get at most 20GB of RAIDed space, because RAID 0 means striped.

But some sort of union mount almost certainly exists to add drives as a single mount point that has all drives be r/w, and hopefully one that wear levels too.

Or you could just use the eMMC to boot off, and RAID everything else. Get matching 256GB SD cards and USB sticks, and the smallest SATA drive you can find and that's 1270GB of unified RAID0 space.

 

[Swordfish II]

Oh I'm aware that lots of functionality will need to be developed after it launches. I loved seeing stuff get better and better one I got the Pandora and I was late to the game.

It will be like Christmas every time I can do something new with the Pyra