FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-01-2011, 11:33 AM
drago01
 
Default F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

On Sat, Oct 1, 2011 at 1:02 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> And I can honestly say I've never seen a
> desktop machine where suspend worked with Linux, so suspending desktop
> machines by default seems like a bad idea.

I don't get where this is coming from, suspend has pretty much always
worked on my desktop machines (ignoring one DMAR bug that got fixed a
while ago).

You have a point though about the AC thing and idle suspend (I didn't
even know that gdm does this), but the "suspend does not work on
desktop" argument is simply not true (it might be broken for some but
that is no different from laptops really, it should be fixed at the
kernel side).
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-01-2011, 03:07 PM
Martin Langhoff
 
Default F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

On Sat, Oct 1, 2011 at 7:02 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> The subject more or less says it all. When I startup my desktop machine (which thus
> is always on AC), and leave it at the gdm screen it will suspend after being left
> alone for 30 minutes. This is not good, since I only leave it powered on when I
> intend to access it remotely.

If it supports LAN-triggered wakeups, I don't see why it should be fully on :-)

Not sure if Fedora 16 has the infra, but in my OLPC-tinted-glasses
view, power mgmt / NM should allow you to say "wake-on-LAN on this
interface", then set the WOL bits when it's going down.

(Note! The WOL bits need to be frobbed every time the system goes to
sleep. They get cleared on wakeup.)

> I would like to suggest to change the default power policy to never suspend
> while on AC power

Thanks for helping keep the Earth warm! :-/

> Another reason for this is that suspend simply does not work

OK, that's a whole another topic.

> suspending desktop
> machines by default seems like a bad idea.

That's such a 90's thinking :-)

At this stage, and looking forward, suspending on idle is a good idea
on /servers/, where you save power at the server and at the AC.

There is work to do across the stack to make S/R work smoothly and
transparently. OLPC is doing much of it -- help us getting it into
mainstream code (and thinking!).

Or join the greenpeace in teaching polar bears about the wonders of
tropical climates...

cheers,


m
--
*martin.langhoff@gmail.com
*martin@laptop.org -- Software Architect - OLPC
*- ask interesting questions
*- don't get distracted with shiny stuff* - working code first
*- http://wiki.laptop.org/go/User:Martinlanghoff
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-01-2011, 03:09 PM
Jan Kratochvil
 
Default F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

On Sat, 01 Oct 2011 13:33:13 +0200, drago01 wrote:
> but the "suspend does not work on desktop" argument is simply not true

Not replying to metoo/flames but neither suspend nor hibernate worked reliably
for me through years on notebook (T60). Depending on BIOS and kernel versions
the former or latter were more reliable. (No proprietary software involved.)
One can expect desktop may have both even less tested => less reliable.


Regards,
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-02-2011, 07:02 AM
Hans de Goede
 
Default F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

Hi,

On 10/01/2011 05:07 PM, Martin Langhoff wrote:
> On Sat, Oct 1, 2011 at 7:02 AM, Hans de Goede<hdegoede@redhat.com> wrote:
>> The subject more or less says it all. When I startup my desktop machine (which thus
>> is always on AC), and leave it at the gdm screen it will suspend after being left
>> alone for 30 minutes. This is not good, since I only leave it powered on when I
>> intend to access it remotely.
>
> If it supports LAN-triggered wakeups, I don't see why it should be fully on :-)
>
> Not sure if Fedora 16 has the infra, but in my OLPC-tinted-glasses
> view, power mgmt / NM should allow you to say "wake-on-LAN on this
> interface", then set the WOL bits when it's going down.
>
> (Note! The WOL bits need to be frobbed every time the system goes to
> sleep. They get cleared on wakeup.)

It would then also need to identify the NIC as a stay awake source, and
only suspend after 30 minutes of no network activity.

Imagine I'm running a screen session with my irc client in there on my Fedora box,
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.

>> I would like to suggest to change the default power policy to never suspend
>> while on AC power
>
> Thanks for helping keep the Earth warm! :-/

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.

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. Once we do then it becomes a question of the latency increase
caused by this is acceptable by the use case.

>> suspending desktop
>> machines by default seems like a bad idea.
>
> That's such a 90's thinking :-)
>
> At this stage, and looking forward, suspending on idle is a good idea
> on /servers/, where you save power at the server and at the AC.
>
> There is work to do across the stack to make S/R work smoothly and
> transparently. OLPC is doing much of it -- help us getting it into
> mainstream code (and thinking!).

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. The last big power
eater is RAM and that will be active in both scenarios.

>
> Or join the greenpeace in teaching polar bears about the wonders of
> tropical climates...

<sigh> I was already afraid people would come up with this totally uncalled
for global warming arguments </sigh> You're barking up the wrong tree here,
as described above I'm pretty aggressive about powermanagement for my desktop
machine, and I don't even have a server at home.

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.

Regards,

Hans
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-02-2011, 08:13 PM
"Jason D. Clinton"
 
Default F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

On Sun, Oct 2, 2011 at 02:02, Hans de Goede <hdegoede@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-03-2011, 07:48 AM
Hans de Goede
 
Default F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

Hi,

On 10/02/2011 10:13 PM, Jason D. Clinton wrote:
> On Sun, Oct 2, 2011 at 02:02, Hans de Goede<hdegoede@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-03-2011, 07:57 AM
Richard Hughes
 
Default F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

On 1 October 2011 12:02, Hans de Goede <hdegoede@redhat.com> wrote:
> I would like to suggest to change the default power policy to never suspend
> while on AC power.

That's what it was supposed to be, but due to an oversight on my part
the wrong keys were being set. I've fixed this upstream in
https://bugzilla.gnome.org/show_bug.cgi?id=660395 -- which will of
course be included in 3.2.1

Thanks,

Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-03-2011, 08:32 AM
Frederic Muller
 
Default F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

On 10/03/2011 03:48 PM, Hans de Goede wrote:
> This is todays hardware and with every generation the gap is getting smaller
> between dyn pm savings and suspend savings.

"The annual life cycle energy use for a computer (3-year lifespan) is
2600 MJ [...]. The energy footprint of a computer is thus far more
significant than its physical size would suggest. The energy used for
the production phase is 81% of the total consumed for production and
operation"[1]

I've read other figures of 70% for production but we can agree that it's
not contradicting.

With this in mind I think the REAL energy saving battle lies elsewhere.
Not to diminish the work done on energy saving during usage, but how
much can you reduce from 19% versus 81%? Oh right, we have no control
over the 81%... but maybe it's not a reason good enough to force such
choices onto users. This is a general comment on suspend/always-on/power
off; we saw the same logic being pushed forward to justify the 'hidden'
shutdown option in GNOME. Maybe developers and users should be aware of
the overall impact of their PC, not just the usage part.

Fred


[1]
http://www.scribd.com/doc/4183/Energy-Intensity-of-Computer-Manufacturing
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-03-2011, 09:37 AM
Nicolas Mailhot
 
Default F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

Hi,

To provide another data point, here my desktop :

1. runs network services (because webmail just works locally and remotely, unlike evo which has been a crasher for as long as I can remember)

2. uses dyndns (evil I know) and with the systemd/networkmanager changes ddclient does not seem to register ip changes centrally anymore. So I'd like to keep dhcp leases as long as possible

3. uses a high efficiency low-noise PSU, which does not like power ups at all (in fact restarting the computer now takes a dozen tries, with minutes waiting for caps to drain ; yes I could change the hardware but it works fine under load and a new PSU is how many years of energy savings again ?).

4. Runs rawhide, so I prefer controlling reboot/startup times, to avoid crashing the system at a time I'm not available to fix it. One side-effect of the last shutdown is gnome-shell crashing on login when I don't have the time to investigate it.

So anyway you look at it, this change is a bloody nuisance

As many real-life setups it is much more complex that paper desktop abstractions.

--
Nicolas Mailhot

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-03-2011, 01:01 PM
Bruno Wolff III
 
Default F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in

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

It looks like it also might not be for systems that have encrypted swap.
I think I started getting crashes starting Saturday in rawhide because of
this. I am not sure since the symptom was after not using my system from
the desktop for a while I would come back to find the machine totally dead.
After setting it to never suspend, this stopped happening.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 05:19 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org