Messages in this thread | | | Date | Mon, 20 Jan 2014 21:44:52 +0100 | From | Pavel Machek <> | Subject | Re: [11/11] system 1: Saving energy using DVFS |
| |
Hi!
> > > Race to idle doesn't mean that the screen goes off as well. Let's say > > > the screen stays on for 1 min and the CPU needs to be running for 10s > > > over this minute, in the first case you have: > > > > No, it does not. I just assumed user is continuing to use his > > machine. Obviously, waiting 60 seconds with screen on will make the > > difference look smaller. But your solution still means user has to > > wait longer _and_ you consume more battery doing so. > > > > And this is for any task where user waits for result with screen > > on. Like rendering a webpage. Like opening settings screen. Like > > installing application. > > Page rendering should make very little difference to power since the > reading (screen on) time is much larger than the rendering (CPU) > time.
For some uses, yes, for some uses (searching for bus time tables, displaying weather) not neccessarily. And I suspect that the whole CPU consumption takes a little difference in power, anyways...
> But what I'm pointing at for 10s/60s ratios are thing like games or > video playing where the CPU is running for 1/6 of the time and idle for > the other 5/6. We get better energy figures by changing the run time to > 3/6 and idle at 3/6.
Better energy figures on complete system consumption, on phone-type device that can be bought in the shop?
> > But hey, maybe you are right and running at lowest possible frequency > > is right. Please provide concrete numbers like I did. > > They've been anonymised (for many reasons) and you have the right not to > trust them. But do you really think we are making up the numbers? We
"Here is power consumption of unspecified part of machine in unspecified units on machine of unspecified type. Trust us our patches improve it in unspecified workload". Why should I trust you?
> have a great interest in the Linux scheduler working efficiently on the > ARM platforms rather than optimising it for non-existent scenarios. If > at some point this argument becomes a blocking factor, I'm sure we can > share the real numbers with the relevant parties under an NDA.
I'm sure you can just buy Samsung S4 in the nearest shop, and you probably can find and ampermeter on site... Then perhaps people can reproduce your results and we can have useful discussion. This is relevant to production hardware, right?
Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |