suspend and hibernate nomenclature

suspend and hibernate nomenclature

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

First, sorry for the random mail to this mailing list.

I'm the developer of gnome-power-manager. The latest mini-project of
mine is to fix the suspend-hibernate nomenclature used by OSS projects.

This might not effect the lowest layers of the stack (i.e. I want to
focus on the stuff used by *users*), so this might not be applicable to
you guys. Please keep me cc'd if you discuss, as I'm not subscribed to
this list.

Full description of the problem is here:
http://live.gnome.org/GnomePowerManager/SleepNames and I would encourage
you guys to add comments to the end of the wiki if required.

Thanks for your time,

Richard Hughes


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Jordan Crouse]

[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

On 07/05/06 19:02 +0100, Richard Hughes wrote:
> First, sorry for the random mail to this mailing list.
> 
> I'm the developer of gnome-power-manager. The latest mini-project of
> mine is to fix the suspend-hibernate nomenclature used by OSS projects.
> 
> This might not effect the lowest layers of the stack (i.e. I want to
> focus on the stuff used by *users*), so this might not be applicable to
> you guys. 

I would say thats probably a pretty accurate assessment.  Since you are a GUI
developer, you can tell the users whatever you want, and you can translate
under the scenes.  In that case, using terms like "hibernate" makes perfect 
sense.

But at the lower level, I favor a more clinical terminology, because it
reduces confusion amongst system developers. Thats not to say that our 
current terminology is sane, (because it isn't), but I would far prefer
precise numbers over vague synonyms for sleeping. :)

*Our* task, as I see it, is to make sure that the underlying descriptions
are intelligent and persistent, so *you* don't have to change your 
application every time something a new kernel is released.  But as soon as
we've figured that out, then it will be no thing for you to take an
"hibernate" from the top end, and turn it into the right term for the kernel.

Regards,
Jordan

--
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]

On Mon, 2006-05-08 at 09:05 -0600, Jordan Crouse wrote:
> On 07/05/06 19:02 +0100, Richard Hughes wrote:
> > First, sorry for the random mail to this mailing list.
> > 
> > I'm the developer of gnome-power-manager. The latest mini-project of
> > mine is to fix the suspend-hibernate nomenclature used by OSS projects.
> > 
> > This might not effect the lowest layers of the stack (i.e. I want to
> > focus on the stuff used by *users*), so this might not be applicable to
> > you guys. 
> 
> I would say thats probably a pretty accurate assessment.  Since you are a GUI
> developer, you can tell the users whatever you want, and you can translate
> under the scenes.  In that case, using terms like "hibernate" makes perfect 
> sense.

Sure, agreed.

> But at the lower level, I favor a more clinical terminology, because it
> reduces confusion amongst system developers. Thats not to say that our 
> current terminology is sane, (because it isn't), but I would far prefer
> precise numbers over vague synonyms for sleeping. :)

Up to you guys :-)

> *Our* task, as I see it, is to make sure that the underlying descriptions
> are intelligent and persistent, so *you* don't have to change your 
> application every time something a new kernel is released.  But as soon as
> we've figured that out, then it will be no thing for you to take an
> "hibernate" from the top end, and turn it into the right term for the kernel.

Sure, I totally agree the user shouldn't know about any of this stuff,
but I thought I should bring the website to your attention to keep you
guys in the loop with GUI users... :-)

Anyway, thanks for this mail, feedback has been great so far.

Richard.


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

Hi!

> First, sorry for the random mail to this mailing list.
> 
> I'm the developer of gnome-power-manager. The latest mini-project of
> mine is to fix the suspend-hibernate nomenclature used by OSS projects.
> 
> This might not effect the lowest layers of the stack (i.e. I want to
> focus on the stuff used by *users*), so this might not be applicable to
> you guys. Please keep me cc'd if you discuss, as I'm not subscribed to
> this list.
> 
> Full description of the problem is here:
> http://live.gnome.org/GnomePowerManager/SleepNames and I would encourage
> you guys to add comments to the end of the wiki if required.

Please do not use word 'thaw'. We already freeze processes during
suspend, and we thaw them during resume.
							Pavel

-- 
Thanks for all the (sleeping) penguins.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

On Mon, 2006-05-08 at 20:01 +0000, Pavel Machek wrote:
> Hi!
> 
> > First, sorry for the random mail to this mailing list.
> > 
> > I'm the developer of gnome-power-manager. The latest mini-project of
> > mine is to fix the suspend-hibernate nomenclature used by OSS projects.
> > 
> > This might not effect the lowest layers of the stack (i.e. I want to
> > focus on the stuff used by *users*), so this might not be applicable to
> > you guys. Please keep me cc'd if you discuss, as I'm not subscribed to
> > this list.
> > 
> > Full description of the problem is here:
> > http://live.gnome.org/GnomePowerManager/SleepNames and I would encourage
> > you guys to add comments to the end of the wiki if required.
> 
> Please do not use word 'thaw'. We already freeze processes during
> suspend, and we thaw them during resume.

