On Sun, Aug 26, 2012 at 6:58 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sun, 26 Aug 2012 05:25:29 +0200 thomasg <tho...@gstaedtner.net> 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. > 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. > 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. > (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. 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. 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. 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 :) 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. >> On Sun, Aug 26, 2012 at 12:43 AM, Wido <wido...@gmail.com> 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 <wido...@gmail.com> 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 <wido...@gmail.com> 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 >> > >> >> > >> > >> >> >> > enlightenment-users@lists.sourceforge.net >> > >> >> > >> > >> >> >> > 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 >> > >> >> > >> > >> >> >> enlightenment-users@lists.sourceforge.net >> > >> >> > >> > >> >> >> 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 >> enlightenment-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > ------------------------------------------------------------------------------ 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 enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
