Macbook 12 battery drain in sleep

Get used to it, battery drain on the macbook is pretty bad. If the diagnostic tool doesn't decent any problem, apple will not consider to look at your machine...

The culprit is Bonjour's announcements of services via Multicast DNS.

On macOS 10.12, run in the Terminal:

sudo defaults write /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements -bool YES

enter your password and reboot.

What else would turning that off affect though? I actually think it's the tcpkeepalive that's set up once you sign into iCloud. In Unix systems, that has a default timeout of 2 hours. But why does this ONLY happen on all 12" MacBooks, no other machines?

Personally, I have encountered this problem on my retina MacBook Pro 13". I also confirm that I personally researched for, found and tested the proposed solution. It has nothing to do with the TCP keep-alive mechanism which can't (and does not) involve any high-level services like mDNSResponder and energy management.

Interesting. What problem exactly did you see on the MacBook Pro? Was it waking up EXACTLY every 2 hours, on battery, even without power nap turned on? Do you know what the side effects are of turning off Multicast? That preference file doesn't seem to exist in that location on my Sierra system...

My theory about tcpkeepalive is that it's setting its own timer to wake the system up to do something like refresh the iCloud session.

Love to compare notes...

I respect your scrupulous approach to the problem, Stephen.🙂 Yes, my rMBP 13 was waking up EXACTLY every 2 hours on battery with NO power nap enabled. As to all the other questions, please refer to http://multicastdns.org/ and follow further links. As for me, I don't use Bonjour, so there are no adverse effects of turning off multicast advertisements.

In order to refer to the mDNSResponder manual page directly, enter in the Terminal:

man mDNSResponder

If you don't have man pages installed, you might need to install command line tools first. I don't see a problem here for the man who is ready to go the whole way. Am I right? 😉

Here is an excerpt from it to cut some corners for you though:

OPTIONAL ARGUMENTS

mDNSResponder accepts the following optional arguments:

-AlwaysAppendSearchDomains

Append search domains for multi-labeled Partially Qualified Domain Name as well as single-labeled Par-

tially Qualified Domain Name. This argument is not recommended because of the extra DNS traffic it gener-

ates and its adverse effect on battery life.

-NoMulticastAdvertisements

Prevent the system from advertising Bonjour services via Multicast DNS.

To cause mDNSResponder to run with these optional arguments when it launches on OS X 10.11 (El Capitan) and later, set the

AlwaysAppendSearchDomains or NoMulticastAdvertisements boolean keys to true in /Library/Preferences/com.apple.mDNSResponder.plist and

reboot.

I'm certainly interested in giving this a try. But why don't I see the plist in that location?

I'm pretty sure that's because it doesn't exist by default. I fail to see where you loose anything since you can always revert back by deleting a newly created .plist file.

Sure, I'll definitely try it. Just a bit confused as to why something like this doesn't have a default plist. I'll report back in A few hours...

Well, I've given this a try.

Firstly, disabling multicast advertisements means my MacBook doesn't show up under Shared in Finder on other Macs on the network, which is inconvenient. Must say, this surprised me a bit.

Secondly, disabling multicast advertisements stopped the Mac waking up every two hours - it now wakes up sometimes every few minutes! I have tested this a number of times. Enabling advertisements, the Mac wakes up every 2 hours with a wake reason of RTC/Maintenance. Disabling them, it wakes up very frequently with a wake reason of ARPT/Network. When it's waking up every 2 hours, I have seen the odd ARPT/Network wakeup in between, but nothing like as often as when advertisements are disabled. Here's a little of a pmset -g log with a few dark wakes. I just don't understand why a laptop on battery even keeps the wifi active so it can be woken up, let alone it actually waking up so often:

I must admit, I see a completely different picture. I can't check network sharing on another Mac right now, but I will check back on that a little bit later.

Out of personal curiosity, Stephen, I assume you don't have "wake for Wi-Fi network access" enabled, do you? And you also have the latest macOS Sierra (10.12) installed on a clean drive (not an update of a previous system), right? And the main question is what wi-fi access point you have. This is to see if we have equal or similar testing environments.

