Macbook 12 battery drain in sleep

It's rather fascinating that your response arrived exactly when I just finished my long troubleshooting run. And you are 100% right about what you just said.

The thing that we are observing is called "enhanced push notifications". It other words, it's exactly what you said - on "modern" computers macOS just lets apsd's TCP connection to be alive for another 12 hours with 2 hour wake-ups. This is called "enhanced" I guess.

Luckily, my rMBP 15" is not considered "modern" for some wicked reason by macOS. That's why it doesn't suffer from the issue.

So, what I've finally done. Let's go!

$ ioreg -l | grep IOPlatformFeatureDefaults

This is what I see on the mid 2014 rMBP 15":

"IOPlatformFeatureDefaults" = {"DNDWhileDisplaySleeps"=Yes,"TCPKeepAliveDuringSleep"=No,"NotificationWake"=No }

And that's what I see on the early 2015 rMBP 13":

"IOPlatformFeatureDefaults" = {"DNDWhileDisplaySleeps"=No,"TCPKeepAliveDuringSleep"=Yes,"NotificationWake"=Ye s,"TCPKeepAliveExpirationTimeout"=43200}

See the difference? Note that these are complete opposites to each other. The first one clearly states: "No sh$tty wake-ups and keep-alives!". The second one states: "I'm yours for 12 hours (43200 seconds)!"

The corresponding property lists reside here:

$ cd /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86Plat formPlugin.kext/Contents/Resources

$ ls -la

To determine your board-id, enter:

$ ioreg -l | grep board-id

In my case:

Mid 2014 rMBP 15 => Mac-2BD1B31983FE1663.plist

Early 2015 rMBP 13 => Mac-E43C1C25D4880AD6.plist

Now let's compare the two (they are in XML format):

$ diff Mac-2BD1B31983FE1663.plist Mac-E43C1C25D4880AD6.plist

[SKIPPED]

253a250,257

> <key>TCPKeepAliveDuringSleep</key>

> <true/>

> <key>TCPKeepAliveExpirationTimeout</key>

> <integer>43200</integer>

> <key>NotificationWake</key>

> <true/>

> <key>DNDWhileDisplaySleeps</key>

> <false/>

You can clearly see the same difference here.

Probably there's a simpler way to override these settings, but what I did was disable SIP (system integrity protection) in Recovery Mode to be able to modify the appropriate file (Mac-E43C1C25D4880AD6.plist in my case), back up the old version just in case and delete the aforementioned section in a text editor. For example:

$ sudo -s

# cd /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86Plat formPlugin.kext/Contents/Resources
# cp Mac-E43C1C25D4880AD6.plist Mac-E43C1C25D4880AD6.plist.bak

# nano Mac-E43C1C25D4880AD6.plist

Note: it should be some other plist in your case based on the output of "ioreg -l | grep board-id".

Voila! Worked for me. No more TCPKeepAlive=active when sleeping! 😁

P.S. Don't forget to enable SIP back to be on the safe side.

I'd also really appreciate if there was a more elegant way to achieve the same result (simple toggle to turn off "enhanced" notifications) without messing with the /System/Library folder because obviously some future update can wipe it clean. I spent hours researching for such a solution to no avail. These features are not even documented anywhere leave alone exposing controls over them.

Wow, great sleuthing! If this stuff isn't documented, how did you manage to find all that? Also, you refer to "enhanced push notifications" as if that IS a documented thing. Is it mentioned somewhere? And why does it even bother with keeping the session alive? Maybe it just saves some resources on the Apple server side.

I guess I still question whether this is all supposed to happen on battery power, and also the fact that you sometimes see the extra wakeups due to network events, which definitely doesn't seem right...

To find all that, I first grep'ed the whole /System/Library folder for words like "TCPKeepAlive", "TCPKATurnOff", "7200" and others that were common to our pmset logs. And then, depending on in what text or binary files they popped up, I followed further down to man pages, Google, etc.

Enhanced push notifications are indeed a documented thing: Enhanced notifications that can wake your Mac - Apple Support

In fact, they are one the causes that officially can wake your Mac from sleep: If your Mac doesn't sleep or wake when expected - Apple Support

So, no wonder here. As to whether it all applies to battery, I'm sure it does. But to be objective, I will run the Macs on battery today and see their logs tomorrow to confirm. Will report here.

As to other wake-ups, there is one distinct type of a wake-up that happens after *standbydelay* seconds on battery or *autopoweroffdelay* on AC (see your "pmset -g custom" output to figure these values out and whether they are supported by your model). This is when a Mac goes from Deep Idle (memory is powered) to Standby (memory is dumped to disk, i.e. hibernation). This what I have definitely seen in my logs many times. Not sure what other (network) wake-ups you are referring to.

Great stuff. Yes, I'm aware of the "standbydelay" processing whereby Mac goes into standby (hibernation), by default, every 10800 seconds (3 hours). I've seen occasional other wakeups, like

