2GB and 4GB


HelenF

Very Active Member
Joined
Jun 22, 2013
Messages
615
Location
UK
Looks like I preordered a 2GB RAM Pyra way back. I read somewhere that the 2GB orders are a tiny minority. Where are we at with that now?

If they were all 2GB RAM, I think that would have been enough. But I'm concerned that if nearly everyone has a 4GB Pyra, that will be treated as normal, and 2GB owners might miss out on things.
 
2GB might use a little less energy then 4GB version, but I assume 4GB would be preferable as you can always charge your Pyra but you can't just add more memory (maybe virtual memory, but it's less fast).
I'm assuming most applications might not require this amount of RAM though, but this assumption is based on a hunch so I can be really wrong.
 
2GB might use a little less energy then 4GB version
Supposedly the power difference would be really small. Whatever it is, I'm pretty sure that the 2GB version is not going to get by using only half the power of the 4GB version. I know that it should on paper but RAM works really strange.

Maybe you should run some games or loads —that are representative of what you want to do on Pyra— on your current computer and see how much ram that costs using "free -h". For example, I'm using 7.2Gi, so I know that I would need the 4GB version + download 4 extra GB RAM.
 
  • Like
Reactions: rSl
Well, yes, of course it won't chop power usage by half, but then nobody with sense really expected that. The main power consumers are probably be the backlight and the CPU, or maybe the wifi chip or even the sound chip (my current solution to getting sound out of my laptop is a USB thingy, and that's currently radiating an appreciable amount of heat), all stuff that doesn't vary between the 2GB and 4GB units. I'd expect the mobile editions to use more power than the non mobile ones, but in terms of the cost of DRAM refresh, its power draw been thouroghly lightened through the 80's and 90's, so I wouldn't expect it to be a big percentage. The 2GB units will still use half the power for DRAM refresh, but given that's not a big constituent of system power it won't really affect battery life and stuff like that.

Edit: I'm also one of the few who have ordered 2GB RAM units. I believe that should be sufficient, and I can always enable swap for things that use more RAM in a non-interactive session (such as a game loading data). I wouldn't be against paying a little more to make my unit more standard though.
 
With the Pyra using desktop/laptop style DDR3 rather than one of the mobile LPDDRn varieties due to unavoidable constraints, self-referesh current will be relatively high but I don't know how much this depends on size.

As you've picked up this is going to be irrelevant during operation because it would be dominated by CPU, backlight, and the access/IO power consumption of the DDR3 (which will depend even less on size).

But during standby, this could be the biggest part of power consumption if it is possible to make the lowest power off modes of the OMAP5 actually work. Unfortunately it seems like these have been decoded due to TI possibly because of subtle bugs, so we may be limited to the medium-power retention mode at best (and even that is the source of occasional random lockups on newer kernels at the moment...)

I think excellent standby times are not something to expect from the Pyra, but maybe things will improve as time goes on.
 
In theory hibernate might work, but it is not so commonly used on ARM devices (because they usually have working low power suspend) therefore some SoC-specific state saving and restoring code might be needed.

It's probably not going to be that useful on a regular basis unless you have a fast and durable SD card.
 
Yeah, I'm expecting to begin with I'm going to have to turn my Pyra off at night, and it probably won't make a full day in use. But that's one thing I'm pretty sure will improve over time, when showstoppers are fixed and you can spend time measuring system load and stuff like that. It certainly went that way with the Pandora.
 
What we need is some sort of standby mode.
So that we can use the Pyra as an always-on device
 
Well, to my ear at least, standby indicates no processes are running, which includes networking processes and network appliances. What we need in my lingo at least is reduced near-idle power, if you want an always connected device that you expect to respond to pings of various types.
 
The Pyra should have that, working in the same way as any Linux laptop, there are two problems. This is more than just freezing processes as it also puts devices into low power mode (eg turning off the screen). I am not sure how easy it is to make some stuff still run in the background like a phone.

1. It's not working at the moment. It works on the uEVM so one of the Pyra specific device drivers or daemons must be blocking standby.

2. As mentioned, the OMAP5 does not officially support very low power standby modes, only a simple one where the CPU is essentially frozen in place with active parts turned off - but L1/L2 and registers are still powered up. This is the same power mode the CPU enters when idle.
 
In my idealized perfect world...

I would like my Pyra to cold boot from the microSDXC card (it already does this with the shoulder button pressed). I have a 1TB Sandisk microSDXC card that I have been using for another project. They seem to be good. I plan to use one in the interior microSDXC slot in my Pyra eventually. Until then I'll just keep fiddling around with 64GB to 400GB cards in it.

I would like it to do a 'light hibernation' when the lid is closed. Functionally, the unit would mirror RAM to the eMMC then more or less shut down.
When the lid is opened, the eMMC as boot target catches that it had an 'active suspend', does a light boot from eMMC to restore the contents of the eMMC RAM mirror to RAM, then passes control to the OS on the microSDXC for continued operation. In this idea, the eMMC only gets used for the suspend/restore function. The eMMC has plenty of room and durability for this task.

How long it would take to suspend/return would depend on how much RAM we are using at the moment. But, either way it should be a matter of seconds.

But - that is a pretty complicated trick and the returns for doing it are pretty small. Why small? Because the whole Pyra takes less than a minute to boot anyway.

Short of a solution described above, I will likely just set my lid switch to trigger a power down if not re-opened inside of ~20 minutes. That is how I have my e-reader set up and that seems to work about perfectly.
 
A chip less is a chip less that eats power.
All this "but the cpu needs so much more" is nonsense.
Thats like asking how bad smoking is and all scientist just tell you cars are deadlier. Dafuck am i supposed to do with that information when i want to calculate say a lifespan?
 
I don't really need an always-connected option.
What I want is to be able to quickly wake my Pyra up from sleep.
Booting takes much too long.
Long booting times combined with high power consumption in idle is not a good combination.
 
Thankfully, battery lifespans are measured in Ah and they'll do that more or less the same time after time. Just add up all the power demands on the system and you can calculate how long the battery will last.
 
A chip less is a chip less that eats power.
If I remember correclty (someone more knowledgeable than me could confirm/correct), there are no chip less.
The 4GB unit has 4x8Gb modules, and the 2GB unit has 4x4Gb modules.
 
Previously, people were saying that you could see the number of orders from the remaining shop stock. But that requires knowing the starting numbers. I'm not sure what the following tells us.

Code:
Stock Version
1746  Mobile Ed., US-Ver., 4GB RAM
1474  Mobile Ed., EU-Vers., 4GB RAM
1737  Standard Edition, 4GB RAM
2002  Mobile Ed., US, 2GB RAM
1992  Mobile Ed., EU-Vers., 2GB RAM
1984  Standard Edition, 2GB RAM
 
Back
Top