Ram Poll.

[bzar]

It's easy for me:
Cost: Don't care
Battery: Important
Too less RAM than needed: Most important

Cost: I'm guessing if it's 15000€ you won't buy it. Obviously there's SOME line you won't cross. It's just high enough you don't consider it ever becoming an issue.
Battery: How much is enough? Will you settle for one day active use without charging? Three days? A week? Obviously there's some line you won't go under.
RAM: What are you going to do with it? If you intend to play the world's largest game of life entirely inside the RAM there probably won't be enough. So obviously there's some use cases you'd consider out of scope. You can ALWAYS run out of RAM one way or the other. What's important here is to identify sensible use cases given the other limited resources (like CPU) and base the estimates on the amount required on those.

Sadly, few things are ever easy if you intend to do an informed decision.

 

[_jr_]

I'm still waiting for a use case for larger memory sizes that isn't based on totally misunderstanding the 'free memory' display and/or assuming amounts of CPU power that the Pyra simply won't have.

 

[Xcl4m4t10n]

I'm still waiting for a use case for larger memory sizes that isn't based on totally misunderstanding the 'free memory' display and/or assuming amounts of CPU power that the Pyra simply won't have.

 

[WizardStan]

What I really don't understand is if battery life is so critical why are so few saying they would be ok with 1GB? 

Because even while people are saying "battery life is important, and sufficient RAM is sufficient" they're still fighting against human nature of "more is better".  1GB might be enough but it doesn't "feel" like it's enough.  I think that's a problem a lot of others are having who want 4 or 8GB: 2GB might literally be enough, but it doesn't "feel" like enough, so you need more.
 

I'm still waiting for a use case for larger memory sizes that isn't based on totally misunderstanding the 'free memory' display and/or assuming amounts of CPU power that the Pyra simply won't have.

I'm still waiting for a use case for larger memory sizes that isn't based on totally misunderstanding the 'free memory' display and/or assuming amounts of CPU power that the Pyra simply won't have.

What just happened here?

 

[Kev2442]

^ Whatever happens. I'm wondering too. Maybe we found out he has a double life...

I'm more and more convinced that we should wait for a SoC which supports LPDDR to put 4GBs on a Pyra.
2GBs is enough for now based on what we did with the Pandora. We may need the longer battery life. The current board is more limited by the CPU than the RAM. And we need a selling point for the upgrades.

In the meantime, you can always get rid of the desk environment along with unnecessary stuff. That should give you some more free RAM for whatever you have to do that takes so much.
I haven't bought 16GBs of DDR3 to render stuff on a handheld console anyway.

 

[TrashyMG]

In the meantime, you can always get rid of the desk environment along with unnecessary stuff. That should give you some more free RAM for whatever you have to do that takes so much.
 

When idle the OS including XFCE4 Desktop uses less than 100MB.. currently idle at 73MBs on the devboard.

 

[_jr_]

Im wondering, too, whether that is the result of a special case of schizophrenia. I hope it is just a quoting accident.