2016-10-24 07:35:50 +1100 DarkWake DarkWake from Deep Idle [CDN] due to ARPT/Network: Using BATT (Charge:33%) 30 secs

I can't think of any reason why any network event would wake up the Mac while on battery power. Don't see these that often, but they can come thick and fast at times, and at other times not at all.

Given that the mystery 2-hourly wakeups appear to be normal, I am now left with the fact that the increased frequency of wakeups seems to exacerbate the frequency of a nasty kernel panic on the 12" MacBooks, as discussed at http://forums.macrumors.com/threads/kernel-panics-on-macbook-12-9-1.1980359/ and https://www.reddit.com/r/applehelp/comments/4mq28o/macbook_retina_12inch_early_2 016_kernel_panics/. Hopefully my bug report with Apple will yield something...

Yes, I remember encountering some spurious ARPT/Network in older logs, but I haven't seen them since then. They can be well due to false reasoning in a race-condition. That is let's say a Mac wakes up for hibernation and immediately there is some pending network activity. The process picks up either event as a reason and logs it. Happens a lot because there's no need to be super strict and implement atomic logging. Nevertheless, it's just a guess...

I can officially confirm that now both Macs behave similarly on AC and battery. Now their "pmset -g log | grep due" output looks like this:

Early 2015 rMBP 13:

2016-10-28 22:45:30 -0700 Sleep Entering Sleep state due to 'Clamshell Sleep': Using Batt (Charge:86%) 10829 secs

2016-10-29 01:45:59 -0700 DarkWake DarkWake from Deep Idle [CDN] due to EC.SleepTimer/SleepTimer: Using BATT (Charge:84%) 0 secs

2016-10-29 01:45:59 -0700 Sleep Entering Sleep state due to 'Maintenance Sleep': Using Batt (Charge:84%) 31659 secs

2016-10-29 10:33:38 -0700 Wake Wake from Standby [CDNVA] due to EC.LidOpen/Lid Open: Using BATT (Charge:84%)

Mid 2014 rMBP 15:

2016-10-28 23:29:16 -0700 Sleep Entering Sleep state due to 'Clamshell Sleep': Using Batt (Charge:92%) 10806 secs

2016-10-29 02:29:22 -0700 DarkWake DarkWake from Normal Sleep [CDN] due to EC.SleepTimer/SleepTimer: Using BATT (Charge:91%) 0 secs

2016-10-29 02:29:22 -0700 Sleep Entering Sleep state due to 'Maintenance Sleep': Using Batt (Charge:91%) 29220 secs

2016-10-29 10:36:22 -0700 Wake Wake from Standby [CDNVA] due to EC.LidOpen/Lid Open: Using BATT (Charge:91%)

One wake-up for hibernation after 3 hours of Deep Idle and the rest is one healthy sleep in Standby till morning.🙂

Cool. What exactly did you change the plist to?

Out of interest, I left the MacBook to sleep with the lid open. Looks pretty disastrous!

It wakes every 900 seconds (15 minutes) and always from deep idle. Over a period of 20 hours it never went into standby state. Even after the 12 hour period when TCPKeepAlive is inactive, it still wakes every 15 minutes! Battery dropped 12% in that period.

Not sure what exactly you mean by what I changed the plist to. I thoroughly described what I did in this post: Re: Re: Macbook 12 battery drain in sleep . More specifically, I deleted the section that defined TCPKeepAlive* and other related parameters from the plist.

Yeah, your Mac's sleep with eyes wide open looks gross. Did you fiddle with it in any way? Did you make similar to mine or different modifications? What causes such behaviour?

"I deleted the section that defined TCPKeepAlive* and other related parameters from the plist". That's the info I was after. I wondered if you deleted/changed values or whatever. But now I see I didn't read carefully enough, and you already said you just deleted the whole section. Sorry about that!

I have never tested sleep behaviour with the lid open, only with the lid closed. I have made no changes to anything yet. It would appear that this is what happens when you sleep with the lid open. Not pretty. Be interesting to see if yours does the same thing, but I suspect you'd have to reverse your plist changes.

Out of interest, I could definitely try to run the Macs with the lid open to see what it looks like now. Do I just leave them without touching anything for a night?

You could try a "dry run" which means you just run commands to examine what your plist looks like without modifying anything. Btw, with SIP enabled by default, the system won't let you modify those plists anyway. Based on the assumption that such wake-ups are controlled by them, it could shed some light on your mystery.

Please also provide a full pmset log excerpt without grepping it. There you could see if it is still mDNSResponder or another process that schedules 15 minute wake-ups.

Yes, just leave the lid open. Once it's slept, if someone sends you a text message and you have Messages set up, you'll see the notification on screen. But regardless, it wakes up every 15 minutes, like this:

