Suspend To Ram

[aliking]

Looking at the latest video of PMenu, it seems we have about a 40 second boot time. I have no particular opinion about whether that is good or bad, because I had been intending to actually boot very rarely and just keep my Pandora in suspend mode when I'm not using it.

I wondered:

1. Is suspend is working right now in the latest firmware
2. What options for suspending are working - e.g. suspend to ram, suspend to disk, low power/wifi on?
3. What is the power usage in suspend mode/s?
4. How quickly does suspend/wakeup happen?
5. Is there any confirmation on whether suspending might corrupt the SDs?
6. Is suspend currently working using the lid sensor?
7. What can wake the system up? RTC?

I don't think we've seen an update on that, or maybe i just missed it. Also appreciate that some of these may be unanswerable, but can anyone shed some light on the topic?

a

 

[dflemstr]

Looking at the latest video of PMenu, it seems we have about a 40 second boot time. I have no particular opinion about whether that is good or bad, because I had been intending to actually boot very rarely and just keep my Pandora in suspend mode when I'm not using it.

I wondered:

1. Is suspend is working right now in the latest firmware
2. What options for suspending are working - e.g. suspend to ram, suspend to disk, low power/wifi on?
3. What is the power usage in suspend mode/s?
4. How quickly does suspend/wakeup happen?
5. Is there any confirmation on whether suspending might corrupt the SDs?
6. Is suspend currently working using the lid sensor?
7. What can wake the system up? RTC?

I don't think we've seen an update on that, or maybe i just missed it. Also appreciate that some of these may be unanswerable, but can anyone shed some light on the topic?

a

Well, the Pandora uses Linux and a lot of your questions are Linux-generic so I'll try to answer a few of them:

1. Yes, it has to work since it is a feature built into the vanilla kernel. There are probably soem drivers (maybe WiFi?) that have problems going back to their previous state after a suspend-to-disk session.
2. Suspend to RAM is almost guaranteed to work since a lot of devs seem to have been using it during development. Don't know about suspend-to-disk, but it really shouldn't matter since you probably won't be using STD that often (it requires ~256 MB of reserved SD space, and suspend-to-disk is much slower usually than just turning the device off, and recovering from STD will take a minimum of 25 seconds, since SD cards generally aren't faster than 10 MiB/s, which is a very long time compared to the boot time of ~10 secodns for the device). The other things; low power modes etc, aren't actually "suspension states" but rather related to CPU scheduling and the CPU's power management etc. If there is good support for the processor in the Kernel (and I know there is), such power features like those you mentioned should work transparently and seamlessly.
3. Suspend-to-disk: 0 W, nada, nihil, in theory at least. Suspend-to-RAM: less than you will ever have the need to have. If we can extrapolate the usual estimates, I'd say that suspend-to-RAM would keep the device alive for at least a month. At least. And in today's modern society, who is really away from a power adapter for longer than that?
4. From RAM: instantaneously, or near enough. From disk: at least 25 seconds if you use all of your RAM, as I said.
5. Why would suspend corrupt your SD cards? Suspend-to-RAM is compeltely unrelated to your SD cards, so it can't destroy anything, and suspend-to-disk is a fairly safe operation (aka doesn't corrupt your SDs 99.9999% of the time) most of the time if you decide to use it for some reason.
6. Dunno.
7. There's been talk about this, and the general atmosphere was fairly optimistic.

 

[aliking]

Thanks dflemtr, there's some good information here.

My question was more "Does suspend work?" than "Will suspend work?". Anyone else who owns an OLPC will understand why I'm not taking this for granted until I see it.

If devs have been using suspend-to-RAM thus far, great. I just asked because I'm hoping that someone has *actually* tested it and because it would really suck if it didn't work.

 

[valhalla]