I did vote for 1G and 2G, since all proposed use cases (Browsing, compiling, Grench's multiple Android VMs, X86 VM, etc) will run happily within 1G. But nobody would seriously consider 1G now for the reasons Wizardstan mentioned.

If Nikolaus and ED had always talked about how they are going to use 1G as the best compromise between battery life and performance, we could probably have easily settled for 2G

 

[Grench]

I believe that was an attempt to reinforce and 2X the statement.

I'll 3X it.  In bold.  For emphasis.

I'm still waiting for a use case for larger memory sizes that isn't based on totally misunderstanding the 'free memory' display and/or assuming amounts of CPU power that the Pyra simply won't have.

I have yet to see anyone propose a practical application (200+ browser windows is NOT practical) that actually -requires- more than 2GB of RAM to run.

As to why not 1GB?  1GB is likely enough for >95% of users likely uses.  2GB takes that to >99.5 of users likely uses.

Things that are being forgotten...

The NAND should be VERY fast on the Pyra - similar to SSD speeds.  Utilizing a chunk of NAND for /SWAP isn't going to kill speed like it did on the HDDs of the 386 erra.

If you don't want to use NAND, we should be pushing nearly 100MB/s on the SD busses - all 3 of them.

So, even if you somehow manage to run out of physical RAM on the SoC daughter board, it's not like you're reduced to spinning media speeds for /SWAP.  There is no reason I can think of why you couldn't drop in a 128GB SD card, make the whole thing /SWAP and pretend that you have 130 GB of RAM.

Having a 2GB /SWAP would be adequate for that 'just in case I run out' fear.

 

[Faust]

I really like the idea of using a part of micro-sd card inside the internal slot to swap more RAM, if you can choose the amount of memory you want to swap into RAM I think we can stay with 2GB. 2 GB of a 64 or 128 GB card is really insignifiant!

 

[TrashyMG]

I really like the idea of using a part of micro-sd card inside the internal slot to swap more RAM, if you can choose the amount of memory you want to swap into RAM I think we can stay with 2GB. 2 GB of a 64 or 128 GB card is really insignifiant!

the internal uSD port can only be used if you disable the eMMC(NAND) the OS will reside on as they share the same lines, you could boot on a regular SD card or just have the entire OS on the uSD with a large swap.

 

[Grench]

I really like the idea of using a part of micro-sd card inside the internal slot to swap more RAM, if you can choose the amount of memory you want to swap into RAM I think we can stay with 2GB. 2 GB of a 64 or 128 GB card is really insignifiant!

the internal uSD port can only be used if you disable the eMMC(NAND) the OS will reside on as they share the same lines, you could boot on a regular SD card or just have the entire OS on the uSD with a large swap.

Or, if the NAND is 16GB as speculated, giving it a 2GB /swap partition OR utilizing a /swap file within the primary parition's space would both work just dandy.

If the NAND is 8GB, that would get a bit tight.

Yes, wear leveling in the NAND blah blah - if the NAND wears out in 5 years, drop in a microSD that you'll be able to just about buy from a gumball machine in 2021 and jam on.

1GB is -enough- RAM for a Pyra.
2GB is a -lot- of RAM for a Pyra.
4GB is more RAM than the Pyra can really utilize well.
8GB is simply silly in a very Pythonesque manner.
https://en.wikipedia.org/wiki/The_Ministry_of_Silly_Walks

 

[comradekingu]

The performance hit you take swapping memory is grim
The additional benefit you get by loading the whole OS into ram is reasonable, considering eMMC or SD isnt the fastest storage

Powering memory isnt a big part of the equation, lessened by the big amount of battery bank there is to draw from.

The only time you notice anything is running out of ram, in any way, which considering these things go up, makes a device with more volatile storage a device for the future+1.
 

 

[Grench]

The performance hit you take swapping memory is grim
The additional benefit you get by loading the whole OS into ram is reasonable, considering eMMC or SD isnt the fastest storage

Powering memory isnt a big part of the equation, lessened by the big amount of battery bank there is to draw from.

The only time you notice anything is running out of ram, in any way, which considering these things go up, makes a device with more volatile storage a device for the future+1.
 

Wow - just because you state it does not make it true.

The 'performance hit' should be manageable.  There is no reason to load the whole OS into RAM on a device with FAST eMMC and SD storage.  The only storage faster than eMMC (~200MB/s) are the latest SSD drives, but they're physically huge compared to the eMMC in the Pyra.  SD is only half of the eMMC speeds, but runs at speeds on par with notebook hard drives.  This isn't your father's /swap on a 7 MB/s hard drive.  With how well current versions of Linux manage /swap, you are unlikely to even notice when it crosses beyond 2GB as unused portions of the OS and unused components of running applications would have already been shuffled to /swap.

Powering memory IS (Note:  IS) a big part of the equation.  The Pyra uses DDR3, NOT the LPDDR3 memory that your smartphone likely has.  There is a HUGE difference in memory consumption.  I expect the memory to take roughly 10% of the active use battery consumption and roughly 80-90% of the standby mode battery consumption.

The Pyra is a, "device for the future" because it has a replaceable SoC + memory daughter card.  In the future, we may be able to swap the then 'old' SoC with a 'new' SoC.  The current SoC matches up nicely with 1-2 GB of RAM.  2GB of RAM is already a -lot- for that SoC.  A future SoC that can actually do something with >2GB of RAM could then have whatever is appropriate for that SoC.

For perspective...
According to TrashyMG's post above, the OS lives inside of 100 MB of RAM.  If I remember right, the Kingston eMMC that came on the dev boards was a very slow (cheap) eMMC card at around 20 MB/s.  Trashy - from a cold/off state, how long does it take for the dev board to boot to the desktop?

There are eMMC chips out there that run at or near the bus speed of the Pyra - roughly 10 times the data rate of the Kingston.

 

[Kev2442]

The Amigas had "fast" RAM and "slow" RAM, and they worked just right. Using a high-speed eMMC as swap/hibernate file would be great and remove most of the need for 4GBs.

 

[TrashyMG]

Trashy - from a cold/off state, how long does it take for the dev board to boot to the desktop?

I can time it when I get home in a few hours.

 

[Kev2442]

I suppose you're joking... :rolleyes:
How long does it take to wake up from hibernation ?

 

[TrashyMG]

Trashy - from a cold/off state, how long does it take for the dev board to boot to the desktop?

I can time it when I get home in a few hours.

Well I'm not home yet, but this is from kernel startup to it making it to the slim login manager:

EDIT: Just to add this is a boot from the devboard's uSD slot not the eMMC.

 

[sepulep]

Or, if the NAND is 16GB as speculated, giving it a 2GB /swap partition OR utilizing a /swap file within the primary parition's space would both work just dandy.


If the NAND is 8GB, that would get a bit tight.

Yes, wear leveling in the NAND blah blah - if the NAND wears out in 5 years, drop in a microSD that you'll be able to just about buy from a gumball machine in 2021 and jam on.

1GB is -enough- RAM for a Pyra.
2GB is a -lot- of RAM for a Pyra.
4GB is more RAM than the Pyra can really utilize well.
8GB is simply silly in a very Pythonesque manner.
https://en.wikipedia.org/wiki/The_Ministry_of_Silly_Walks

1GB is clearly too tight since there are multiple PNDs around already for the pandora that won't run if there is no 512mb + 512mb swap,  lets drop that option from the discussion shall we?

 

[comradekingu]

I think that kind of reasoning is akin to a preconceived notion of what a pyra _is_.

Also it doesnt take into account what it can be, now, or could be in the future.

Some people voting for 2GB probably dont know about bigmem kernels.

 

[levi]

FWIW, I note that the current boards revision doesn't let me delete my vote from this poll. That's unfortunate, as when I voted there were two polls open, and this was the one I decided to vote nonsense in.