Sleep/Wakes since boot at 2016-10-28 19:21:36 +1100 :70 Dark Wake Count in this sleep cycle:1

UUID: 8D59A03F-8F33-4813-8237-CF78F6C579CE

Sleep/Wakes since boot at 2016-10-28 19:21:36 +1100 :71 Dark Wake Count in this sleep cycle:1

UUID: 1D2D5E59-39D2-4205-A052-0A0B6C21043C

Lots of stuff going on there! I see there is a parameter in the plist:

<key>NetworkTimerDelay</key>

<integer>900</integer>

Maybe that has something to do with it. I'm going to make the change to the plist now to delete that section you mentioned above, and see if that affects what happens on sleep with the lid open, as well as lid closed bahaviour.

Well a couple more days fiddling. Applied the fix. AC and battery mercifully sleep beautifully. Just the expected wake after 3 hours to go into standby mode. Then I put everything back to normal to see what was causing the 15 minute wakes on battery. Didn't do it anymore! Then I started investigating the effects of Do Not Disturb in System Prefs, Notifications. There's a switch in there to turn on DND when the display sleeps. Whichever way you put it, it doesn't affect the line in the plist section that says it's false. Must affect some other plist, but I don't know why it's in the subject plist at all. What's your switch set to?

Having the switch off means things like Messages wake the Mac up from sleep when the lid is open (the new enhanced notification functionality). Don't really know what use this is at all. You just see a fleeting notification before it goes back to sleep. Seems to be a slightly feeble attempt at making the Mac more like an iPhone. I was hoping that having the switch on would stop the new sleep behaviour, but no dice - even though I don't have Find My Mac on. You'd think with nothing set to wake from sleep, it wouldn't bother with all that tcpkeepalive stuff! Made me realise though the one side effect of the fix - Find My Mac won't find a sleeping Mac any more, and that is potentially useful. Battderfy drain with the lid open is pretty severe. I had around 9% in 8 hours. It was waking up for text messages, but seemed to wake up with network events a lot without those too, and never went into Standby in that time.

I'm going back to the fix now, mostly because I reckon the less wakes the machine has the less likely it is to get the kernel panic! Once SIP is off, you can copy the plist using Finder, and edit it using Textedit too...

Good to hear that the fix is helpful in your case too! 🙂

I believe DNDWhileDisplaySleeps in the system plist sets the default which can then be overridden in Preferences. Since I didn't change that toggle in Preferences, it's ON for both Macs.

As I see it, Find My Mac is the ONLY viable explanation why a Mac would want to wake itself up with the lid closed. None of the remaining cases where enhanced push notifications are supposed to work would wake a Mac with the lid closed. All of them are supposed to wake a Mac when it sleeps with the lid open. So, if you're like me who doesn't care about Find My Mac, you don't lose a dime applying the fix. It goes without saying though, Find My Mac will stop working after 12 hours of intermittent (unhealthy) sleep anyway. Although it could be useful for someone who lost their Mac in a huge mansion to find it in 12 hours, that's definitely not me.

As to why all the settings when turned off do not cumulatively stop the TCPKeepAlive=active behaviour, I believe it's because it's too complicated to programmatically manage this case reliably on different interdependent levels. It's like having a generator to shutdown when there's no demand for electricity in a house is relatively easy to implement. But having it to turn back on when someone turns on the light or a fridge wants to kick in is hard because a different kind of feedback is needed. It's much simpler to just leave it running. The same approach is with push notifications.

Ok, let us now consider this topic as solved.

DNDWhileDisplaySleeps is false in the plist, which to me means the prefs option is unticked. But I believe the default is ticked. So still unsure about that one!

Your thinking re the behaviour exactly mirrors mine. The only reason for the tcpkeepalive with the lid closed is for Find My Mac, and that itself is useless after 12 hours anyway. They must think the extra battery drain is insignificant, but to me it isn't. It's strange thinking indeed, especially when they go to the trouble of stopping the animation on the Time Machine icon to save power! Worse is when the lid is open. My MacBook wakes constantly if DNDWhileDisplaySleeps is off. Much more often than the number of real notifications. But I don't use that option and rarely leave the lid open anyway.

I'm going to update my case with Apple with these thoughts. But they've been very tardy getting back on this and the panic issue. Quite disappointing really.

Been fun debugging with you...

DNDWhileDisplaySleeps is completely absent from a Mid 2014 rMBP15's plist (Mac-2BD1B31983FE1663.plist) which potentially means that the default value is "true" since "enhanced sleep" is a new functionality starting Yosemite (or El Cap if one cares) that's built around derived plists. However, nothing stops it from being ticked by default in Prefs for all Macs. So, yeah, there's some dust here, I agree.

My pleasure, Sir! Please keep us informed if you hear anything meaningful from Apple on your case. Good luck!

That looks right. If it still doesn't seem to go into standby, maybe you should back off the mods to the plist and try again. The MBP may have different requirements...