Connected Standby & You
Connected Standby is an improved standby mode available on some Windows 8 (& 8.1) devices.
Connected Standby devices can generally out-perform most non-connected standby devices in terms of power consumption while actually getting a small amount of critical work done while the screen is off.
With Connected standby Windows devices get a lot of the benefit you expect from a mobile phone.
Things like inbound Skype calls even while the device is in your backpack (fantastic when you are travelling overseas because roaming on your mobile phone is very expensive).
Also, your content stays up to date while the device is off (email, live tiles etc.) & the device resumes from screen-off exceptionally quickly.
The bit i have really come to depend on though, is that while i wander around campus from meeting to meeting, building to building, the device is joining the appropriate wireless networks as i go.
As soon as i open the device in my next meeting the device is ready to go. There is no waiting to get on a network, watching the little connection status icon spin for what seems like eternity (to be fair it is 20 or 30 seconds, but zero is much better).
With Connected Standby as soon as i open the device, it is ready to go and my content is fresh.
I really like this feature and i miss it when i pick up a non-connected standby device for the day.
If you have time, this video explains it much better in 2 minutes or less:
[View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-01-70/What-is-Connected-Standby.mp4:0:0]
That's the cool parts of connected standby...
Up until 6 months ago i worked in a field role for Microsoft and i have been involved in a few conversations involving negative connected standby experiences.
At the time, i didn't really understand what was going on. In most cases I had the customer routed to the correct support people to work it through. But now, six months into my role in the Kernel team I wanted to share some of the information i have picked up along the way in hope that it will help you with any trouble maker devices.
The first thing i wanted to call out is: if you aren't getting good battery life on a connected standby device - something is wrong.
I can almost hear you saying "well done Captain Obvious!". But what i mean by that is, Connected Standby devices are engineered from the group up to be very good on battery, especially during standby.
If you bought a Connected Standby device, the hardware is more than likely the better stuff. Components like Memory of the DDR3-RS, DDR3L even LP-DDR3 flavor rather than normal PC-DDR. (will cover DRAM in another post shortly, or you can bing it). The device will most likely have low power networking components (both Bluetooth and WiFi, maybe even Mobile Broadband) and low power storage. The system most likely be designed around a low power SoC (System on a Chip).
If your device supports CS, you have a very good quality device in terms of hardware components.
(Want to be sure if your device supports CS? Launch an elevated command prompt and run "Powercfg /a". You are looking for output like that below)
Actually, for a quick detour: why wouldn't a device support connected standby?
The short answer is, its very difficult. But i gave a hint with the premium hardware comments above.
The hardware needs to be capable of supporting the new very low power states. At worst, the controllers must be able to deal with devices attached to the system that don't do well with low power. On top of that, the system as a whole needs to be able to communicate advanced power states to Windows through a driver called a PEP. The firmware of the devices often has specific modifications for low power activity. Generally speaking the device manufacturer needs to be thinking about CS right from the first blueprint.
Actually, a much better way to see what you might expect from the hardware is to watch this short video.
(Our team published these on MSDN only this week. They are short and interesting I promise):
[View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-01-70/DPM.mp4:550:0]
(The video is available with some follow up text is here: https://msdn.microsoft.com/library/windows/hardware/dn481230(v=vs.85).aspx )
The main point: Connected Standby begins as a hardware feature.
Windows checks if the device manufacturer considers the device to be CS capable during system boot.
Windows reads the system firmware on the way up looking for an AOAC flag (AOAC == Always On Always Connected). If the firmware doesn't say AOAC, Windows doesn't implement the connected standby features. (Your device manufacturer supplies the firmware).
Windows also checks a few things itself. One of which, is that the device uses a solid state disk (SSD). It does this by checking whether the seek latency on the disk is greater than 0ms. Remember that seek latency is the time is takes the disk to find (not retrieve) the information you need. On a rotational disk this involves getting the disk platter to where it needs to be, and moving the head to the right spot. This takes time. On an SSD, there are no moving parts just an array of storage locations - we get 0ms 'seek' time.
Anyway, we are off track... What can you do if you are seeing battery drain that is out of the ordinary?
The good news is that there was a big chunk of work done during Windows 8.1 development that will definitely help out.
The feature is called Sleep Study, and it is fairly easy to use and understand in most cases.
At its most simple, you just type: "Powercfg /sleepstudy" from a command prompt on your device. This will get you a HTML report which details where all your battery went and why.
The basics:
Up the top we get a graph showing all the charges and drains. Then we get a breakdown of every CS session over the last three days.
Each individual connected standby session has a hyperlink that leads to a more detailed section further down the document.
As an example, if i take Session 8 which shows me I lost 1% of my battery in 43 minutes and achieved a low power state only 89% of screen off time i could click for more detail:
In the example, I can drill in to see what things are going on in the background (BI == Background Infrastructure) and in the case i can see that there is some Skype, and some Windows Mail.
If i think about that, it makes sense that the network controller wouldn't go to sleep completely for about 8% of the time if i am doing a lot of mail and Skype.
I will do a full post on sleepstudy with some solid examples shortly but I hope knowing about it gets some issues solved/understood in the meantime.
Depending on what the sleepstudy tells you there are some actionable things you can do:
- For some things, there will be a valid explanation. Maybe you are syncing a lot of mail or roaming between a lot of networks. Even then, the drain shouldn't be ridiculous though. There are heavy constraints on what the system is allowed to do and when (see the "Introduction to Connected Standby whitepaper). If the system appears to be just running flat out, something is wrong.
- Update your drivers. Bad drivers will never do on a Connected Standby system. Keep in mind that a connected standby system relies on drivers and firmware to tell Windows when to be in the lowest power state. To give a really tangible example, consider you network card firmware. On a Connected Standby system the firmware contains a list of the types of packets that should be allowed to wake the CPU with an interrupt and ultimately the rest of the system (think of a Skype call: push notification packet). If the firmware is bad, the system wont do well in Connected Standby because it may be woken up for all kinds of non-important traffic that is floating around wireless networks.
- Make sure no drivers are missing. None. If you type "devmgmt.msc" at the start screen and find any yellow exclamation marks next to a device you have probably found the reason your battery is not doing well. The hardware components are tightly integrated on a Connected Standby system. One bad component may ruin the experience for an otherwise amazing device.
- Remove trouble maker applications from the lock screen. The applications configured as 'lock screen applications' on your system are allowed much more CPU and Network time during a CS session than others. As a test, remove any trouble makers you find using your sleepstudy report as a guide and see if Connected Standby gets better.
- Test with Airplane mode on. Just a test, not a long term solution. Airplane mode turns off the radio devices on the system. No radio devices, no inbound packets. Its a test that leaves the network interfaces in their lowest power mode. No roaming between networks, no push notifications. Its only a test though, if you find drastically improves the issue there is something unexpected going on that needs to be addressed.
- Test with "Quiet Hours". Background tasks and most notifications are suppressed during quiet hours. Default on Windows is 12 - 6am. See if extending this gives relief. Again, only for testing, not a long term solution.
Over the next few weeks i will cover off some more things like a detailed look at sleepstudy, some information about the guts of connected standby and try to keep a reference to any fixes i come across with either Microsoft updates or System Builder drivers and firmware if they are released.
For now, there is much more Information available:
Introduction to Connected Standby (Actually quite deep, originally for system builders):
https://msdn.microsoft.com/en-us/library/windows/hardware/dn481224(v=vs.85).aspx
Connected Standby User Experiences:
https://msdn.microsoft.com/library/windows/hardware/dn481217(v=vs.85).aspx
Applications and their impact on Connected Standby:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn481223(v=vs.85).aspx
Thanks,
Chad