Got any better ideas? It needs to *just* apply to hibernation, not a
generic term like wake.

Richard.



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On Ne 14-05-06 16:32:24, Richard Hughes wrote:
> On Mon, 2006-05-08 at 20:01 +0000, Pavel Machek wrote:
> > Hi!
> > 
> > > First, sorry for the random mail to this mailing list.
> > > 
> > > I'm the developer of gnome-power-manager. The latest mini-project of
> > > mine is to fix the suspend-hibernate nomenclature used by OSS projects.
> > > 
> > > This might not effect the lowest layers of the stack (i.e. I want to
> > > focus on the stuff used by *users*), so this might not be applicable to
> > > you guys. Please keep me cc'd if you discuss, as I'm not subscribed to
> > > this list.
> > > 
> > > Full description of the problem is here:
> > > http://live.gnome.org/GnomePowerManager/SleepNames and I would encourage
> > > you guys to add comments to the end of the wiki if required.
> > 
> > Please do not use word 'thaw'. We already freeze processes during
> > suspend, and we thaw them during resume.
> 
> Got any better ideas? It needs to *just* apply to hibernation, not a
> generic term like wake.

reanimate?  As you said, users are unlikely to see this one.

Alternatives:

dehibarnate (unhibernate?), resume-from-disk :-), ressurect,
resuscitate (particulary useful if s-2-disk is buggy :-), revive, ...


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Rafael J. Wysocki]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Sunday 14 May 2006 17:39, Pavel Machek wrote:
> On Ne 14-05-06 16:32:24, Richard Hughes wrote:
> > On Mon, 2006-05-08 at 20:01 +0000, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > First, sorry for the random mail to this mailing list.
> > > > 
> > > > I'm the developer of gnome-power-manager. The latest mini-project of
> > > > mine is to fix the suspend-hibernate nomenclature used by OSS projects.
> > > > 
> > > > This might not effect the lowest layers of the stack (i.e. I want to
> > > > focus on the stuff used by *users*), so this might not be applicable to
> > > > you guys. Please keep me cc'd if you discuss, as I'm not subscribed to
> > > > this list.
> > > > 
> > > > Full description of the problem is here:
> > > > http://live.gnome.org/GnomePowerManager/SleepNames and I would encourage
> > > > you guys to add comments to the end of the wiki if required.
> > > 
> > > Please do not use word 'thaw'. We already freeze processes during
> > > suspend, and we thaw them during resume.
> > 
> > Got any better ideas? It needs to *just* apply to hibernation, not a
> > generic term like wake.
> 
> reanimate?  As you said, users are unlikely to see this one.
> 
> Alternatives:
> 
> dehibarnate (unhibernate?), resume-from-disk :-), ressurect,
> resuscitate (particulary useful if s-2-disk is buggy :-), revive, ...

Maybe "wake up"? :-)

Rafael

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

One thing that doesn't seem right at all:  you suggest using the same
name for the "standby" and "suspend to RAM" states.  Those are both
different types of "suspend" states, as distinct from "hibernate"/swsusp
states (which are types of power-off).

That wiki page has an assertion that both "standby" and "suspend-to-RAM"
are bad names.  Maybe; but they're also the names that MS-Windows users have
been trained to expect, so fighting against them (and hiding them even in
explanations) isn't necessarily good.

But they are still distinctly different states, and if you don't expose
both of them to users, then you'd be effectively preventing use of one
of the two states.  And if power savings is a goal, that's ungood.  On
embedded systems, there are lots of variants of "standby", and analogues
of "suspend to RAM" can be hard to enter.

One suggestion might be to talk about how deeply the system is suspended;
"light suspend" (standby) or "deep suspend" (suspend-to-RAM).  That could
work well with the non-PC/non-ACPI/non-ACPI type of systems too, where
there may well be several more types of "suspend" state than just those
two, and no analague of "hibernate".  (Noted also by Scott Preece...)

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]

On Mon, 2006-05-08 at 16:47 -0700, David Brownell wrote:
> One thing that doesn't seem right at all:  you suggest using the same
> name for the "standby" and "suspend to RAM" states.  Those are both
> different types of "suspend" states, as distinct from "hibernate"/swsusp
> states (which are types of power-off).

Well sort of. I was trying to explain that standby and suspend-to-ram
are similar enough for the user not to worry about the differences.

My point mainly was that standby is a bad name for suspend-to-ram, which
a few users and vendors have suggested, as it's different, and has been
used differently for ACPI.

> That wiki page has an assertion that both "standby" and "suspend-to-RAM"
> are bad names.  Maybe; but they're also the names that MS-Windows users have
> been trained to expect, so fighting against them (and hiding them even in
> explanations) isn't necessarily good.

Apple have different names too.

> But they are still distinctly different states, and if you don't expose
> both of them to users, then you'd be effectively preventing use of one
> of the two states.  And if power savings is a goal, that's ungood.  On
> embedded systems, there are lots of variants of "standby", and analogues
> of "suspend to RAM" can be hard to enter.

Ohh, standby exists, but I don't think a user needs to understand this
(or use this -- see below) in a desktop context.

> One suggestion might be to talk about how deeply the system is suspended;
> "light suspend" (standby) or "deep suspend" (suspend-to-RAM).  That could
> work well with the non-PC/non-ACPI/non-ACPI type of systems too, where
> there may well be several more types of "suspend" state than just those
> two, and no analague of "hibernate".  (Noted also by Scott Preece...)

At the moment I'm aiming the nomenclature at people using acpi, pmu, apm
etc on a desktop platform, rather than embedded people as the
requirements are very different. Think of just getting KDE and GNOME to
agree on something. :-)

For embedded (I'm guessing here), the use of standby for a super-quick
sleep and the use of suspend-x where x = 1-4 for the different states
may be needed, but at the moment I think the desktop user has enough to
understand.

If you guys used a sleep name in the kernel
sleep_for_not_longer_than_6_minutes_but_more_that_2_seconds() I really
don't mind -- but if the user has to click a button, I would rather the
button was marked suspend or hibernate :-)

Thanks for your comments.

Richard.



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

On Tuesday 09 May 2006 12:38 am, Richard Hughes wrote:
> Ohh, standby exists, but I don't think a user needs to understand this
> (or use this -- see below) in a desktop context.

I don't think I saw a real explanation for that "below".  You implied
that "standby" was mostly meaningful for embedded hardware; not so.

If the state is there and used, users will be aware of the distinction
between the two suspend states ("standby" and "suspend to RAM").  One
is quick to enter/exit, the other isn't.

Of course what I _would_ like to see is Linux distros that autosuspend,
entering "standby" after they're idle for a while and then, if they're
not woken up quickly enough, entering "suspend-to-RAM".  No point in
having laptops burn all that energy all the time, after all ... or
automagically inflicting long resume-from-STR latencies on them.

Admittedly we do have issues getting either of those states to work
lately in Linux, but at least "standby" should be trivial given even
a small fraction of the effort that's gone into swsusp/"hibernate".


> If you guys used a sleep name in the kernel
> sleep_for_not_longer_than_6_minutes_but_more_that_2_seconds() I really
> don't mind -- but if the user has to click a button, I would rather the
> button was marked suspend or hibernate :-)

Well "not_longer_yadda_yadda()" would be a bizarre model.  The user-visible
issue is the latency to suspend or resume ... where "standby" is quick, and
"suspend-to-RAM" is relatively slow.  Where "quick" is on the order of time
for users to finish switching their mental context, while "slow" is on the
order of doing that _plus_ doing something else to fill the wait time.  How
long the system stays in a given suspend state is immaterial to any issue
beyond how much power is saved.  (Which is only indirectly user visible,
e.g. stretching battery life out one more hour vs eight more.)

The "suspend" button could be more menu-like, and users could choose to
override whatever their default "suspend depth" is ... and set the default
to match their impatience (vs power savings).

- Dave




[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

Hi!

> Of course what I _would_ like to see is Linux distros that autosuspend,
> entering "standby" after they're idle for a while and then, if they're
> not woken up quickly enough, entering "suspend-to-RAM".  No point in
> having laptops burn all that energy all the time, after all ... or
> automagically inflicting long resume-from-STR latencies on them.

Actually, it is quite hard to decide when it is okay to suspend
machine. You do not want it to fall asleep during compilation/cd
burning/download.

> > If you guys used a sleep name in the kernel
> > sleep_for_not_longer_than_6_minutes_but_more_that_2_seconds() I really
> > don't mind -- but if the user has to click a button, I would rather the
> > button was marked suspend or hibernate :-)
> 
> Well "not_longer_yadda_yadda()" would be a bizarre model.  The user-visible
> issue is the latency to suspend or resume ... where "standby" is quick, and
> "suspend-to-RAM" is relatively slow.  Where "quick" is on the order of time
> for users to finish switching their mental context, while "slow" is on the
> order of doing that _plus_ doing something else to fill the wait time.  How
> long the system stays in a given suspend state is immaterial to any issue
> beyond how much power is saved.  (Which is only indirectly user visible,
> e.g. stretching battery life out one more hour vs eight more.)

Well, entering/exiting s2ram eats more power than idle; so if you expect to
sleep 4 seconds, it is probably best to do nothing, maybe enter
standby if you are fast.

4sec idle: 4 sec at 10W
4sec s2ram: 2 sec entering s2ram at 15W, 0 sec sleep, 2 sec exiting
s2ram at 15W. bad
4sec standby: 1sec enter standby at 15W, 2 sec sleep at 5W, 1 sec exit
standby at 15W

							Pavel
-- 
Thanks for all the (sleeping) penguins.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]

