Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Ok, let's go with your example sequence. The average over 10 minutes is 2.9 per minute, and the standard deviation is 6. That's a huge standard deviation. This means, we can say that in 68% of circumstances, the 11th minute's usage will be somewhere between -3.1 and 8.9. Obviously it can't be less than zero, but this demonstrates that your example sequence gives a really bad prediction. That's not a very tight prediction.

Let's test the r-squared value of your prediction. First, we have to map the usage. Under your sequence the total used energy by minute is 1, 2, 3, 4, 5, 25, 26, 27, 28, 29. Right? Under your 2.9/minute prediction, the next 10 minutes will be 2.9, 5.8, 8.7, 11.6, 14.5, 17.4, 20.3, 23.2, 26.1, 29. Same total usage at the end of the 10 minutes. The r-squared of this is 0.8. Not terrible, but not great either.

How about this sequence for 10 minutes: 20,1,1,1,1,1,1,1,1,20. Average is 4.8/minute. Standard deviation is 8! R-squared is 0.6 - pretty freakin' bad.

Compare your sequence, and my other sequence, to a tighter 10-minute sequence: 17,17,17,17,17,20,17,17,17,17. Average is 17.3/minute. Standard deviation is 0.9. R-squared is 0.999. Now that is something from which you can make a good prediction.
None of that matters. The drop over 10 minutes was 2.9 per minute.
If there had been two 20 spikes within a given 10 minute window the inpact would be a value of 49/10 = 4.9
I.e. About twice and exactly as needed/expected!

The purpose of the average is to average out the minute by minute measurements of 1/min and 20/min
 
What question are you trying to answer?
I'm stating that averaging usage over a wider window averages out the impact of brief fluctuations in high levels of activity. The overal variation from one microsecond to the next is irrelevant: to gauge average usage and thus to estimate (estimate, not predict) future battery life, one gets a less volatile estimate by averaging over a wider time period. The only disadvantage of a wider time period is that by definition it is less dynamic and slower to react.
But 10-15 mins seems more than reactive enough to me. The sliding window will mean that under sustained usage, the 10 minute average will gradually increment and will only take a maximum of 10 minutes to reach equilibrium.
 
I'm stating that averaging usage over a wider window averages out the impact of brief fluctuations in high levels of activity. The overal variation from one microsecond to the next is irrelevant: to gauge average usage and thus to estimate (estimate, not predict) future battery life, one gets a less volatile estimate by averaging over a wider time period. The only disadvantage of a wider time period is that by definition it is less dynamic and slower to react.
But 10-15 mins seems more than reactive enough to me. The sliding window will mean that under sustained usage, the 10 minute average will gradually increment and will only take a maximum of 10 minutes to reach equilibrium.
And how do you know whether this estimate of future battery life is useful or useless?
 
So I've waited to post in this thread until I did real world testing. Previous to this update, if I joined webex, and presented a powerpoint presentation for 40-60 minutes, I'd burn through 30% of my battery.

Today, I did the exact same presentation, for the same amount of time, and I burned 5% of my battery. There was also a Microsoft update which potentially had an impact.

In my previous complaining, I never used the "estimated battery remaining." It was always % battery I started at before task and % battery afterwords. I'm hesitant to say this resolved all my battery issues until I tested for a few more days, but as it stands, it sure looks that way.

Edit: This is on my 15inch with touchbar and fully upgraded graphics.
 
You are, that's total time on battery - I was on it for maybe an hour at a cafe. I've dropped Duet from auto-starting on load due to energy use and the fact that it's not something I really use when on battery anyways. Pathfinder is something I'd prefer to keep. I didn't have any non-background process running when testing that load - if I'm expected to close pathfidner, istat, dropbox, alfred, flux, etc every time I unplug because they're halving my battery life I don't see how people are supposed to do work on this for 10 hours. :/



Skimming activity monitor while real applications are open Coda 2 has an energy impact of 12 to 118 with a single gulp task running in a terminal tab (though that spike wouldn't happen often). Sketch uses 28-75 (and pops on my dGPU). Safari is generally on 10-16. Having some ~.5 and one ~3-4 energy impact process (pathfinder) should be within acceptable use.

Included Activity Monitor screenshot below of processes with a low of 7.7w when activity monitor wasn't running.

View attachment 678176

Killing everything except istat menus (on slow refresh, quit just closes preferences) and backblaze (bluetooth off, wifi on, screen ~75%) dropped me to 7.7w with an estimated little over 4 hours of battery life, using up around 5% of my battery in 15min closing applications, checking activity monitor, and firing up safari occasionally.

OP had > 9 hours of estimated use, and that's with Safari running (and presumably some other things like an email client, etc). I'm guessing there's some hardware flaw with my machine.
Is there something constantly tapping your dGPU? That's my only guess, seems like really high idle wattage otherwise, agree it seems like it shouldn't be like that...
 
Is there something constantly tapping your dGPU? That's my only guess, seems like really high idle wattage otherwise, agree it seems like it shouldn't be like that...

That'd make sense, but both activity monitor and gfxStatus show it switching to integrated when expected (and it was on integrated for all the time assessments here). Maybe it's still drawing power for some reason even when not reported in use? The only things that proc dGPU normally would be when Safari has some multimedia content or I'm in Sketch.

https://forums.macrumors.com/thread...on-macos-10-12-2.2021719/page-8#post-24072746 shows 6 hours of estimated life with a normal amount of things running after logging on/off - I don't think I've ever gotten more than around 4:30. I'm used to plugging, but this is slightly off putting as it'd be nice to park in a cafe and just not have to worry about battery if outlets are full etc. Having the CPU/GPU constraints for low draw but getting mediocre battery life doesn't seem quite worth it. ^^

update: Just unplugged and with a similar setup as before but with Sketch closed and on integrated graphics it's giving me 3:45 with 23w draw not really doing much aside from having an edit window open in Safari. I just switched to discrete and waited a bit and I'm now at 4:30 total with 16w draw. Using gfxStatus I switched back to integrated (which is mirrored in activity monitor) and I'm currently drawing 22.5w...? Total time dropped to 4:06.

Toggling between integrated and dynamic via gfxStatus (reflected in activity monitor, nothing open that requires dGPU) doesn't have any impact on power draw. It fluctuates between 16w and 23w with a standard amount of things open.

Restarted my laptop and turned off everything I could - drawing 6-9w with 98-99% CPU idle. Maybe once the discrete graphics turn on they don't turn off without a restart? Though I'm getting 3:18 remaining on a 92% charge - that's less time using ~1/3 of the power.

Update 2, (session 2 ~90%) drawing around 16w with a common amount of things open, 6:30 estimated time again.

Update 3, (session 2 ~65%) drawing 12w now, jumping between 4:30 to 5:00 estimated time.

I am running on the "more space" 1920x1200 equivalent, which should take some more resources to render.

// @KrayZier
 
Last edited:
FWIW I've always taken the battery life indication with a grain of salt knowing it'll shift with my usage, but if I'm going to be doing similar tasks it was useful to have.

I think Apple has missed something and feels it's user error vs a sporadic hardware issue or some hungry common background processes. I have iStat menus (slow refresh), so I still see it in my menu bar - but I can see some non tech literate people being confused by it.

That said my current activity monitor time remaining says I have 3:30 with a 6-9w draw and 4:30-6:00 with a draw ranging from 18-23w, so lol.
 
Last edited:
GUYS. Basic web surfing means nothing these days with poor battery life. My 2013 rMBP can just sit and browse a website with NO ads, NO videos, NO heavy images, and just a BASIC site and it will last about 8 hours. Visiting a site with a LOT of ads, videos, images, ... will make it last only 2 hours.

Yes, one time my 2013 rMBP only lasted 2 hours when I was looking at the Stardew Valley Wiki site while I was playing the game on a different computer.
 
I consider it to be useful. It lets me know how long, under my current recent average energy usage, the battery will last. That is a very useful feature.

Ok, but would you consider it to be useful if its was off by +/- 10 minutes? What if it was off by +/- 45 minutes? What if it was off by +/- 90 minutes? At what point does it stop being useful?
 
I don't think so, nor are you fooling anyone else by the looks of things. But on the positive side, your handle seems most appropriate!

Wow, that comment you're replying to was being sarcastic about the sarcasm. How deep does your embarrassment go that you could continually miss the obvious sarcasm and sarcasm on sarcasm? It's layered, but it's easy to see. Sad.
 
Ok, but would you consider it to be useful if its was off by +/- 10 minutes? What if it was off by +/- 45 minutes? What if it was off by +/- 90 minutes? At what point does it stop being useful?
There is no error. In my example, it is stating precisely the amount of time the battery will last given my current 10 minute average power consumption. This will only be different if my future usage alters - at which point so will the estimate.

Now, to answer the question you want me to answer: rather than +/- 10 or 30 mins it is only relevant as a fraction of the total amount of battery time left.

In this situation, +/- 10% would be perfectly acceptable. That means an estimate +/- 1 hour at full charge and +/- 6mins when down to 10% charge.
 
There is no error. In my example, it is stating precisely the amount of time the battery will last given my current 10 minute average power consumption. This will only be different if my future usage alters - at which point so will the estimate.
So if the "estimate" is reflecting current usage, and it changes as the usage changes, then it's really not an estimate of time remaining, right? It's a misnomer. Rather, it's a statement of present battery condition. It's basically telling you the percent battery remaining, but in a convoluted and less precise way. (e.g., you have 3ish hours remaining = 75% remaining).

Now, to answer the question you want me to answer: rather than +/- 10 or 30 mins it is only relevant as a fraction of the total amount of battery time left.

In this situation, +/- 10% would be perfectly acceptable. That means an estimate +/- 1 hour at full charge and +/- 6mins when down to 10% charge.
I agree. If an estimate deviates too much from reality, it's not useful, and a 10% deviation is not so good.

Fortunately we have tools to evaluate an estimate by calculating how much the estimate will deviate from the input data and how closely the estimate will conform to a normal reality.

Look back at my mathy post. Your example sequence of high fluctuations had a standard deviation of over 200% of the average! You said anything greater than a 10% deviation is not useful, yet if the average from your sequence were used to predict the next 10 minutes, it would presents a +/- ~40% deviation from reality! (roughly interpreting the r-squared value). My last example sequence of low fluctuations had a 5% deviation of the average, and that average would present a +/- ~1% deviation from reality.

So when you said the fluctuations within the sample don't matter when making an estimate, this shows they do in fact matter a lot. Average alone, without context, is pretty useless. Sometimes averages are good for estimations and sometimes averages aren't good for estimations - it really depends on the data that goes into the average.

That's pretty much what the r-squared value is designed to measure, of an estimate. How close is the estimate to normal reality? So an r-squared of .999 means the estimate fits almost perfectly with reality, and an r-squared of .6 means the estimate kinda fits but kinda doesn't. Again, this changes depending on how large the fluctuations in the input data are.
 
I'm not sure if someone else said this but the update messed up the battery icon. Yes I know that it was intentional to remove the time remaining section, but now the percentage icon is static. I stays at the same percentage even though the battery is draining. Not sure if my battery has improved but this basically makes the battery icon that Apple prvovides 100% useless. Doesn't tell how long I have or what the percentage is, wtf Apple!?
 
@MyopicPaideia @KrayZier

I've been breaking up my sessions testing things out (log out, restart, etc) but I've been on dGPU for a good chunk of this one and I'm within my usual 4-5 hour range. Background processes that have me idle high aren't taking up any significant amount of energy (according to activity monitor). I'm assuming that my dGPU is drawing power when I switch to integrated.
Screen Shot 2016-12-15 at 4.35.30 PM.png
 
  • Like
Reactions: KrayZier
Received my new BTO mac 13" with upgraded i5 and maxed out RAM. Had it a few days and was getting the full 10 hours and maybe more at times before update. Updated it today and it has been fine...I prob represent 90% plus of mac users as in I've more power than what I'll ever need to use and this machine is amazing. I'm starting to really get a feel for the touch bar and genuinely believe it has massive future ahead of it and can't wait for more 3rd party developers to utilize it. Just thought I'd let anyone on the fence know...It's pricey but I had the cash so don't shoot the messenger.
 
@MyopicPaideia @KrayZier

I've been breaking up my sessions testing things out (log out, restart, etc) but I've been on dGPU for a good chunk of this one and I'm within my usual 4-5 hour range. Background processes that have me idle high aren't taking up any significant amount of energy (according to activity monitor). I'm assuming that my dGPU is drawing power when I switch to integrated.
View attachment 678231
I think the dGPU is not switching back off or is erratically turning on and off. You might have to reset PRAM, NVRAM, and SMC. I can't think of what else could be going on
 
So if the "estimate" is reflecting current usage, and it changes as the usage changes, then it's really not an estimate of time remaining, right? It's a misnomer. Rather, it's a statement of present battery condition. It's basically telling you the percent battery remaining, but in a convoluted and less precise way. (e.g., you have 3ish hours remaining = 75% remaining).
I disagree quite strongly. 3ish hours left will only equate to 75% when the usage is high enough that 100% will give you 4ish hours. The time remaining estimate is one based on current usage, the % remaining is a physical measure of how much capacity is left.

With respect to the rest of your post, the poor fit you are concerned about is irrelevant to the average power drain over time. It would only be important if we actually wanted to estimate the high frequency fluctuating pattern. But we don't need to. I strongly suspect that the recent problems (erratic estimates) in fact came about precisely due to using a sampling window that was too short and thus, whilst more accurate at any given moment in time, was largely displaying a pointless (and perhaps confusing) level of finescale information due to the rapid power cycling of the processor.

As I have said many times now, simply averaging over a wider window of time will remove these fluctuations and provide a more stable long term estimator of battery life.
 
Last edited:
And yet the battery life on my early 2015 rMBP is gone way down. Less than an hour of basic web surfing with no graphics and I've gone from 92% to 79%. Ridiculous!
 
Trust me, it's no where near as silent - I have both. The 2015 model also has terrible cooling and throttling - it runs much slower on CPU intensive tasks as it has to keep throttling back to prevent overheating.

My 2015 is a dog with the fans too, they're always on, i've reset PRAM, had them replaced, nothing, its much louder than my 2013 was. But both are blown away by the thermal cooling and ahh TOTAL SILENCE of the 2016 model. It's a joy.
I have Intel Power Gadget installed and i have never seen CPU throttle under highest load and CPU temp doesn't go above 100 like it does on 2016. A little more silent, but heat will have an impact on the lifespan of the machine.
 
I have Intel Power Gadget installed and i have never seen CPU throttle under highest load and CPU temp doesn't go above 100 like it does on 2016. A little more silent, but heat will have an impact on the lifespan of the machine.

I disagree...

Messages%20Image%281833760167%29.jpeg

The 15" 2015 is renown for throttling - Skylake obviously helps, but the fans and cool is definitely superior in the new design.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.