Re: F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
Le Lun 3 octobre 2011 17:09, Przemek Klosowski a écrit : The bottom line is that the power supply is probably on the fritz and likely to fail altogether. Decent power supplies aren't that expensive, I recently got a nice, quiet one for around $30-40. Thanks, but it's perfectly fine under load, so I don't see the point of changing it prematurely. It just does not like shutdowns -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
On 3 October 2011 08:57, Richard Hughes hughsi...@gmail.com wrote: 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 I've done a test build here for anyone interested: http://koji.fedoraproject.org/koji/taskinfo?taskID=3401483 Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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 Goedehdego...@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
Re: 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 hdego...@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
Re: 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
Re: 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 Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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
Re: F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
On Sun, Oct 2, 2011 at 4:13 PM, Jason D. Clinton m...@jasonclinton.com wrote: 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. Well, it's not well supported now across the stack, but it is surely not madness. On the XO hardware we actually use WOL while there peer-to-peer network connections up. On x86 the wakeup time is not so good. On the upcoming ARM model, the wakeup time is expected to be very low. We are sorting out wakeup right now so can't really say, but surely 100ms. This means that blade servers running ARM (or any SoC where power mgmt has been well designed) can be drawing ~250mw in a suspend that looks a lot like a very deep sleep. No fans, no aircon footprint. Are there things to resolve on the way to making this practical? Definitely! Should we be riding the I want lower power draw / fast+transparent suspend/deep-idle on my netbook wave to benefit the server space? I sure think so. 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. Interesting numbers. The big questions is -- does it suspend and resume fast and transparently enough that you can treat suspend as a very deep idle? And how fast can we bring those improvements to the much bigger numbers you have for servers. m -- martin.langh...@gmail.com mar...@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
Re: F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
On 10/03/2011 05:37 AM, Nicolas Mailhot wrote: 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 ?). If your PS has trouble starting because of faulty caps, it's probably not because they are draining---on the contrary, they are probably worn out and leaky (electrically), causing trouble for the startup circuit which wasn't designed for the extra losses. Often you can identify the failing electrical capacitors because their casing is swollen or maybe even burst open and leaking the actual electrolyte. http://en.wikipedia.org/wiki/Capacitor_plague You'd have to disassemble the power supply to see that, however, and there are possibly dangerous voltages inside even for some time after disconnecting the power, so I don't recommend doing that. The bottom line is that the power supply is probably on the fritz and likely to fail altogether. Decent power supplies aren't that expensive, I recently got a nice, quiet one for around $30-40. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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 Goedehdego...@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
Re: 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 hdego...@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
F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
Hi All, 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. I would like to suggest to change the default power policy to never suspend while on AC power. Another reason for this is that suspend simply does not work on this (very recent) desktop machine. 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. Note I've also filed a bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=742685 But since this more of a policy thing then really a bug I thought it would be good to discuss this on the list. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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 hdego...@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
Re: 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 hdego...@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.langh...@gmail.com mar...@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
Re: 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
Re: F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
Hans de Goede 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. You can use KDM instead. It does not support power management at all (at this time), so you can be sure that it won't be suspending your computer, ever. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