On Tuesday 16 May 2006 1:40 pm, Pavel Machek wrote:
> Hi!
> 
> > Of course what I _would_ like to see is Linux distros that autosuspend,
> > entering "standby" after they're idle for a while and then, if they're
> > not woken up quickly enough, entering "suspend-to-RAM".  No point in
> > having laptops burn all that energy all the time, after all ... or
> > automagically inflicting long resume-from-STR latencies on them.
> 
> Actually, it is quite hard to decide when it is okay to suspend
> machine. You do not want it to fall asleep during compilation/cd
> burning/download.

Any "is the system idle" test that ignores high cpu or block i/o
loads is obviously buggy ... but that's easy enough, even those little
system monitors in X11 can get that right.  And if they get it wrong,
things would wake up right away.  (The X11 server is a good example
of the worst case.  Mine often ignores mouse and keyboard events, and
will do things like kicking in the screen saver while I'm paging through
a document ... it comes right back, but it's _very_ annoying.)

As for downloading, that's why ethernet adapters have wake-on-lan (WOL)
mechanisms.  Likewise for other wakeup-capable devices, like a keyboard
or mouse.  Or even 3D engines, DSPs, SPUs, ...


> > > If you guys used a sleep name in the kernel
> > > sleep_for_not_longer_than_6_minutes_but_more_that_2_seconds() I really
> > > don't mind -- but if the user has to click a button, I would rather the
> > > button was marked suspend or hibernate :-)
> > 
> > Well "not_longer_yadda_yadda()" would be a bizarre model.  The user-visible
> > issue is the latency to suspend or resume ... where "standby" is quick, and
> > "suspend-to-RAM" is relatively slow. ...)
> 
> Well, entering/exiting s2ram eats more power than idle; so if you expect to
> sleep 4 seconds, it is probably best to do nothing, maybe enter
> standby if you are fast.

Yes.  Those policy decisions are appopriate for userspace though,
NOT for a kernelspace "not_longer_yadda_yadda()" API call.

Are these numbers you sent real ones?  For what computer system?
I _might_ have one system to which they apply, but 10W "idle" system
power seem either way too high (by at least two orders of magnitude!)
or pretty low (for many current x86 systems).

Linux could optimize the process of entering/exiting system sleep
states, if that starts mattering much.  For true suspend states, that
mostly means suspending drivers, which ought to be cheap when the
system is already idle enough that autosuspend could kick in.

- Dave


> 4sec idle: 4 sec at 10W
>
> 4sec s2ram: 2 sec entering s2ram at 15W, 0 sec sleep, 2 sec exiting
> s2ram at 15W. bad
>
> 4sec standby: 1sec enter standby at 15W, 2 sec sleep at 5W, 1 sec exit
> standby at 15W

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 3007 bytes --]

Hi!

> > > Of course what I _would_ like to see is Linux distros that autosuspend,
> > > entering "standby" after they're idle for a while and then, if they're
> > > not woken up quickly enough, entering "suspend-to-RAM".  No point in
> > > having laptops burn all that energy all the time, after all ... or
> > > automagically inflicting long resume-from-STR latencies on them.
> > 
> > Actually, it is quite hard to decide when it is okay to suspend
> > machine. You do not want it to fall asleep during compilation/cd
> > burning/download.
> 
> Any "is the system idle" test that ignores high cpu or block i/o
> loads is obviously buggy ... but that's easy enough, even those little
> system monitors in X11 can get that right.  And if they get it wrong,
> things would wake up right away.  (The X11 server is a good example

Well, will it ever go to sleep? In such case? There are many things
that wake up periodically.

> As for downloading, that's why ethernet adapters have wake-on-lan (WOL)
> mechanisms.  Likewise for other wakeup-capable devices, like a keyboard
> or mouse.  Or even 3D engines, DSPs, SPUs, ...

?? WOL is for different functionality, I'm afraid. Or do you know
ethernet hub that automagically wakes machines when data come?


> > > > If you guys used a sleep name in the kernel
> > > > sleep_for_not_longer_than_6_minutes_but_more_that_2_seconds() I really
> > > > don't mind -- but if the user has to click a button, I would rather the
> > > > button was marked suspend or hibernate :-)
> > > 
> > > Well "not_longer_yadda_yadda()" would be a bizarre model.  The user-visible
> > > issue is the latency to suspend or resume ... where "standby" is quick, and
> > > "suspend-to-RAM" is relatively slow. ...)
> > 
> > Well, entering/exiting s2ram eats more power than idle; so if you expect to
> > sleep 4 seconds, it is probably best to do nothing, maybe enter
> > standby if you are fast.
> 
> Yes.  Those policy decisions are appopriate for userspace though,
> NOT for a kernelspace "not_longer_yadda_yadda()" API call.

Agreed.

> Are these numbers you sent real ones?  For what computer system?

Well.. no, they are guesses...

> I _might_ have one system to which they apply, but 10W "idle" system
> power seem either way too high (by at least two orders of magnitude!)
> or pretty low (for many current x86 systems).

..based on thinkpad x32 notebook. 10W in idle is pretty much okay,
sleep is around 3W IIRC (linux sucks here), and full cpu load at
minimum speed is 13W... so I was not *that* off.

> Linux could optimize the process of entering/exiting system sleep
> states, if that starts mattering much.  For true suspend states, that
> mostly means suspending drivers, which ought to be cheap when the
> system is already idle enough that autosuspend could kick in.

Yep, you are right, taht was just for ilustration.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On Thursday 18 May 2006 1:50 pm, Pavel Machek wrote:

> Well, will it ever go to sleep? In such case? There are many things
> that wake up periodically.

Applications that constantly wake/poll are death to power management anyway,
that's not news ... most of the "work" done by polling is wasted.  When they
get switched to no-timeout/blocking APIs, then they can sleep painlessly
until a relevant wakeup event triggers.

Things that really *must* wake up periodically should be using some API that
interacts with RTC alarms, and those RTC alarms should be acting as system
wakeup events.


There's also non-automated sleep too ... what "apmsleep" used to do when
you told it to suspend until 7am (or for two hours, etc).  The same thing
can be done with /sys/power/state and a wakeup-enabled RTC.


> > As for downloading, that's why ethernet adapters have wake-on-lan (WOL)
> > mechanisms.  Likewise for other wakeup-capable devices, like a keyboard
> > or mouse.  Or even 3D engines, DSPs, SPUs, ...
> 
> ?? WOL is for different functionality, I'm afraid. Or do you know
> ethernet hub that automagically wakes machines when data come?

No, that's exactly what WOL is designed for.  A typical scenarios has
the adapter waking up when the incoming packet is unicast to the MAC
address of that host.  The hub/switch would act normally.

- Dave

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

On Čt 18-05-06 19:25:29, David Brownell wrote:
> On Thursday 18 May 2006 1:50 pm, Pavel Machek wrote:
> 
> > Well, will it ever go to sleep? In such case? There are many things
> > that wake up periodically.
> 
> Applications that constantly wake/poll are death to power management anyway,
> that's not news ... most of the "work" done by polling is wasted.  When they
> get switched to no-timeout/blocking APIs, then they can sleep painlessly
> until a relevant wakeup event triggers.

Well, that is not how X app currently work :-(.

> Things that really *must* wake up periodically should be using some API that
> interacts with RTC alarms, and those RTC alarms should be acting as system
> wakeup events.

But that means completely rewriting userspace.

> There's also non-automated sleep too ... what "apmsleep" used to do when
> you told it to suspend until 7am (or for two hours, etc).  The same thing
> can be done with /sys/power/state and a wakeup-enabled RTC.

Yep, I should get it working one day.

> > > As for downloading, that's why ethernet adapters have wake-on-lan (WOL)
> > > mechanisms.  Likewise for other wakeup-capable devices, like a keyboard
> > > or mouse.  Or even 3D engines, DSPs, SPUs, ...
> > 
> > ?? WOL is for different functionality, I'm afraid. Or do you know
> > ethernet hub that automagically wakes machines when data come?
> 
> No, that's exactly what WOL is designed for.  A typical scenarios has
> the adapter waking up when the incoming packet is unicast to the MAC
> address of that host.  The hub/switch would act normally.

I do not think WOL wakes that way. IIRC it needs magic ethernet
packet.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1194 bytes --]

On Sat, 20 May 2006, Pavel Machek wrote:

> > > > As for downloading, that's why ethernet adapters have wake-on-lan (WOL)
> > > > mechanisms.  Likewise for other wakeup-capable devices, like a keyboard
> > > > or mouse.  Or even 3D engines, DSPs, SPUs, ...
> > > 
> > > ?? WOL is for different functionality, I'm afraid. Or do you know
> > > ethernet hub that automagically wakes machines when data come?
> > 
> > No, that's exactly what WOL is designed for.  A typical scenarios has
> > the adapter waking up when the incoming packet is unicast to the MAC
> > address of that host.  The hub/switch would act normally.
> 
> I do not think WOL wakes that way. IIRC it needs magic ethernet
> packet.

That's right.  I don't remember what the contents need to be, but WOL 
doesn't work with any old ethernet packet.

You can see this by looking closely at what Dave wrote: "... the incoming
packet is unicast to the MAC address of that host."  If the host has been
asleep for some time, its MAC address will have timed out from the
source's ARP cache.  The source will need to broadcast an ARP request
packet before it can unicast anything, and the broadcast won't wake up the 
host.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 2825 bytes --]

