801      iPhone_iPad_Mac_apple

Touchbar MacBook Pro battery drain while sleeping

I have read about reported problems with battery life on the new MacBook pros but mine seems a bit different.  Mine seems to drain battery while sleeping.  On my old MacBook Pro I could put it to sleep overnight and it would use minimal battery.  With this one on 100% charge when I wake it in the morning I'm sitting at about 70% remaining.  I do not have power nap enabled, any ideas?

I'm experiencing the same issue but mine will drain to as low as 60% some nights.  I also ensured that I have power nap turned off, all applications closed and all dongles removed.  I noticed that some of the dongles get hot while just being connected to the laptop (even if they aren't in use).  I guess those have some active circuitry that draws power at all times.

I am also seeing about 20-30% battery drain overnight in sleep mode on a Late-2016 15" MBP W/TB.  I'd love to hear any suggestions anyone has regarding this. 

I have been trying everything I can think of with no resolution.  I wiped / reloaded my machine.  I have removed anything that runs as a service.  I have been sure to shut down all apps before I close the lid.  Nothing seems to help...every time I put it to sleep it eats up quite a bit of battery.  I have owned several MacBook Pros, none of them used very much battery while asleep.

I'm with you.

So far the best I could find is that battery drain while sleeping is related to frequent(more than 0 user driven wake means frequent for me) wake up that is unexpected as a user:

uptime; pmset -g stats

0:24  up 1 day, 23:07, 2 users, load averages: 1.16 1.24 1.23

Sleep Count:86

Dark Wake Count:74

User Wake Count:21

Around 2 days without rebooting/shutdown and accumulated 74 "Dark Wake"! Although this is an extreme result due to my experiment. (setting "NoMulticastAdvertisements" to 1 for mDNSResponder and shortened standbydelay to 30 minutes on 2017-01-03 and reverted on 2017-01-04)

A ridiculously high bytes written (14.69 GB!) count from Activity Monitor:

Although this is a side effect after setting standbydelay to half an hour. The default setting is 3 hours.

Fighting with my first mbp a few days and here is the summary of my findings:

1. hibernate mode

By default it is 3, which means whenever the computer sleep, the used RAM(maybe the compressed one) will be written to disk. This is called "Safe Sleep". -> I'm sure I will never run out of battery or all of my previous laptop knows to enter hibernate mode at low power state even sleeping, I must disable it as I wonder if writing roughly 1 GB per sleep with a high number of Dark Wake will use up too much battery unnecessary.

2. mDNSResponder

It is one of the suspect due to this: (snippet of pmset -g log)

2017-01-04 17:05:48 +0800 Sleep                 Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:45%) 7228 secs

2017-01-04 17:05:50 +0800 Wake Requests         [*proc=mDNSResponder request=Maintenance inDelta=7198] [proc=powerd request=TCPKATurnOff inDelta=32430]

2017-01-04 19:05:50 +0800 Kernel Client Acks    Delays to Sleep notifications: [AppleIntelFramebuffer driver is slow(msg: SetState to 0)(538 ms)]          

7198 = 2h * 3600s/h - 50s-48s

This formula is true for other inDelta values.

Setting NoMulticastAdvertisement to 1 helps removing the RTC wake request by mDNSResponder. But....

3. ARPT/Network, DriverReason:WiFi.ScanOffload*

After(if you notice the date is 2017-01-03 here while 2017-01-04 for mDNSResponder above, this is because I unset the NoMulticastAdvertisement on 2017-01-04 for cross-verification) mDNSResponder no longer waking, ARPT/Network wake become very frequent when standbydelay was set to 1800 (other values may have the same effect too, not verified): (snippet of pmset -g log | grep -Ei 'reason|arpt|ec.sleep|rtc|entering sleep|maintenance sleep|EC\.[^ ]+|scanoffload')

2017-01-03 19:01:12 +0800 WakeDetails         DriverReason:WiFi.ScanOffload-Unspecified - DriverDetails:                

2017-01-03 19:01:42 +0800 Sleep               Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:47%) 754 secs 

2017-01-03 19:14:16 +0800 DarkWake            DarkWake from Standby [CDN] due to ARPT/Network: Using BATT (Charge:47%) 30 secs  

2017-01-03 19:14:16 +0800 WakeDetails         DriverReason:WiFi.ScanOffload-Group key handshake timeout - DriverDetails:

2017-01-03 19:14:46 +0800 Sleep               Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:47%) 325 secs 

2017-01-03 19:20:11 +0800 DarkWake            DarkWake from Standby [CDN] due to ARPT/Network: Using BATT (Charge:46%) 30 secs  

2017-01-03 19:20:11 +0800 WakeDetails         DriverReason:WiFi.ScanOffload-Unspecified - DriverDetails:                

2017-01-03 19:20:41 +0800 Sleep               Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:46%) 631 secs 

2017-01-03 19:31:12 +0800 DarkWake            DarkWake from Standby [CDN] due to ARPT/Network: Using BATT (Charge:46%) 30 secs  

:

:

(recurring)

4. XCH1/HibernateError (check it by pmset -g log | grep --color HibernateError)

This error start appearing when the swap file was disabled by setting the boot-args of nvram. It is harder to set on this new mbp 13" 2016 with touch bar probably due to the side effect. The side effect of disabling swap file is the XCH1 failing to hibernate which caused the failure of the IOBluetoothHostControllerUARTTransport driver and thus the death of bluetooth. I discovered this story because Apple Watch Unlock no longer working for me. It took a long way to find out the cause and fix it by resetting NVRAM.

The early conclusion based on many dog fights with my first mbp:

1. DON'T disable swap file until you find a way to prevent XCH1/HibernateError because your machine will have problem sleeping well and the bluetooth will become irresponsive.
2. hibernatemode 0 is okay, feel free to set it.
3. standbydelay SHOULD NOT be too short until you find a way to prevent the Dark Wakes.
4. DON'T set the mDNSResponder's preference NoMulticastAdvertisements to 1 until you find a way to prevent the ARPT/Network Dark Wake because things will just get worse!
5. pmset is our good friend, if anyone got more information about what it shows and how to dig more in details, please guide us to the paradise.

A few notes about reading pmset -g log:

1. Entering Sleep state due to 'X' where X can be:
   1. Clamshell Sleep - when the lid is closed
   2. Idle Sleep - when idled for sleep delay
   3. Maintenance Sleep - re-entering into Deep Idle or Standby state
2. (Dark)Wake from balhblahbalh due to X where X can be:
   1. ARPT/Network - ****, DarkWake related to WiFi, but why?
   2. EC.LidOpen - alright, wake by me
   3. EC.SleepTimer - standby time reached, hibernate!
   4. RTC/Maintenance - the clock set by software, most likely mDNSResponder in our case
   5. XHC1/HibernateError - argh, u got swap file disabled? Is your bluetooth still fine?

References that maybe helpful:

1. rMBP 2015 Wake Reason: ARPT (Network) (ahha, rMBP 2015 experienced the same, a temporary workaround is to turn off WiFi before sleeping the machine)
2. https://apple.stackexchange.com/questions/152305/disable-swapping-on-yosemite (any better way to disable swap file for Sierra? I have just tried the nvram one, may try those said for Sierra later...)
3. Enhanced notifications that can wake your Mac - Apple Support (some useful things, will Find My Mac cause wake by WiFi?)
4. If your Mac doesn't sleep or wake when expected - Apple Support (useful troubleshooting steps, try to follow it)

Lastly, I've disabled the "Wake for Wi-Fi network access" option in the Power Adapter tab to see if this affect battery use or not...good luck to me.

Update to the problem, disabling "Wake for Wi-Fi network access" indeed cause "Find My iMac" to show something different, but the ARPT/Network wake is still there.

So far the best workaround is like what has been discussed in rMBP 2015 Wake Reason: ARPT (Network) - disable Wi-Fi before sleeping. pmset -g log showed no wake at all. (Note that I have tried hard to make sure I have not turn on any feature that requires wake on wifi network access but I could have missed something)

BTW, I wonder if all of you have set the NoMulticastAdvertisement of mDNSResponder to 1? Because if mDNSResponder is waking every 2 hours, there will be much fewer ARPT/Network wakes.

To check this, run this in terminal (on a clean installation you should see something like file does not exist):

$ plutil -p /Library/Preferences/com.apple.mDNSResponder.plist

{

  "NoMulticastAdvertisements" => 1

}

$

Another way to confirm this is to run:

$ pmset -g log | grep =mDNSResponder

On a clean installation you should see something like:

[*proc=mDNSResponder request=Maintenance inDelta=7198]

Thank you for your responses on this.  I am going to try and turn off the WIFI before I put my machine to sleep the next couple of nights.  Let's see what happens.

I did a bit more experiment by disabling anything that might seem related and the good news is that after that without turning off WiFi, no wake at all except the standby one!

The bad news is that I need to:

1. Disable Find My Mac (even if Wake for Wi-Fi network access is disabled!)

2. Disable Wake for Wi-Fi network access (under the Power Adapter tab, I think this is a very confusing option which I expect it take effect only when the Power Adapter is plugged in)

I'm turning on more features(such as location service for Siri and send diagnostic ..) to see if any of them would trigger the problem again.

Finally noted the key signal:

TCPKeepAlive=active

If this is active then the machine will be waken and won't wake otherwise.

Then I searched through all pmset log and it looks the hypothesis of no wake if tcpkeepalive is inactive is not rejected.

The next step will be to find out what are the established tcp connections while all apps are closed and which process is responsible for it.

Thanks for the hard work.  It's so bizarre.  For the past couple of nights I have disabled wifi (and quit all apps) before putting the machine to sleep.  1 night I opened the next morning to 68% battery, the other 98% (both were from a 100% charge). 

I also struggled with this problem of 2 hour wake-ups. And I noticed the flag "TCPKeepAlive=active" in the pmset log.

For me, the fix was to disable "Find my Mac" in iCloud settings. After doing that, the flag changed to "TCPKeepAlive=inactive" and it is no longer waking up every 2 hours. Since I still want to use the Find my Mac feature, we need a different fix here. Running around with the feature disabled gives me an insecure feeling.

Thanks for your advices.

Under the latest Sierra, I am not able to add "NoMulticastAdvertisements" because the plist does't exist.

What can I do to create the file?

Just wanted to add that disabling "Find my Mac" has completely eliminated my battery drain issues; however, I'd like to have this feature so a better alternative would be preferred.

Hmm Find My Mac was already disabled for me.  Still have the problem.  I suppose I'll try enabling it and then disabling it, perhaps that will do the trick.

In fact I don't recommend setting 1 for NoMulticastAdvertisements because I doubt that it is a workaround to prevent frequent wakeup by ARP.

But if you would like to try, here it is (I'm on Sierra 10.12.2 16C68):

launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

defaults write /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements -bool $option

launchctl load /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

最后更新：2017-09-30 08:30:03

  上一篇： Old iMac died. How do I transfer backup of old ...

  下一篇： Where can I buy a replacement screen