Touchbar MacBook Pro battery drain while sleeping

This is still a problem as of 10.13.2. I was losing around 18% battery per day of standby on my 2016 15" MBP. I disabled Find My Mac and sleep battery use went down to 3% over 19 hours, only waking up a few times instead of every 2 hours.

I have the same problem too. MBP Touch late 2017

Same diagnosis, close everything, disconnect everything.

Have just disabled Find my Mac to see if that fixes it.

Thanks for the information to all in this thread.

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. http://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.

I have the exact same problem too and its a little ridiculous - Mine is waking up ever 30 minutes for some reason. Has anyone got a fix for this yet? I am going through my battery cycles like there is no tomorrow.

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]

I'm on 10.12.6 and have the problem.

Charged it to 100% overnight. Unplugged it at 10am, didn't use the laptop until 6pm and it had dropped to 42%

Nothing plugged into it during that time.

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.

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.

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

I feel the same. So I've restored everything (Unset NoMulticastAdvertisement and re-enable Find My Mac) and just let it wake for every 2 hours.

If I want it to sleep overnight, I just shut it down......

The 2 hours wake maybe some intended change as this provides higher chance for Find My Mac to try to work at every 2 hours. But then the standby mode is completely useless or even worse because it writes the RAM to disk every 2 hours once standby mode is entered......

But I still think that I should be able to control this myself instead of tweaking with mDNSResponder and disabling Find My Mac together to completely sleep my device.

Next step to study maybe to study the source code of mDNSResponder to see how could it masks the wake of ARPT and wake every 2 hours instead of anytime. (This makes the "Wake for network access" setting a little bit weird)

mine started to do this 2 days ago... have we found any solution to get it from draining?

weird part is i run your commands and most of mine look like it should such as the file isnt there or the mDNSresponder is 7198 but it repeats every 30 mins

Well guess what, I leave everything as last time (no tweak) and the tcp keep alive suddenly become inactive(2nd last line) and it had a good sleep today while I'm out! Magic! I could only assume that this issue is definitely related to the tcp keep alive "flag" of some active tcp connections.

(on the other hand, while setting NoMulticastAdvertisement to 1 and disabling Find My Mac and disabling wake on network access can guarantee to have perfect sleep)

2017-02-10 00:08:53 +0800 Sleep Entering Sleep state due to 'Clamshell Sleep':TCPKeepAlive=active Using Batt (Charge:100%) 7201 secs

2017-02-10 02:08:54 +0800 DarkWake DarkWake from Deep Idle [CDN] due to RTC/Maintenance: Using BATT (Charge:100%) 4 secs

2017-02-10 02:08:58 +0800 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:100%) 7201 secs

2017-02-10 04:08:59 +0800 DarkWake DarkWake from Deep Idle [CDN] due to RTC/Maintenance: Using BATT (Charge:100%) 7 secs

2017-02-10 04:09:06 +0800 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:100%) 7003 secs

2017-02-10 06:05:49 +0800 DarkWake DarkWake from Deep Idle [CDN] due to ARPT/Network: Using BATT (Charge:99%) 30 secs

2017-02-10 06:06:19 +0800 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:99%) 163 secs

2017-02-10 06:09:02 +0800 DarkWake DarkWake from Deep Idle [CDN] due to EC.SleepTimer/SleepTimer: Using BATT (Charge:99%) 4 secs

2017-02-10 06:09:06 +0800 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:99%) 3114 secs

2017-02-10 07:01:00 +0800 DarkWake DarkWake from Standby [CDN] due to ARPT/Network: Using BATT (Charge:98%) 30 secs

2017-02-10 07:01:30 +0800 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:98%) 905 secs

2017-02-10 07:16:35 +0800 DarkWake DarkWake from Deep Idle [CDN] due to EC.SleepTimer/SleepTimer: Using BATT (Charge:98%) 4 secs

2017-02-10 07:16:39 +0800 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:98%) 7228 secs

2017-02-10 09:17:07 +0800 DarkWake DarkWake from Standby [CDN] due to RTC/Maintenance: Using BATT (Charge:97%) 0 secs

2017-02-10 09:17:07 +0800 Sleep Entering Sleep state due to 'Idle Sleep':TCPKeepAlive=active Using Batt (Charge:97%) 7228 secs

2017-02-10 11:17:35 +0800 DarkWake DarkWake from Standby [CDN] due to RTC XHC1/Maintenance: Using BATT (Charge:96%) 5 secs

2017-02-10 11:17:40 +0800 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:96%) 3150 secs

2017-02-10 12:10:10 +0800 DarkWake DarkWake from Standby [CDN] due to RTC/Maintenance: Using BATT (Charge:96%) 0 secs

2017-02-10 12:10:10 +0800 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=inactive Using Batt (Charge:96%) 44997 secs

2017-02-11 00:40:07 +0800 Wake Wake from Standby [CDNVA] due to EC.LidOpen XHC1/Lid Open: Using BATT (Charge:95%)