On Saturday 20 May 2006 12:23 pm, Alan Stern wrote:
> On Sat, 20 May 2006, Pavel Machek wrote:
> 
> > > > > As for downloading, that's why ethernet adapters have wake-on-lan (WOL)
> > > > > mechanisms.  Likewise for other wakeup-capable devices, like a keyboard
> > > > > or mouse.  Or even 3D engines, DSPs, SPUs, ...
> > > > 
> > > > ?? WOL is for different functionality, I'm afraid. Or do you know
> > > > ethernet hub that automagically wakes machines when data come?
> > > 
> > > No, that's exactly what WOL is designed for.  A typical scenarios has
> > > the adapter waking up when the incoming packet is unicast to the MAC
> > > address of that host.  The hub/switch would act normally.
> > 
> > I do not think WOL wakes that way. IIRC it needs magic ethernet
> > packet.
> 
> That's right.  I don't remember what the contents need to be, but WOL 
> doesn't work with any old ethernet packet.

You're both wrong.  Notice what "man ethtool" reports:

       wol p|u|m|b|a|g|s|d...
              Set Wake-on-LAN options.  Not all devices support this.  The argument to this
              option is a string of characters specifying which options to enable.

              p  Wake on phy activity
              u  Wake on unicast messages
              m  Wake on multicast messages
              b  Wake on broadcast messages
              a  Wake on ARP
              g  Wake on MagicPacket(tm)
              s  Enable SecureOn(tm) password for MagicPacket(tm)
              d  Disable (wake on nothing).  This option clears all previous options.

It does not "need" MagicPacket; not all hardware supports it.  On hardware that
does support it, you aren't forced to use it.  (MagicPacket is nice for certain
kinds of remote administration.)

A brief survey of some Ethernet-equipped Linux hardware I see right now:

 - RTL 8139, supports pumbg
 - SIS 900, supports pg
 - at91rm9200 (arm920), supports pumb (in hardware, from "standby", but
   its Linux driver doesn't handle it yet)


> You can see this by looking closely at what Dave wrote: "... the incoming
> packet is unicast to the MAC address of that host."  If the host has been
> asleep for some time, its MAC address will have timed out from the
> source's ARP cache.  The source will need to broadcast an ARP request
> packet before it can unicast anything, and the broadcast won't wake up the 
> host.

Well, controllers may wake on ARP too.  And if a download is active, then
it's likely that the ARP cache won't be timing out ... and even if it did
time out, some networks use proxy ARP or persisten ARP cache entries, so
using ARP is not always necessary.

Point being as I said:  that WOL helps address that problem.  As always,
if you need particular hardware capabilities (like wake-on-unicast) you
need to make sure your hardware has them.

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]

Hi!

> > > > > ?? WOL is for different functionality, I'm afraid. Or do you know
> > > > > ethernet hub that automagically wakes machines when data come?
> > > > 
> > > > No, that's exactly what WOL is designed for.  A typical scenarios has
> > > > the adapter waking up when the incoming packet is unicast to the MAC
> > > > address of that host.  The hub/switch would act normally.
> > > 
> > > I do not think WOL wakes that way. IIRC it needs magic ethernet
> > > packet.
> > 
> > That's right.  I don't remember what the contents need to be, but WOL 
> > doesn't work with any old ethernet packet.
> 
> You're both wrong.  Notice what "man ethtool" reports:

Ok, you are right and I was wrong....

>        wol p|u|m|b|a|g|s|d...
>               Set Wake-on-LAN options.  Not all devices support this.  The argument to this
>               option is a string of characters specifying which options to enable.
> 
>               p  Wake on phy activity
>               u  Wake on unicast messages
>               m  Wake on multicast messages
>               b  Wake on broadcast messages
>               a  Wake on ARP
>               g  Wake on MagicPacket(tm)
>               s  Enable SecureOn(tm) password for MagicPacket(tm)
>               d  Disable (wake on nothing).  This option clears all
>        previous options.

...I only knew about magicpacket-like stuff.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 881 bytes --]

On Sat, 20 May 2006, Pavel Machek wrote:

> Hi!
> 
> > > > > > ?? WOL is for different functionality, I'm afraid. Or do you know
> > > > > > ethernet hub that automagically wakes machines when data come?
> > > > > 
> > > > > No, that's exactly what WOL is designed for.  A typical scenarios has
> > > > > the adapter waking up when the incoming packet is unicast to the MAC
> > > > > address of that host.  The hub/switch would act normally.
> > > > 
> > > > I do not think WOL wakes that way. IIRC it needs magic ethernet
> > > > packet.
> > > 
> > > That's right.  I don't remember what the contents need to be, but WOL 
> > > doesn't work with any old ethernet packet.
> > 
> > You're both wrong.  Notice what "man ethtool" reports:
> 
> Ok, you are right and I was wrong....

Me too.  I guess things have moved forward since the last time I looked at 
this stuff.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On Saturday 20 May 2006 10:20 am, Pavel Machek wrote:

> > Things that really *must* wake up periodically should be using some API that
> > interacts with RTC alarms, and those RTC alarms should be acting as system
> > wakeup events.
> 
> But that means completely rewriting userspace.

Completely?  No.  Hardly anything really _requires_ real-time wakeups.

