[Testers?] Suspend/Resume MDs....

[jondecker76]

I still haven't had time to test this out yet (been extremely busy) - but it is a needed feature.

I agree that suspend to disk isn't a great option as a good percentage of users will have diskless MD's. I understand that it would be easier to implement, but it wouldn't be as good for our purposes as suspend to RAM. I hope you keep plugging away at it - I think we all know what its like to feel like we are chasing our tails around in circles sometimes

[tschak909]

No. Suspend to Ram will work, with well supported hardware.

But again, You don't have to prove me wrong. Just implement what you feel is right.



-Thom

[totallymaxed]

Great, OK, so focusing on suspend to disk, what do you think we need to do to add this into 0810? Are we confident enough of all the config and script files working on most platforms that this can be just static files added to the installation process? Also, has s2ram been added back into hibernate/uswsusp in 0810 or do we need to compile a version (like we did manually) and add it to the build?

Especially for MDs, I do not think focusing on suspend to disk is such a grand idea. All my MDs are (going to be) diskless.

I agree, but as you can see from the thread, there are specific hardware issues particular to chipsets that cause s2ram to fail or fail if the right options are not specified... dunno how we can code for this as it seems to be a black art getting the right options for your specific hardware. I thought if we can get s2disk working reliably, s2ram can be bolted on afterwards by presenting the options to choose from based on the fact that the underlying suspend functionality works at least for s2disk.... what do you think?

Sambucca - forgot to ask, have you checked leaving your MD suspended for at least a day and then resuming? Just want to be sure that this mechanism genuinely deals with the TCP connections issues, and there isn't something else we need to cover as well.

I tend to agree Colin that suspend to RAM is really what we need...we are moving strongly to diskless MD's wherever possible.

Andrew

[colinjones]

Great, OK, so focusing on suspend to disk, what do you think we need to do to add this into 0810? Are we confident enough of all the config and script files working on most platforms that this can be just static files added to the installation process? Also, has s2ram been added back into hibernate/uswsusp in 0810 or do we need to compile a version (like we did manually) and add it to the build?

Especially for MDs, I do not think focusing on suspend to disk is such a grand idea. All my MDs are (going to be) diskless.

I agree, but as you can see from the thread, there are specific hardware issues particular to chipsets that cause s2ram to fail or fail if the right options are not specified... dunno how we can code for this as it seems to be a black art getting the right options for your specific hardware. I thought if we can get s2disk working reliably, s2ram can be bolted on afterwards by presenting the options to choose from based on the fact that the underlying suspend functionality works at least for s2disk.... what do you think?

Sambucca - forgot to ask, have you checked leaving your MD suspended for at least a day and then resuming? Just want to be sure that this mechanism genuinely deals with the TCP connections issues, and there isn't something else we need to cover as well.

I tend to agree Colin that suspend to RAM is really what we need...we are moving strongly to diskless MD's wherever possible.

Andrew

I don't think anybody actually read my post, let me repeat it!!

I agree, but as you can see from the thread, there are specific hardware issues particular to chipsets that cause s2ram to fail or fail if the right options are not specified... dunno how we can code for this as it seems to be a black art getting the right options for your specific hardware. I thought if we can get s2disk working reliably, s2ram can be bolted on afterwards by presenting the options to choose from based on the fact that the underlying suspend functionality works at least for s2disk.... what do you think?

Sambucca - forgot to ask, have you checked leaving your MD suspended for at least a day and then resuming? Just want to be sure that this mechanism genuinely deals with the TCP connections issues, and there isn't something else we need to cover as well.

I never suggested that Suspend to Disk should be the solution... just that getting the overall mechanism to work with it would be easier. Once we had proved that that works, then expand the options to Suspend to RAM by exposing the s2ram configuration options so that the user can choose which ones they think are appropriate for their hardware. I don't know of any other way of progressing unless 0810 kernel has recently worked magic in making s2ram work reliably across different hardware. Certainly it is useless to me, I don't have a disk in my MD, and want to avoid putting one in. Potential false economy anyway - having to run a disk when one isn't otherwise needed to save power?! No, I've no idea where to go now... I cannot get suspend to RAM working on my MSI Wind PC, the only options for different hardware I found were in that s2ram config file and I have tried all those - one caused some kind of oops/panic and backtrace on resume, all the other combinations just hung on resume... are there any more reliable s2ram alternatives to uswsusp/hibernate/s2ram?

[tschak909]

my bad. I owe you a beer.

-Thom

[colinjones]

my bad. I owe you a beer.

-Thom

I'm reeeealy thirsty, can you fedex it?

[sambuca]

Colin, have not yet tried leaving the MD off for some time. But it is suspended at this moment, so when get back home today, I can resume it to check it. Not that I think it will be a problem, as all devices are restarted the normal way.

I think that these scripts are good for *both* suspend to ram and to disk. LMCE does not need to take any special precautions with regards to suspending and resuming other than what your script already does. It is the suspend scripts' responsibility to make sure the specific hardware works after resume, not LMCE!

However, it is a fact that not all hardware works reliable with suspend/resume. But this is constantly improving.
And I think we all agree that suspend to ram is the ideal solution.

There are also other options to suspend/resume. I think ACPI has some support and also pm-utils do suspend/resume, although pm-utils seems to use s2disk/s2ram in the background. I think pm-utils are the standard in 810. So we need to adapt the scripts to using that, see http://en.opensuse.org/Pm-utils. The hook scripts are a bit different, but a no-brainer to change.

As for how to integrate it in LMCE, I am not sure. But couldn't we just add support for both disk and ram suspension? Lets say I install ubuntu on a random computer, then try to supend it. It will either work or not. The same with LinuxMCE. What do you think? At least we should provide the scripts necessary to do LinuxMCE specific stuff (colin's script), and then users with enough know-how can enable them.

br,
sambuca

[gollywog]

Could the suspend do disk happen to a CF or flash drive of some description? Still boot of the net but when suspending write appropriate stuff to a (maybe usb attached??) drive?

I don't know much about this so just a sugestion. If it's dumb just ignore

Gollywog

[sambuca]

gollywog,

I am using a CF disk to suspend at this moment. It works fine, only problem is that LMCE tries to use it as swap, which would be a bad, as CF cards have limited write cycles.

br,
sambuca

[sambuca]

Colin, I just resumed my MD, suspended from yesterday (~24h), and everything works perfectly. I use the addition to your script that I posted previously.

sambuca

[jondecker76]

sambuca - can you post a speed comparison of booting from the lan and resuming from suspend?

[sambuca]

I can give you a rough estimate right away.
I know from previous tests that normal lan boot takes around 2 minutes. This is on a 100MBit lan, via a gigabit switch to the gigabit card in the core.
I actually did a rough count of seconds for resume from disk yesterday, and I think it ended up around half a minute. So its quite an improvement, and do note that this is suspend to disk. Suspend to ram should be even quicker. I remember that it resumed in 3-4 seconds with 704, but you'll have to also add in the time that the launch manager and devices take to start up.

I'll see it I can do a more thorough test one of these days.

sambuca

[chriss]

In my experience the performance of the disk and the size of the RAM are important factors when doing s2disk. On my WinXP laptop with 2GB RAM and a very slow 1.8" HDD the resume takes about 2min where ~95% of the time are required to read back the memory image from disk.

br,
/chriss

[sambuca]

Hi again,

I timed the resume process today, and I must admit, I don't know what I timed the last time. It certainly was not the resume... Now I measured it to about 1 minute in resume from disk. 25 seconds of those are spent reading from disk (512MB memory), and 15 is the normal BIOS boot, which leaves 20 seconds that lmce uses to start up again.
The time for lmce restart is ofcourse depending on how many devices you have (and what devices).

On the other hand, I tried pm-utils today, and got my MD to suspend to RAM.  I also read that pm-utils uses the HAL database to find out what stuff to do when suspending/resuming, which would mean that it supports more configurations easier.
So I timed the pm-utils suspend to ram and got these times:
(It used 30 seconds to turn off, not that it matters very much)

00 power on
09 lmce launch manager started
18 Orbiter started
30 all devices started, complete
= 30 seconds to resume

So, I would definitely recommend pm-utils. Remember, this is the standard in Ubuntu 810.

br,
samuca

[colinjones]

sambucca - care to outline what config you changed to use pm-utils instead of hibernate-ram/s2disk?

Also, I would be interested in what device is causing your suspend to take so long... are you using VDR? That device takes ages (~15s) to shutdown on my MD whereas all the other devices take ~2 secs. If you hibernate-ram from the command line, I believe there are still echo's in there that print the number of outstanding devices... also you can keep hitting refresh on the children devices of the MD and see which one still says Registered: Yes, that will be the one that slows it down. I realise that the suspend isn't the one we are interested in for speed, but its still worth knowing...