Why would suspend corrupt your SD cards? Suspend-to-RAM is compeltely unrelated to your SD cards, so it can't destroy anything, and suspend-to-disk is a fairly safe operation (aka doesn't corrupt your SDs 99.9999% of the time) most of the time if you decide to use it for some reason.

A few months ago there was a thread on the kernel mailing list about a default kernel setting that could lead to filesystem corruption on removable block devices that were removed while the system was suspended; I don't know what happened meanwhile.

 

[torpor]

I'd rather the Pandora shell integrated cryopid somehow, so that processes could be checkpointed. This would make it possible to suspend -any- game/application and return to it at the exact same point later ..

 

[dflemstr]

I'd rather the Pandora shell integrated cryopid somehow, so that processes could be checkpointed. This would make it possible to suspend -any- game/application and return to it at the exact same point later ..

...provided that the SGX and BT drivers support process restoring, and provided that you'd ever want to freeze an application instead of just quitting it, thus having it eat RAM constantly without doing anything with it, or having it eat up space on your SD card and let it take 10 seconds to "unfreeze" again because it has to page in the stored pages into memory. Yeah. There's always two sides on a coin.

 

[bzar]

I'd rather the Pandora shell integrated cryopid somehow, so that processes could be checkpointed. This would make it possible to suspend -any- game/application and return to it at the exact same point later ..

How would this affect programs that depend on the system clock for tracking time? If, for instance my game relied on the system clock to tell my physics engine how much time has passed, would the whole world jerk a few hours at once when the game is resumed? I have no such game in the making, but I can see problems like this with your suggested approach.

 

[gruso]

How does the Nintendo DS do it? It's an awesome function. I won't be holding my breath for it on Pandora though.

 

[dflemstr]

How would this affect programs that depend on the system clock for tracking time? If, for instance my game relied on the system clock to tell my physics engine how much time has passed, would the whole world jerk a few hours at once when the game is resumed? I have no such game in the making, but I can see problems like this with your suggested approach.

The timer that most games use for timing isn't actually a system-wide timer, but an offset timer that specifies the time in milliseconds since the application started. It would thus be very easy to stop that timer when the application suspends.

@ Gruso: a feature similar to the DS thingie has been in the Kernel for ages (it even was in the Multics kernel I think, aka on the earilest machines known to man).
Just find the Process ID of a process you want to pause, type "kill -STOP <pid>" on a terminal and the application will be paused, and suspended. You can then type "kill -CONT <pid>" to resume the application. There are of course GUIs to do this with too; just open up the System Monitor in KDE and you have the ability to send signals to a process more easily, to pause it, resume it, hang it up, terminate it, interrupt it, etc. without using the misnamed "kill" command once.

 

[bzar]

How would this affect programs that depend on the system clock for tracking time? If, for instance my game relied on the system clock to tell my physics engine how much time has passed, would the whole world jerk a few hours at once when the game is resumed? I have no such game in the making, but I can see problems like this with your suggested approach.

The timer that most games use for timing isn't actually a system-wide timer, but an offset timer that specifies the time in milliseconds since the application started. It would thus be very easy to stop that timer when the application suspends.

Ok, so use clock() based solutions instead of time() or similar? That's nice to know. This would be a good thing to document in some developer FAQ if process freezing is used widely. I haven't dug very deep into the implementations of clock(), but does the timer generally stop when the process freezes? How can it be stopped? Or are you proposing applications to be aware when they get unfrozen and reset their internal counters to match the new processor time?

I like the idea of DS-like behavior with emulators and such

 

[dflemstr]

How would this affect programs that depend on the system clock for tracking time? If, for instance my game relied on the system clock to tell my physics engine how much time has passed, would the whole world jerk a few hours at once when the game is resumed? I have no such game in the making, but I can see problems like this with your suggested approach.

The timer that most games use for timing isn't actually a system-wide timer, but an offset timer that specifies the time in milliseconds since the application started. It would thus be very easy to stop that timer when the application suspends.