In any case, I can't possibly believe it's news to you that userspace code
which uses periodic polling is troublesome ... it wasn't news in the 1980s,
or 1990s, so it can't be news now.  That's not just from the power management
perspective; it also makes trouble in GUI applications architecture too.


> > There's also non-automated sleep too ... what "apmsleep" used to do when
> > you told it to suspend until 7am (or for two hours, etc).  The same thing
> > can be done with /sys/power/state and a wakeup-enabled RTC.
> 
> Yep, I should get it working one day.

See the attached.  "rtcwake -t $(( 5 * 60 * 60))" to sleep in standby mode
for five hours, or until some other wakeup event kicks in.  :)

- Dave


[-- Attachment #2: rtcwake.c --]
[-- Type: text/x-csrc, Size: 5203 bytes --]

#include <stdio.h>
#include <getopt.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>

#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>

#include <linux/rtc.h>


/*
 * rtcwake -- enter a system sleep state until specified wakeup time.
 *
 * This is sort of like the old "apmsleep" utility, except that it uses
 * cross-platform Linux calls not APM.  It expects two newish capabilities
 * in the RTC driver:  using the 2.6.16+ RTC class, and supporting the
 * driver model wakeup flags.
 *
 * This is unlike the x86 "nvram-wakeup", since it doesn't wake from
 * any kind of "soft off".  It wakes from a Linux suspend state, which
 * doesn't necessarily involve BIOS or ACPI even on x86 platforms.
 */

static char		*progname = "rtcwake";

static int may_wakeup(const char *devname)
{
	char	buf[128], *s;
	FILE	*f;

	snprintf(buf, sizeof buf, "/sys/class/rtc/%s/device/power/wakeup",
			devname);
	f = fopen(buf, "r");
	if (!f) {
		perror(buf);
		return 0;
	}
	fgets(buf, sizeof buf, f);
	fclose(f);

	s = strchr(buf, '\n');
	if (!s)
		return 0;
	*s = 0;

	return strcmp(buf, "enabled") == 0;
}

/* all times should be in UTC */
static time_t	sys_time;
static time_t	rtc_time;

static int get_basetimes(int fd)
{
	struct tm	tm;
	time_t		offset;
	struct rtc_time	rtc;

	/* record offset of mktime(), so we can reverse it */
	memset(&tm, 0, sizeof tm);
	tm.tm_year = 70;
	offset = mktime(&tm);

	/* read system and rtc clocks "at the same time"; both in UTC */
	sys_time = time(0);
	if (sys_time == (time_t)-1) {
		perror("read system time");
		return 0;
	}
	if (ioctl(fd, RTC_RD_TIME, &rtc) < 0) {
		perror("read rtc time");
		return 0;
	}

	/* convert rtc_time to normal arithmetic-friendly form */
	tm.tm_sec = rtc.tm_sec;
	tm.tm_min = rtc.tm_min;
	tm.tm_hour = rtc.tm_hour;
	tm.tm_mday = rtc.tm_mday;
	tm.tm_mon = rtc.tm_mon;
	tm.tm_year = rtc.tm_year;
	tm.tm_wday = rtc.tm_wday;
	tm.tm_yday = rtc.tm_yday;
	tm.tm_isdst = rtc.tm_isdst;

	rtc_time = mktime(&tm) - offset;
	if (rtc_time == (time_t)-1) {
		perror("convert rtc time");
		return 0;
	}

	return 1;
}

static int setup_alarm(int fd, time_t *wakeup)
{
	struct tm	tm;
	struct rtc_time	rtc;

	tm = *gmtime(wakeup);

	rtc.tm_sec = tm.tm_sec;
	rtc.tm_min = tm.tm_min;
	rtc.tm_hour = tm.tm_hour;
	rtc.tm_mday = tm.tm_mday;
	rtc.tm_mon = tm.tm_mon;
	rtc.tm_year = tm.tm_year;
	rtc.tm_wday = tm.tm_wday;
	rtc.tm_yday = tm.tm_yday;
	rtc.tm_isdst = tm.tm_isdst;

	/* some rtcs only support up to 24 hours from 'now' ... */
	if (ioctl(fd, RTC_ALM_SET, &rtc) < 0) {
		perror("set rtc alarm");
		return 0;
	}

	if (ioctl(fd, RTC_AIE_ON, 0) < 0) {
		perror("enable rtc alarm");
		return 0;
	}

	return 1;
}

static void suspend_system(const char *suspend)
{
	FILE	*f = fopen("/sys/power/state", "w");

	if (!f) {
		perror("/sys/power/state");
		return;
	}

	fprintf(f, "%s\n", suspend);
	fflush(f);

	/* this executes after wake from suspend */
	fclose(f);
}

int main(int argc, char **argv)
{
	static char		*devname = "rtc0";
	static unsigned		seconds = 60;
	static char		*suspend = "standby";

	int		t;
	int		fd;
	time_t		alarm;

	// progname = argv[0];
	if (chdir("/dev/") < 0) {
		perror("chdir /dev");
		return 1;
	}

	while ((t = getopt(argc, argv, "d:m:s:t:")) != EOF) {
		switch (t) {

		case 'd':
			devname = optarg;
			break;

		/* what system power mode to use?  for now handle
		 * only "on", "standby" and "mem".
		 */
		case 'm':
			if (strcmp(optarg, "standby") == 0
					|| strcmp(optarg, "mem") == 0
					|| strcmp(optarg, "on") == 0
					) {
				suspend = optarg;
				break;
			}
			printf("%s: suspend state %s != 'standby' || 'str'\n",
					progname, optarg);
			goto usage;

		/* absolute alarm time, seconds since 1/1 1970 UTC */
		case 's':
			t = atoi(optarg);
			if (t < 0) {
				printf("%s: illegal time_t value %s\n",
						progname, optarg);
				goto usage;
			}
			alarm = t;
			break;

		/* relative alarm time, in seconds */
		case 't':
			t = atoi(optarg);
			if (t < 0) {
				printf("%s: illegal interval %s seconds\n",
						progname, optarg);
				goto usage;
			}
			seconds = t;
			break;

		default:
usage:
			printf("usage: %s "
					"[-d rtc0|rtc1|...] "
					"[-m on|standby|str] "
					"[-s time_t] "
					"[-t relative seconds] "
					"\n",
					progname);
			return 1;
		}
	}

	/* this RTC must exist and be wakeup-enabled */
	fd = open(devname, O_RDONLY);
	if (fd < 0) {
		perror(devname);
		return 1;
	}
	if (!may_wakeup(devname)) {
		printf("%s: %s not enabled for wakeup events\n",
				progname, devname);
		return 1;
	}

	/* relative or absolute alarm time, normalized to time_t */
	if (!get_basetimes(fd))
		return 1;
	if (alarm)
		alarm -= sys_time - rtc_time;
	else
		alarm = rtc_time + seconds + 1;
	if (setup_alarm(fd, &alarm) < 0)
		return 1;

	printf("%s: wakeup from %s using %s at %s",
			progname, suspend, devname,
			ctime(&alarm));
	fflush(stdout);
	usleep(10 * 1000);

	if (strcmp(suspend, "on") != 0)
		suspend_system(suspend);
	else {
		unsigned long data;

		(void) read(fd, &data, sizeof data);
	}

	if (ioctl(fd, RTC_AIE_OFF, 0) < 0)
		perror("disable rtc alarm interrupt");

	close(fd);
	return 0;
}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

Hi!

> > > Things that really *must* wake up periodically should be using some API that
> > > interacts with RTC alarms, and those RTC alarms should be acting as system
> > > wakeup events.
> > 
> > But that means completely rewriting userspace.
> 
> Completely?  No.  Hardly anything really _requires_ real-time wakeups.
> 
> In any case, I can't possibly believe it's news to you that userspace code
> which uses periodic polling is troublesome ... it wasn't news in the 1980s,
> or 1990s, so it can't be news now.  That's not just from the power management
> perspective; it also makes trouble in GUI applications architecture
> too.

Well, maybe it is not news to _me_, but it is certainly news to
application writers.

Battery applet requires polling -- we have no battery interface that
is event-driven, for example. Then you have clock on the desktop. Then
there's blinking cursor (in X) at HZ/5 or something like that.

How can kernel know which sleep is "important enough" to wake up
system for it?

Like, yes, we can probably do that on embedded platforms, but for
something running KDE/Gnome?

[Now, it is true that things are getting better. One of tricks is to
make sure all the periodic polling happens synchronized (=> cpu can
sleep for longer intervals between polls), and there are tricks like
"only blink X cursor 5 times", but... try running timertop on
KDE/Gnome system...] 

> > > There's also non-automated sleep too ... what "apmsleep" used to do when
> > > you told it to suspend until 7am (or for two hours, etc).  The same thing
> > > can be done with /sys/power/state and a wakeup-enabled RTC.
> > 
> > Yep, I should get it working one day.
> 
> See the attached.  "rtcwake -t $(( 5 * 60 * 60))" to sleep in standby mode
> for five hours, or until some other wakeup event kicks in.  :)

Thanks.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: suspend and hibernate nomenclature

[Scott E. Preece]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]


| On Mon, 2006-05-08 at 20:01 +0000, Pavel Machek wrote:
| > Hi!
| > 
| > > Full description of the problem is here:
| > > http://live.gnome.org/GnomePowerManager/SleepNames and I would encourage
| > > you guys to add comments to the end of the wiki if required.
| > 
| > Please do not use word 'thaw'. We already freeze processes during
| > suspend, and we thaw them during resume.
| 
| Got any better ideas? It needs to *just* apply to hibernation, not a
| generic term like wake.
---

Well, it's not pretty, but using an "un-" prefix is generally
well-understood.  So, suspend/unsuspend, hibernate/unhibernate.

scott
-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece@motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114@vtext.com



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]