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

[Hans de Goede]

Hi,

On 10/02/2011 10:13 PM, Jason D. Clinton wrote:
> 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. :-)
>

Hehe, actually I don't do that, I always use xchat this just was an example
of something I know some people do :)

>> 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.

Agreed, so we need a way to set that powerpolicy, esp. since Fedora still had a server
installation profile last time I checked.

>> 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.

Agreed this was just to show there are otherways to save power and to debunk the
whole not autosuspending makes the polarcaps melt argument. Anyways auto-suspending
for the desktop case is fine.

>> 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.

If you say so :) I had the same feeling but I'm not that deep into recent pm
advances.

Note that this also makes autosuspend for servers madness -> we need an
user/admin friendly way to configure this.

> 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).

Right, I do hope that you see here that no disk idle behavior is not really
a fair comparison. If you get the 30 minutes of inactivity which is needed
for auto-suspend, surely you can also makes the disk spin down. Also as you
set before wol is not the answer for servers, so we really need to get better
at this dynamic pm stuff.

> 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.

1) Not for servers
2) This is todays hardware and with every generation the gap is getting smaller
between dyn pm savings and suspend savings.

>> 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

Sorry, but that is not an acceptable solution. As you said yourself there is a
need to have a different power policy for server versus desktop usage. From that
logically follows that we thus need to be able to configure that power policy using
some configuration tool. Directly frobbing gsettings is just as arcane as running
irc in a screen session and thus not a proper solution.

Regards,

Hans