This all might be also interesting to know because I am in the process of setting up macOS 10.12 on my rMBP 15", and I'm going to compare how these two machines behave with and without this "fix" to mDNSResponder. I have an AirPort Express (gen.2) as a Wi-Fi AP now which can act as a sleep proxy whereas when I observed 2 hour wake-ups I was on a non-Apple Wi-Fi AP. So that's another thing I want to address in my comparison. Will get back to you when I have some results.

I just checked my pmset -g log, and I must say my picture has changed too.😟 Now I see my rMBP 13 waking up every HOUR (you probably will see the same if you look at what your Mac does at night) due to the same ARPT/Network reason. But the funny thing is that the hour interval is sporadic. Here is some logging output from the middle of the night. As you can see at the end, there is a delay when the Mac slept last (04:44) and when I woke him up (08:23).

Definitely unsatisfactory. I will roll back the setting now and see what changes.

Very frustrating! Yes, I almost see an hourly pattern, with lots of "noise" wakes in between. Your 4.44 wakeup is for RTC/Maintenance, which is what the other 2-hourly wakeups are for.

I'm on latest Sierra. I find the Sierra console log useless. Its verbose, you can't seem to go back in time, and has completely different information in it. You can't see what it's up to when it wakes up at all. "Wake for wifi access" isn't an option when you're on battery. The 2-hourly wakeups (with advertising enabled) happen on a completely fresh install, but only once you've signed into iCloud. When it wakes up, I can tell (on El Capitan), that the only thing it does is take up the keepalive session with the Apple Push Services Notification service.

I have all Airport Express/AirPort Extreme access points.

I have this (and the probably MacBook-specific kernel panics while asleep) raised with Apple support. I've sent them heaps of logs. Hopefully something will come of it...

Let me know how you go!

I know that there is no "wake on wi-fi" on battery. I asked that just to make sure we have similar settings.

My progress so far is almost zero.😢 I installed a fresh copy of Sierra on my rMBP 15" (mid 2014) with the same software and settings as on the previously mentioned rMPB 13" (early 2015).

Both computers sleep on AC. pmset -g log | grep "due"

A typical night of the rMBP 13":

2016-10-24 19:19:12 -0700 Sleep Entering Sleep state due to 'Clamshell Sleep':TCPKeepAlive=active Using AC (Charge:100%) 7200 secs

2016-10-24 21:19:12 -0700 DarkWake DarkWake from Deep Idle [CDN] due to RTC/Maintenance: Using AC (Charge:100%) 45 secs

2016-10-24 21:19:57 -0700 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:100%) 1734 secs

2016-10-24 21:48:51 -0700 DarkWake DarkWake from Deep Idle [CDN] due to ARPT/Network: Using AC (Charge:100%) 45 secs

2016-10-24 21:49:36 -0700 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:100%) 7200 secs

2016-10-24 23:49:36 -0700 DarkWake DarkWake from Deep Idle [CDN] due to RTC/Maintenance: Using AC (Charge:100%) 45 secs

2016-10-24 23:50:21 -0700 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:100%) 7200 secs

2016-10-25 01:50:21 -0700 DarkWake DarkWake from Deep Idle [CDN] due to RTC/Maintenance: Using AC (Charge:100%) 45 secs

2016-10-25 01:51:06 -0700 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:100%) 7200 secs

2016-10-25 03:51:06 -0700 DarkWake DarkWake from Deep Idle [CDN] due to RTC/Maintenance: Using AC (Charge:100%) 45 secs

2016-10-25 03:51:51 -0700 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:100%) 7200 secs

2016-10-25 05:51:51 -0700 DarkWake DarkWake from Deep Idle [CDN] due to RTC/Maintenance: Using AC (Charge:100%) 44 secs

2016-10-25 05:52:35 -0700 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:100%) 7200 secs