Ok, so use clock() based solutions instead of time() or similar? That's nice to know. This would be a good thing to document in some developer FAQ if process freezing is used widely. I haven't dug very deep into the implementations of clock(), but does the timer generally stop when the process freezes? How can it be stopped? Or are you proposing applications to be aware when they get unfrozen and reset their internal counters to match the new processor time?

I like the idea of DS-like behavior with emulators and such

Read my edit for info on how timers are suspended; basically, the Kernel does it automatically for you.

Also, no one in their right mind would use time() for games since it's horribly inaccurate (it can be up to 15 ms off) and only has a 1ms resolution, so I don't think that anyone is using it for games atm, ergo that shouldn't be a problem.

 

[torpor]

.. provided that you'd ever want to freeze an application instead of just quitting it, thus having it eat RAM constantly without doing anything with it, or having it eat up space on your SD card and let it take 10 seconds to "unfreeze" again because it has to page in the stored pages into memory. Yeah. There's always two sides on a coin.

Eh, big deal. It takes about 2 seconds to freeze a process to disk with cryopid, and it will stay there frozen forever, waiting to be restored. This is much better than having to wait for a full system suspend, shutdown, poweroff, poweron, boot, restore ..

Just find the Process ID of a process you want to pause, type "kill -STOP <pid>" on a terminal and the application will be paused, and suspended.

It will be 'suspended' in the sense that it is no longer running, but you can't reboot the system/poweroff and expect to be able to resume such processes. With a cryopid/checkpoint scheme, the system can be completely powered down and resumed at any time in the future .. with the advantage that a frozen process can even be moved to another machine and restarted. Imagine being able to do game-saves without the game needing to support them ..

 

[dflemstr]

.. provided that you'd ever want to freeze an application instead of just quitting it, thus having it eat RAM constantly without doing anything with it, or having it eat up space on your SD card and let it take 10 seconds to "unfreeze" again because it has to page in the stored pages into memory. Yeah. There's always two sides on a coin.

Eh, big deal. It takes about 2 seconds to freeze a process to disk with cryopid, and it will stay there frozen forever, waiting to be restored. This is much better than having to wait for a full system suspend, shutdown, poweroff, poweron, boot, restore ..

Just find the Process ID of a process you want to pause, type "kill -STOP <pid>" on a terminal and the application will be paused, and suspended.

It will be 'suspended' in the sense that it is no longer running, but you can't reboot the system/poweroff and expect to be able to resume such processes. With a cryopid/checkpoint scheme, the system can be completely powered down and resumed at any time in the future .. with the advantage that a frozen process can even be moved to another machine and restarted. Imagine being able to do game-saves without the game needing to support them ..

If you can live with up to 256 MiB save files, then sure, I guess...

 

[torpor]

If you can live with up to 256 MiB save files, then sure, I guess...

My Pandora will have 2x32gig SD cards in it .. so .. yeah .. no problems there, even though I highly doubt we're going to have any apps that consume a full 256megs and anyway such a limit won't really be possible, will it.. and even if we get ~200meg frozen apps, the shell thats doing the freezing/unfreezing can just as easily add a gzip/gunzip stage to the pipeline. No sweat whatsoever.

 

[rabidpoobear]

How does the Nintendo DS do it? It's an awesome function. I won't be holding my breath for it on Pandora though.

On the DS, it just sends the lid sensor to a game, and the game is expected to handle shutting down of hardware. That's why Animal Crossing continues to run, where some games will pause. And some homebrew won't turn off the LCD when you close the lid.

 

[Sphinxter]

Don't panic, all is within your grasp. Write two scripts after figuring out which drivers are not re-entrant, one to remove those on suspend and another to add them back on wake-up. I'd like to think I can get that boot time down to < 15 seconds. To me it appears we are looking at init doing it's usual sloth-like one step at at time start up sequence rather than quickinit doing a parallel boot sequence according to it's needs and provides. Can someone confirm that suspicion?