F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

[Jason D. Clinton]

On Sun, Oct 2, 2011 at 02:02, Hans de Goede <hdegoede at redhat.com> wrote:
> Imagine I'm running a screen session with my irc client in there on my Fedora box,

There has perhaps never been a better sentence written demonstrating
why software engineers are not the target audience of any software
development. :-)

> and 30 minutes after the last resume it suspends while I'm midway typing a sentence,
> then it wakes up again because of the network activity. Power management win 0, likely
> even a loss (disks spinning up which may have stayed spun down otherwise, etc. User
> experience suck, since I all of a sudden get a multiple seconds latency while typing.

Your "desktop" is now a "server" and the power policy should reflect
that it's offering up network services.

> Well there are 2 use cases to consider here:
> 1) The machine has a desktop function -> just turn it off when it is not used
>    My desktop rarely gets an uptime > 4 hours since I even turn it off when I
>    go to lunch, and it has a master/slave powerstrip to also power down the
>    printer, display, speaker, etc. One could even argue that suspending here
>    will lure people in to the false sense that it is ok to leave it on since
>    it will go into low power mode anyways, while in reality it is still using
>    a significant amount of power. I'm pretty sure that if we were to bet and
>    measure the poweruse of my desktop once for a week using my power regime,
>    and once more using an always on, but suspend after 30 minutes of idle
>    power regime, that my power regime is significantly more efficient.

People are not like machines, we don't always know that we're not
coming back to our computers and we forget to turn them off. We're
also lazy.

> 2) The machine has a server function. In this case working wake on lan and
>    stay active on lan are a must have and until we have those it should not
>    auto suspend.

WOL for a network server is madness. It shouldn't have been suggested.
If you really want to save power, move your IRC client to a shared
shell server somewhere so that the power consumption of an always-on
server is aggregated across all those who use it. That really gets to
the heart of the argument for "cloud" computing: economies of scale.

> I for one would argue that system suspend itself is 90's thinking,
> and that we should get better at dynamic powermanagement with things
> like powergating and dynamic clockspeed support becoming pretty common
> in all hardware one could argue that system suspend is the powersaving
> answer of the 90's and that of the 2010's is becoming better at dynamic
> pm. I think that a system with its disks spun down, cpu clocked down and
> in its lowest powerstate, unused usb controllers in suspend, display engine
> in its lowest powerstate and display pipes + connectors turned off, etc.
> will come pretty close to a fully suspended system.

A fully power-saved Sandy Bridge laptop in the state you lay out above
is around 7W. A suspended laptop from the same generation consumes
roughly 0.4W of power. Stand-by is 0.1W.

Desktop systems from the same generation tend to be on the order of
1-2W while suspended and consume 30-35W while power-saved. Stand-by is
1-2W.

Servers from the same generation tend to be on the order of 6-8W while
suspended and consume around 90-120W while power-saved (assuming a
dual socket mobo with no disk idle behavior and dual GigE NIC's).
There's some variability here based on the number of DIMM's. Stand-by
is 1-4W.

As you can see, suspending is the right thing to do.

> But sometimes I work a couple of hours from the laptop in the living room and
> I need access to my desktop, so then the desktop is on (with the display turned
> off, really off) untill now this worked fine, with F-16 it no longer works fine.
> We've a name for that it is called a regression and it needs to be fixed.
>
> At a minimum there should be an easy way to configure the powermanagement policy
> under gdm which there currently is not. Things like Network-Manager and the
> Region and Language setting already allow configuring gdm / system wide settings
> from there gnome-3 user session control panel, if we want to do powermanagement
> from gdm we need the same for gdm.

I'm guessing this will work even if no X session is running; please
report back if it doesn't:
sudo -u gdm dbus-launch gsettings set
org.gnome.settings-daemon.plugins.power sleep-inactive-ac false