2016-10-25 07:52:35 -0700 DarkWake DarkWake from Deep Idle [CDN] due to RTC/Maintenance: Using AC (Charge:100%) 45 secs

2016-10-25 07:53:20 -0700 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:100%) 4282 secs

2016-10-25 09:04:42 -0700 Wake Wake from Deep Idle [CDNVA] due to EC.LidOpen/Lid Open: Using AC (Charge:100%) 181 secs

2016-10-25 09:07:43 -0700 Sleep Entering Sleep state due to 'Clamshell Sleep':TCPKeepAlive=active Using AC (Charge:100%) 156 secs

2016-10-25 09:10:19 -0700 Wake Wake from Deep Idle [CDNVA] due to EC.LidOpen/Lid Open: Using AC (Charge:100%)

A typical night of the rMBP 15":

2016-10-24 19:47:16 -0700 Sleep Entering Sleep state due to 'Clamshell Sleep': Using AC (Charge:100%) 48131 secs

2016-10-25 09:09:27 -0700 Wake Wake from Normal Sleep [CDNVA] due to EC.LidOpen/Lid Open: Using AC (Charge:100%)

I repeat. Same systems, same software, same settings, same fresh installations. Hopelessness filled every corner of the black movie screen. Credits follow. The End.

The only difference between the setups that I can think of is that I first installed Dropbox on the 13" driven by inertia. I yanked it off later as fully as I could (its launch agent, settings, caches, etc). Everything else is similar.

I also checked your theory that being logged into iCloud somehow keeps the apple push notification daemon's (apsd) connection alive. I logged out of iCloud on the 13" for one night to no avail. This theory can't be hypothetically complete because in this case, you should log out from every Apple service like Messages and FaceTime as well because they all rely on push notifications. I will try to disable "apsd" altogether to see if it plays any role.

Next steps that I'm going to make on the 13":

1. Disable "apsd" via launchctl and see if it interacts with wake-ups;

2. Fresh-install OSX 10.12 again on rMBP 13" to confirm or disprove that an environment matters;

3. Revert back to good ol' Mavericks.

#1 is easy to implement and doesn't cost much time.

#2 is relatively radical. I'd rather postpone it till I run out of all options.

#3 is due to growing hopelessness and frustration with how things are in Sierra and lack of response from the tech guys in this and other related threads.

Cool about the wake on wifi setting. Good idea to check, just in case it has a bearing.

To tell you the truth, it doesn't matter much to me what it does on AC. More important, obviously, is that it has the same behaviour on battery. I'm pretty sure I've seen similar behaviour on AC with other MacBook Pros, Airs etc, but none of them do this when on battery. But it sounds like your 13" rMBP does it too on battery. The 13" rMBP I've tried it on was late 2012, and that slept very soundly!

The thing about the iCloud signon is that the behaviour only starts after you sign into something iCloud-related, even just Messages. But signing out again doesn't stop the behaviour. You can, from memory, reboot, sign into a fresh user and it will sleep properly, until you sign into iCloud on that user. Strange, I know!

Now, a very interesting new finding! I'm on Sierra, so don't know if this was the case with El Capitan too, but probably was. When one of those maintenance sleeps happens you see something like:

2016-10-28 07:05:32 +1100 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:67%) 7230 secs

7200 secs is, of course, 2 hours. And it says TCPKeepAlive=active.

But now I find that EXACTLY 12 hours after the Mac is initially put to sleep, I get

2016-10-28 10:05:03 +1100 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=inactive Using Batt (Charge:67%)

TCPKeepAlive is now inactive, and the Mac stays properly asleep.

I don't know what to make of all this. Maybe Apple decided the newer Macs are energy-efficient enough to keep that Apple Push session active by waking every 2 hours, rather than setting it up every time, but only for 12 hours. Maybe it's only supposed to do this on AC and not on battery, where I believe wifi is left turned on too. I also don't know why you get spurious network wakes on battery either at times. But battery life certainly suffers more than it should during that initial 12 hour period.

Go forth and ponder!