From: Carsten H. (T. R. <ra...@ra...> - 2012-08-26 12:46:41
|
On Sun, 26 Aug 2012 13:36:49 +0200 thomasg <th...@gs...> said: > On Sun, Aug 26, 2012 at 6:58 AM, Carsten Haitzler <ra...@ra...> > wrote: > > On Sun, 26 Aug 2012 05:25:29 +0200 thomasg <th...@gs...> said: > > > > i agree that a user should almost never switch frequencies by hand this is > > rather pointless. cpufreq allows it - but it's there for tweakers (like me) > > so i can even measure power usage at various freqs, performance etc. it's > > buried inside a menu so as not to be too convenient. > > Yeah sure, having the option for doing testing is great. Imho its just > not clear enough to users that testing is the only case where using > this is wise. > Then again, I don't really have any great idea how to make it not to > inconvenient for testers, yet inconvenient enough for users :) > What might work is, making the cpu-freq gadget a "single-click" > solution. All advanced options in a right-click sub-menu, and simple > switching between Ondemand and Performance by a single left click. yeah. moving the governors list to the main menu on left click will encourage the right use. i actually wanted to make it like mixer or backlight. maybe a slider with a few notches for max perf, min perf and ondemand+conservative. i actually wanted to combine a cpu load meter too a bit like a tacho+speedo in your car. having 70% cpu load but still being at 1ghz is a far cry less cpu load than 70% at 2ghz. > > imho all we need to do from userspace is switch governors or tweak them. > > that means right now powersave / automatic / ondemand / performance. these > > governors do not HAVE to keep the cpu at min or max freq. they happen to > > with powersave and performance, but conceptually they could switch > > frequencies around. if performance can clock down and be done totally > > imperceptible to benchmarking, the ui and responsiveness, then why not? but > > it doesn't. > > As I said, I'm perfectly happy with the possibility to switch between > ondemand and performance. Powersave is (mostly) as pointless as > manual, because it doesn't save power. i don't have any numbers to prove this i guess, but i'd actually like to figure out if powersave helps or not given workload X (everything else being equal). as above i'd make it a slider with 4 notches on the cpufreq gadget so its simpler like the accelerator throttle in a boat or train :) simple and easy. yes i know. for the ODD tweakers amongst us. :) just fyi i have 1 machine where i MUST use powersave. its an old pentum-m. it can clock to 600 or 1000mhz. at 1000mhz if it runs for more than about 40sec it overheats so much that it THROTTLES (not clockrate - acpi throttle states) and performance drops through the floor to be much worse than staying at 600mhz. literally it doesn't have a cpu fan. it's passively cooled only. its a special ULV version of the pentium-m. so... here is a situation where you HAVE to use powersave just to function properly. the high clockrates are for short-bursts only. also... you may not live in a country that gets hot, but if you live somewhere were a hot summer day is in the 40's... you may reconsider the idea that powersave is useless. :) > > the reality that *I* see is that ondemand/automatic have visible impacts to > > the user (other than the fan spinning up/down temperature and power > > consumption changing). i literally can watch my compile scrolling by faster > > switching to performance. its a big jump. it's not a placebo effect. to > > prove the point here are numbers for "make clean > > maintainer-clean; ./autogen.sh > > --disable-static && make -j10 && sudo make -j10 install" for e17 on my > > machine: > > This is true. A area where ondemand still performs badly is I/O-heavy > operations that generally don't use the CPU much. > ./configure is something ondemand does really badly. indeed. and i've noticed. :) > > (this machine core i5 1.6ghz->3.4ghz, 8gb ram, x86_64, all data on ssd so > > no hdd slowness, i ran the exact same compile before the first run to > > ensure all caches are warmed up, linux 3.2.0) > > > > (maximum speed, automatic, low power automatic, minimum speed) > > performance : 91 sec > > ondemand : 122 sec > > conservative: 113 sec > > powersave : 198 sec > > > > ondemand/powersave are not invisible. it's not a placebo effect. i have > > spent my life staring at graphics and animation and i can sometimes SEE the > > difference with responsiveness just in frame rendering when using these. i > > don't have a quick test to prove it but i'm less likely to be affected by > > placebo as this is what i have done for most of my life - stare at > > graphics, animation and spot single pixel glitches and off-by-1's and > > incorrect frame timings. i'm normally very sceptical so if i am seeing an > > effect, it probably is very much there. i just don't have a test for you. i > > could try make one... maybe measure time from ecore wakeup on event to time > > until frame render done and flushed. > > > > believe it or not humans do perceive latencies of less than 20ms. you just > > can't quite realize what you are perceiving and end up saying "this thing is > > slow" when it's fast - it never drops a frame, but.. it's just got higher > > latency. 20ms is enough to be 1 frame behind (actually less is enough). when > > you get an event u want time from event to result on screen to be as short > > as possible. this is because events can come in at ANY time, BUT your > > screen is refreshing at a constant fixed rate. higher latencies present > > themselves eg as pointer being further ahead of the scrollbar or scrolling > > content or window u are moving than normal. if you miss being able to get > > data in at one frame, it has to be delayed until the next frame. this ADDS > > (at 60hz) up to 16.66ms to your latency of display already. so here's an > > example. > > > > 2ms before the next refresh you get an event. you respond and render. this > > rendering take 4ms. oops. you missed the frame. so now your update waits > > another 14.66ms from the time u finished rendering until user sees it. total > > latency from input event to seeing result -> 18.66ms. now to make it even > > worse, with compositing we have ANOTHER rendering step - the compositor. so > > add some more ms to the rendering time etc. etc. not to mention the slower > > your machine (eg cpu clocked down or just old machine) the longer the > > rendering time and the more often you end up in this bucket and the longer > > your latency. given the right circumstances, if you are JUST fast enough to > > render frames at screen refresh given your cpu power etc. then u can be UP > > to 33ms behind the event that generated the redraw. this is visible > > ESPECIALLY if dragging. > > > > anyway. my point is that it is measurable and visible. just the numbers > > above prove that its not invisible to the user. i can literally see my > > compiles go faster ESPECIALLY "configure" goes faster. 6.2s vs 11.4s vs > > 11.9s vs 11.9s (as per above governors in that order). almost twice as fast > > under performance vs ondemand and automatic. it's visible. it's measurable. > > the day it is not measurable or visible is the day we can just stop > > worrying and let the kernel deal with it, but reality is that this day has > > not come. i'm all for saving power, keeping the cpu fan quiet, not > > generating much heat etc, BUT it's all still a trade-off and so we > > ultimately have to give the decision of what to "give up" in return for > > what to the user until they no longer need to care. > > That's a bit sad, but still, I think userspace as well as the user > himself still will make the worst decisions in general. maybe, maybe not, but at this stage in linux's existence... it's the only sane choice we have. and linux or not, there are hardware design decisions, environmental conditions and more that mean you do want and NEED manual control. > The user can say: "I have no interest in saving power" and switch to > performance, that's fine. The user can even say: "I need full > performance for an hour" and make the switch between ondemand and > performance personally, but this really shouldn't be the case on a > regular basis. maybe, maybe not. but they need the choice. hell *I* need the choice. cpufreq exists because *I* needed it years ago. i had a P4 based laptop... i HAD to manually control it because I had to selectively enable ondemand or keep it at powersave as at 3ghz the fan spun so fast it almost went into orbit and it would also become unstable unless i clocked it back down - like the pentium-m laptop but much nastier. i'd enable ondemand for a quick compile then force it back down again to stay alive. :) > To be honest: I think that software defined powersaving is a bad idea > in general. The kernel has the best shot on making this work, > everything else can only do worse. depends which bits. as above. i have had 2 cases where the kernel screws up and i need powersave. the kernel doesn't "magically fix things". the kernel doesn't go look at temperature sensors and clock down again. even if it did what temperature would require the forced clock-down? totally specific to that piece of hardware. thus i have to do it by hand. cpufreq makes it easy and convenient. other cases are with performance being measurably lower on ondemand or conservative. they need controls too but at the other end of the spectrum. cpufreq is a real solution to a real-world problem. it happens to help people. :) > In the end this will be going to be done in hardware solely and there > will be no more software influence, but for now, ondemand still does > the best job, even if it doesn't always work perfectly. > The exception proves the rule :) i seriously doubt this will only be in hardware. in fact things are moving more and more to be software controlled. the hardware cannot know the current INTENTS of the user. the best thing to know is the highest levels of software or the user themselves and have information transported down to the controls. if the ONLY thing that affected cpu frequency switching was current cpu load (which is pretty much what it is), then as long as its algorithms made it entirely invisible to the user - great but it's not the only thing deciding what to clock to. > Anyway, to any user reading this, the thing to take away is: If you > feel or really are experiencing slowdowns, switch to performance (aka > "Maximum Speed"), and if you don't love your power bill, switch back > to automatic afterwards. Never ever ever set the frequency itself > manually, neither to max., nor to min. or anything in between. actually... i'll disagree there. :) at least on the setting to min, max or the 2 auto modes. i have real use cases that need the 2 extremes and the so called "works perfectly in all cases" auto modes. :) > >> On Sun, Aug 26, 2012 at 12:43 AM, Wido <wi...@gm...> wrote: > >> > > >> > > >> > > >> > > >> > On Saturday August 25 2012 15:29:17 thomasg escribió: > >> > > >> >> I'm sorry, but your assumptions are fundamentally flawed. > >> > > >> >> > >> > > >> >> On Sat, Aug 25, 2012 at 7:09 PM, Wido <wi...@gm...> wrote: > >> > > >> >> > ondemand works based on priorities, not idliness. For example, in my > >> >> > debian > >> > > >> >> > >> > > >> >> It does not. > >> > > >> >> However, it somewhat does take priority into account, which you can > >> > > >> >> disable by passing ignore_nice_load=1 as parameter to the ondemand > >> > > >> >> cpufreq kernel module. > >> > > >> > > >> > > >> > You are right, my bad. I forgot to add > >> > > >> > > >> > > >> > "2.4 Ondemand > >> > > >> > ------------ > >> > > >> > > >> > > >> > The CPUfreq governor "ondemand" sets the CPU depending on the > >> > > >> > current usage. To do this the CPU must have the capability to > >> > > >> > switch the frequency very quickly." (from kernel.org) > >> > > >> > that means, it changes the freq based in usage, the more cpu usage, the > >> > higher the speed. That 's what I mean when I say 'not idliness'. Idliness > >> > would mean, not touching your computer for a while > >> > > >> > >> No, idleness is the CPU not having to do any work for a while (a while > >> in kernel terms is some nanoseconds). > >> So even if you don't touch your machine for a day, it might not be > >> idle, because it might execute some software in the background. > >> On the other hand, the machine can be idle even if you sit in front of > >> it, because it is much better and infinitely faster in making > >> decisions than any human, and so it will reduce its clock in this time > >> as well. > >> > >> >> > >> > > >> >> > testing, my regular desktop apps have a priority of 23, so ondemand > >> >> > not > >> > > >> >> > always rises the speed as I would like. Other example is when you go > >> >> > to > >> > > >> >> > lunch, you usually just lock your screen, but how many really lower > >> >> > power > >> > > >> >> > >> > > >> >> cpufreq handles the cpu, what the screen does is absolutely irrelevant. > >> > > >> >> The CPU will still run when you turn off or even unplug your screen, > >> > > >> >> it simply does not care. > >> > > >> >> Locking the screen does not magically reduce power consumption. > >> > > >> > > >> > > >> > I know the screen has nothing to do. But I think locking and E's own > >> > screensaver feature are somehow linked, so I assumed it would, somehow, > >> > pass it 'state' to the modules, or the modules would be able to know if > >> > E is locked or with screensaver. > >> > > >> > >> They are not linked, the screen saver has only very few actions it can > >> take and will never inform any other module. > >> > >> > > >> > > >> >> > >> > > >> >> > consumption? yeah, it's a stupid scenario, but is the one I'm > >> >> > interested (or > >> > > >> >> > when I go to sleep without shuting down the computer and forget to > >> >> > chance > >> > > >> >> > power policy). > >> > > >> >> > >> > > >> >> You should never change power policy manually, except for very rare > >> > > >> >> cases where automatic policies don't work. > >> > > >> >> In almost any case that is contra-productive and you generally will > >> > > >> >> waste energy (and your own time) needlessly. > >> > > >> >> What you want is suspend to ram. > >> > > >> >> e17 can even automatically suspend your computer when it is idle long > >> > > >> >> enough (via the screen saver). > >> > > >> > > >> > > >> > Changing the policy from the cpufreq module, not 'by hand' (I'm assuming > >> > that 'by hand' means writing to > >> > /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor, right). When did I > >> > imply 'by hand'? > >> > > >> > >> You are always implying by hand, which in this case is manually using > >> the e17 cpu-freq frontend to change policy and frequency. > >> > >> I already said that in the past: the cpufreq module should not be > >> enabled by default, because it suggests users, that it may be wise to > >> use it. > >> Most of the time, it isn't. > >> It is (almost always) useless information and (almost always) > >> contraproductive. > >> > >> > > >> > > >> >> > >> > > >> >> > > >> > > >> >> > > >> > > >> >> > And, the idea is that cpufreq module changes the freq (something it > >> >> > already > >> > > >> >> > does), not to rewrite a new power policy. > >> > > >> >> > > >> > > >> >> > >> > > >> >> It does not. It has no policy code, it will only display the status > >> > > >> >> quo via the kernels cpu-freq infrastructure. > >> > > >> > > >> > > >> > It does no changes the freq? I'm sorry, but when I do 'click -> cpu > >> > velocity -> 2.3' I'm not changing the freq? policy or not policy, it can > >> > force the current frequency. I know it can because I do that all the > >> > time, what I would like is that it changes to the minimum frequency > >> > available when E is completelly idle. > >> > > >> > >> The module itself does not change the frequency. > >> If you chose the frequency via the module, what happens is: > >> 1) ask cpu-freq to switch to the userspace governor > >> 2) ask cpu-freq to set a certain p-state (frequency) > >> > >> Both is a terrible idea, as both costs you a) performance and b) energy. > >> The userspace governor forces the user to make his own policy and make > >> all adjustments by hand. > >> This is a terrible idea, because every user (even the most skilled and > >> smart ones) makes terrible decisions. > >> Setting the CPU to a low frequency costs you performance because the > >> cpu can't switch to a fast state, but it also costs you power, because > >> the cpu is less effective at lower frequencies and high load. > >> Setting the CPU to a high frequency does not cost you performance but > >> it constantly costs you power because the system cannot reduce > >> voltage, has to run at high frequencies for mostly no reasons (your > >> CPU is hardly ever working) and it will disable some hardware internal > >> powersaving mechanisms. > >> > >> What would be acceptable is to switch from the ondemand governor > >> (default) to "performance" in case of a negative performance impact of > >> ondemand, which is rare and the majority of users will likely never > >> experience. > >> I strongly believe, that the userspace governor is a terrible idea, > >> distros should not offer it by default to users, and e17 should not > >> offer it by default via the cpufreq gadget. It basically is a button > >> that says "please computer, waste some energy!" > >> > >> > > >> > > >> > > >> > > >> > > >> > > >> > Today I was thinking what other scenarios would be usefull for this. > >> > Then, I remembered that E is very versatile, it can fit in a car's audio > >> > system, in a home theater, a cell phone or even a fridge. I know that > >> > ondemand would fit most of this scenarios, but ondeman works > >> > continuously. That means that if you don't input something for a couple > >> > seconds, freq tends to go down again. I've used ondemand in a laptop > >> > that I had (thinkpad t61, not the best but pretty good), the response > >> > time when in ondemand were not as I would expect. I ended up with > >> > forcing full speed and ondemand when in battery (not 'by hand' but using > >> > cpufrq module). > >> > > >> > >> Generally, ondemand will switch state in under a few milliseconds and > >> you will never notice. > >> There are rare cases when ondemand will switch back and forth because > >> of an unusual usage pattern, but I never encountered it since 2005 or > >> so. > >> > >> > > >> > > >> > So imagine a fridge, working 24/7, you could have a cpu that has 3 or 4 > >> > speeds (don't know how much ARM can have). When the user acctually uses > >> > the fridge panel, you go to full speed, making as responsible as > >> > possible. When nobody touches it, you go to min speed saving consuption. > >> > Same scenario applies for cellphones. Ondeman works, yes, but as it > >> > works continually, it may low freq, making the system less responsive. > >> > > >> > >> This is exactly what ondemand does. > >> I do not believe you ever noticed any latency impact, because ondemand > >> will switch much much faster than you could possibly tell. > >> If you really did, and the cpufreq modules heavy placebo/nocebo-effect > >> didn't play a trick on you, something else was probably > >> mis-configured. > >> > >> Ondemand will, in default configuration on modern desktop systems, > >> evaluate and change the frequency every 10 ms -- human eyes have > >> latencies between 20 and 50 ms. And even then, it might not even be > >> necessary to change the frequency for simple UI stuff, because the CPU > >> might be done in under 10ms already and give cpu-freq no reason to > >> switch state. > >> > >> Anyway, to come back to your core point: I do not believe it is wise > >> to implement such policy in userspace, because userspace does not have > >> the facts to evaluate. Basically the only decision E could make here > >> would be to use the performance governor when the computer is actively > >> used - but this is a terrible idea, because the CPU on a personal > >> computer being actively used is still idle for far beyond 99% of the > >> time. > >> > >> > > >> > > >> > > >> > > >> >> > >> > > >> >> > > >> > > >> >> > > >> > > >> >> > On Saturday August 25 2012 13:54:54 thomasg escribió: > >> > > >> >> > > >> > > >> >> >> On Sat, Aug 25, 2012 at 3:35 AM, Wido <wi...@gm...> wrote: > >> > > >> >> > > >> > > >> >> >> > Hi! > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > Yesterday I was thinking (yeah, sometimes I do that...specially > >> >> >> > when > >> > > >> >> >> > trying to fall asleep), would it be possible to add an option to > >> >> >> > the cpufreq > >> > > >> >> >> > module that, when E goes idle, the freq goes to th min value, and > >> >> >> > when you > >> > > >> >> >> > resume it goes back to the setting it had before. > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > This way, if you want, you can use powersave when not doing > >> >> >> > anything. > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > cheers > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > Wido > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> >> > > >> >> >> > ------------------------------------------------------------------------------ > >> > > >> >> > > >> > > >> >> >> > Live Security Virtual Conference > >> > > >> >> > > >> > > >> >> >> > Exclusive live event will cover all the ways today's security and > >> > > >> >> > > >> > > >> >> >> > threat landscape has changed and how IT managers can respond. > >> > > >> >> >> > Discussions > >> > > >> >> > > >> > > >> >> >> > will include endpoint security, mobile security and the latest in > >> > > >> >> >> > malware > >> > > >> >> > > >> > > >> >> >> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> > > >> >> > > >> > > >> >> >> > _______________________________________________ > >> > > >> >> > > >> > > >> >> >> > enlightenment-users mailing list > >> > > >> >> > > >> > > >> >> >> > enl...@li... > >> > > >> >> > > >> > > >> >> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > >> > > >> >> > > >> > > >> >> >> > >> > > >> >> > > >> > > >> >> >> That's what the linux kernels ondemand cpufreq governor already does, > >> > > >> >> > > >> > > >> >> >> I don't see any reason why something that already is done should be > >> > > >> >> > > >> > > >> >> >> reimplemented in userspace (which could only be done poorly). > >> > > >> >> > > >> > > >> >> >> > >> > > >> >> > > >> > > >> >> >> > >> > > >> >> >> > >> >> >> ------------------------------------------------------------------------------ > >> > > >> >> > > >> > > >> >> >> Live Security Virtual Conference > >> > > >> >> > > >> > > >> >> >> Exclusive live event will cover all the ways today's security and > >> > > >> >> > > >> > > >> >> >> threat landscape has changed and how IT managers can respond. > >> >> >> Discussions > >> > > >> >> > > >> > > >> >> >> will include endpoint security, mobile security and the latest in > >> >> >> malware > >> > > >> >> > > >> > > >> >> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> > > >> >> > > >> > > >> >> >> _______________________________________________ > >> > > >> >> > > >> > > >> >> >> enlightenment-users mailing list > >> > > >> >> > > >> > > >> >> >> enl...@li... > >> > > >> >> > > >> > > >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > >> > > >> >> > > >> > > >> >> >> > >> > > >> >> > > >> > > >> >> > ________________________________ > >> > > >> >> > > >> > > >> >> > Wido > >> > > >> >> > >> > > >> > ________________________________ > >> > > >> > Wido > >> > >> ------------------------------------------------------------------------------ > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. Discussions > >> will include endpoint security, mobile security and the latest in malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> _______________________________________________ > >> enlightenment-users mailing list > >> enl...@li... > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ra...@ra... > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |