Windows 8 Connected Standby and AOAC

Question

I have some questions about Windows 8 Connect Standby.

1. Connected Standby is a new power state, and Mobile PCs can supprot Connect Standby, but does our Notebook and desktop both can support connected standby? My understanding is that Mobile PC is ARM-basing, is that correct?

2. What is the releationship between Connected Standby and AOAC?

3. If Windows 8 can only support Connected Standby on Mobile PC, how does Windows8 inplement AOAC on Notebook?

4. For WLAN/WWAN devices, they must support AOAC on Windows 8 ?

5. What is the differences between Intel AOAC and Windows 8 AOAC?

Answer 1

Connected Standby is a system-wide power state.  During Connected Standby, many devices are powered down, including network adapter(s).  In fact, from the perspective of the NDIS miniport driver, Connected Standby looks similar to a system sleep (S3) in Windows 7: NDIS sets a few wake patterns, then sends an OID_PNP_SET_POWER (e.g., D2 device state).  That's it.

Where Connected Standby is wildly different from prior OS releases is in usermode sockets.  In Windows 7, the OS would never put a network adapter into a D2 power state unless nobody is using it.  (Mainly if the system itself goes to sleep, or if an Ethernet NIC is disconnected).  But when in Connected Standby, the system will put the NIC into a low power state even if the NIC is being used.  The system will pretend that the NIC is still connected, and the system periodically wakes up to renew its IP address.  Critically, the system also plumbs a special wake pattern onto the network adapter.  If there is an incoming notification for that system (e.g., an incoming chat message), then the Microsoft notification service (a remote server) will send a matching packet to the system, waking it.  You might think of it as cloud-scale wake-on-lan.

To answer your questions:

1. Connected Standby will only be enabled on systems that are designed for it.  For traditional desktops / laptops, it's business as usual (sleep, hibernate, etc.).  The OEM has to put a special marker into the firmware to indicate that the system is designed for Connected Standby.  Because of this, any existing system today will not enter Connected Standby; only new systems released with and designed for the next version of Windows will use this feature.
2. Always-On/Always-Connected (AOAC) is the name of this feature.  Connected Standby is the system state that an AOAC-compliant system can enter.
3. See #1.
4. Not all drivers are required to implement AOAC.  However, if you want to sell your chip to an OEM that is manufacturing AOAC systems, then obviously you will need to meet the requirements for Connected Standby.  Also, if you intend to get a logo, note that there are big logo requirement changes for WLAN/WWAN even besides Connected Standby, e.g., Selective Suspend.
5. I'm not familiar with Intel AOAC.  I speculate that if Intel had been using "AOAC" prior to Microsoft's public discussion of AOAC at //BUILD, then it could just be an acronym coincidence.

If you haven't already, make sure to watch the //BUILD videos on Connected Standby:  HW-566T and HW-456T.

Answer 2

Hi Jeff, can you go into more details about what both Metro Apps and Win32 apps can/can't do while in the Connected Standby mode?

1. From the videos, it looks like Metro Apps can do some "background activities" -- What kind of activities are they allowed to do?  Disk I/O, memory modification, code execution?

2. On a Connected Standby enabled desktop, Pat mentioned Win32 apps are automatically "suspended" by DAM.  Can these apps perform any background activities?  Can they receive notifications? Can you define what "suspended" means -- is it more like S1 ~ S3 where states are maintained in memory, or more like S4 where things are written to a hibernate file?

 

Thanks!

Answer 3

I'm not super familiar with the user-mode side of things, so perhaps somebody else will chime in and add more detail than I can give.

Metro-style apps are fully suspended while the system is in connected standby.  When I say "suspended", I mean that the scheduler does not schedule any threads in that process, and the memory manager is more aggressive about paging out that application's working set.  This "suspend" is an evolution of the SuspendThread facility that exists in prior versions of Windows, so you can play with it on your Windows 7 machine right now: Process Explorer has a menu option that allows you to suspend any process (suspending a process is simply suspending each thread in the process).

Metro-style apps can register with one of several system-provided "brokers" that will resume the app.  When the broker's condition is met, the broker will exit connected standby and allow the app to run.  The app is limited in how long it is allowed to run, so you can't register a callback and use that as a pretext to perform 30 minutes of hard number-crunching.  The purpose of this time limit is to prevent apps from accidentally chewing up the user's battery.

Windows.Networking.PushNotifications is one such broker.  It wakes your app in response to a message from the network using a wake packet pattern (as I mentioned in the earlier post).

Classic Win32 apps are also suspended, but I'm not sure under what conditions (if any) the Win32 app will be scheduled on the CPU.  I think the kernel team might be fine-tuning those rules still, so anything I might say could be wrong tomorrow.  The high-level goal is to have the system stay "on" in Connected Standby for days at a time, so whatever apps do, their CPU activity will have to be strictly limited.

Answer 4

Connected Standby is a system-wide power state.  During Connected Standby, many devices are powered down, including network adapter(s).  In fact, from the perspective of the NDIS miniport driver, Connected Standby looks similar to a system sleep (S3) in Windows 7: NDIS sets a few wake patterns, then sends an OID_PNP_SET_POWER (e.g., D2 device state).  That's it.

Where Connected Standby is wildly different from prior OS releases is in usermode sockets.  In Windows 7, the OS would never put a network adapter into a D2 power state unless nobody is using it.  (Mainly if the system itself goes to sleep, or if an Ethernet NIC is disconnected).  But when in Connected Standby, the system will put the NIC into a low power state even if the NIC is being used.  The system will pretend that the NIC is still connected, and the system periodically wakes up to renew its IP address.  Critically, the system also plumbs a special wake pattern onto the network adapter.  If there is an incoming notification for that system (e.g., an incoming chat message), then the Microsoft notification service (a remote server) will send a matching packet to the system, waking it.  You might think of it as cloud-scale wake-on-lan.

I think it's important to mention that in order to implement Connected Standby, network adapter must maintain at least minimal level of connectivity at MAC level, otherwise the connection will drop. For that reason the device can't be completely powered down.

Regarding the D2 state - can you please elaborate a bit more? What are the OS considerations to choose between D2 and D3?

Answer 5

Right, during Connected Standby, the OS will enable wake patterns on the NIC; the NIC must trickle enough power to honor those wake pattern requets.  (This is no different from WoL on Windows 7 or any prior OS).

> What are the OS considerations to choose between D2 and D3?

Although it's kind of mysterious because it looks like a big black box, NDIS's power policy algorithm is really pretty simple.  In a nutshell, NDIS picks the lowest-power state that permits any active WoL patterns to work.  NDIS itself doesn't assign any semantics to D1-D3; those all come from the NIC and its bus.

To elaborate, NDIS decides the Dx state based on a combination of bus-reported capabilities, NIC-reported capabilities, and administrative policy.  The bus will say "This device supports D0, D2, and D3.  However, the device must be in D2 or higher to wake the system".  The bus's claims are all reflected in the DEVICE_CAPABILITIES structure that the bus generates.  Then the miniport adds its own commentary in the NDIS_PM_CAPABILITIES structure.  The miniport might say "I need D2 for packet pattern wake, but I can do magic packet in D3".

When NDIS puts this hypothetical NIC to a low-power state, NDIS checks whether any wake pattern is enabled.  If there are no wake patterns, then NDIS just picks the lowest available state: D3.  On the other hand, if the NIC must be able to wake the system (e.g., as in the Connected Standby scenario), then NDIS will dutifully pick the D2 state.  (Even though the NIC says it supports magic packet in D3, NDIS won't believe it because the bus says that the device needs at least D2 to wake.  Normally I wouldn't expect the miniport to contradict the bus like that, but I wanted to make the hypothetical example more interesting.)

The above discussion uses concrete D2 and D3 numbers, but they all come from the NIC and the bus.  NDIS doesn't hardcode any semantics to these D-states.  (The bus does hardcode semantics to each Dx state — see for example what USB thinks about device power states).

 

Answer 6

Right, during Connected Standby, the OS will enable wake patterns on the NIC; the NIC must trickle enough power to honor those wake pattern requets.  (This is no different from WoL on Windows 7 or any prior OS).

> What are the OS considerations to choose between D2 and D3?

Although it's kind of mysterious because it looks like a big black box, NDIS's power policy algorithm is really pretty simple.  In a nutshell, NDIS picks the lowest-power state that permits any active WoL patterns to work.  NDIS itself doesn't assign any semantics to D1-D3; those all come from the NIC and its bus.

To elaborate, NDIS decides the Dx state based on a combination of bus-reported capabilities, NIC-reported capabilities, and administrative policy.  The bus will say "This device supports D0, D2, and D3.  However, the device must be in D2 or higher to wake the system".  The bus's claims are all reflected in the DEVICE_CAPABILITIES structure that the bus generates.  Then the miniport adds its own commentary in the NDIS_PM_CAPABILITIES structure.  The miniport might say "I need D2 for packet pattern wake, but I can do magic packet in D3".

When NDIS puts this hypothetical NIC to a low-power state, NDIS checks whether any wake pattern is enabled.  If there are no wake patterns, then NDIS just picks the lowest available state: D3.  On the other hand, if the NIC must be able to wake the system (e.g., as in the Connected Standby scenario), then NDIS will dutifully pick the D2 state.  (Even though the NIC says it supports magic packet in D3, NDIS won't believe it because the bus says that the device needs at least D2 to wake.  Normally I wouldn't expect the miniport to contradict the bus like that, but I wanted to make the hypothetical example more interesting.)

The above discussion uses concrete D2 and D3 numbers, but they all come from the NIC and the bus.  NDIS doesn't hardcode any semantics to these D-states.  (The bus does hardcode semantics to each Dx state — see for example what USB thinks about device power states).

 

Thank you very much, Jeffrey. That was really helpful :)

Answer 7

Hi Jeffrey,

    Thanks for your patient reply. I've watched the videos about Connected Standby, but still have questions below, would you please help to give some suggestions?

1.       Connected standby is a new power state just for tablet, and only three power states are supported on these tablet? The implementation of AOAC is based on this new power state, right?

2.       I noticed that you’ve mentioned “The system will pretend that the NIC is still connected, and the system periodically wakes up to renew its IP address.” But the HW-566T shows “The NIC/Mobile Broadband adapter maintains basic L2 connectivity”. So my understanding is that the NIC is always really connected, not pretend. Is that correct?

3.       There are two kinds of Metro applications.

The first kind is able to receive live tile updates and toast notifications without background process while in Connected Standby. For these info update, the mobile PC do not wake up.

The second type of Metro apps is Metro RTC apps that can receive push notifications while in Connected Standby. For these info update, the mobile PC will wake up and alert user. 

The behavior just like a cellphone. Is my understanding correct for Metro apps?

4.       To support Window8 AOAC, I understand such requirements should be satisfied. Any other requirements?

a.       Specifical chipset. Provided by chipset supplier.

b.       Specifical WLAN/WWAN adapters, should meet MS logo requirement. Provided by WLAN/WWAN module maker.

c.       A set of Metro RTC applications. Provided by 3^rd party software supplier.

d.       Specifical marker in platform firmware. Provided by OEM.

e.       Windows 8 system.  Provided by Microsoft.

In fact I’m care about how to make a AOAC-capable system, such as the hardware and software requirements.

5.       Is Microsoft AOAC support a mandatory for Mobile PC or tablet?

6.       All above implementation are based on mobile PC or tablet, is my understanding correct?

As you mentioned, “For traditional desktops / laptops, it's business as usual”, so my understanding is that traditional Note-book do not support Win8 AOAC, right? 

Also I’m quite wandering the Win8 AOAC implementation on traditional Note-book, what is the AOAC strategy on traditional Note-book? Seems that above features can not support on traditional Note-book?

 

Any comments will be appreciated. Thanks a lot!

Answer 8

1.  Connected standby is a new power state.  It's premature to say that Connected Standby is "only for tablets", because who knows how computers will look 5 years from now?  But yes, you can think of it as being for new form factors.  I'm not sure which "three power states" you're referring to -- do you mean D0 - D3?

2.  Yes, you're right.  My use of the word "pretend" was too imprecise.  What I meant was that the kernel doesn't tell usermode that the network stack has become unusable.  Traditionally, as in Windows 7, when the NIC goes into a low power state, all TCP connections are reset.  From usermode's perspective, a D2 state meant that you get disconnected.  However, with Connected Standby, the kernel "pretends" that the NIC is still in D0 state.  TCP sockets don't get reset anymore, even though the NIC is in D2.  If a usermode process does send data while the system is in Connected Standby, NDIS will quietly drop the outbound data.

Of course, the NIC is actually connected, so there's no "pretending" about that.  The NIC continues to exchange whatever Layer2 messages are needed to maintain a connection (e.g., for WiFi, the NIC continues to respond to the AP).  And the OS periodically wakes the NIC to maintain Layer3 connectivity too (i.e., DHCP lease renewal).

3.  I don't know how the marketplace will divide up apps.

4.  At a high level, yes, that's what you need to make an AOAC system.

5.  I don't know what our system logo requirements will be.  However, I'm pretty sure that AOAC will not be required for "regular" laptops (so... depends what you mean by "Mobile PC").  If you're actually in the business of manufacturing systems and you want to get a logo, you should check with more official channels instead of the forum :)

6.  Even non-AOAC systems will see some battery-life improvements compared to Windows 7:

• We've worked really hard to reduce the number of times that the CPU wakes up on ALL platforms.  This includes a new "dynamic tick" for the system clock.
• We've gone through and inventoried all the "background optimization" tasks that used to be scheduled at odd intervals, and we've combined them all into a single "maintenence hour".  This reduces how often your harddrive has to spin up to do some routine maintenence.
• USB3 is much nicer about power consumption than USB2.  USB2 requires polling the bus for interrupts, which means a single USB2 gadget can keep the CPU awake.  Everybody talks about USB3's greater bandwidth, but its power savings over USB2 are possibly more important.
• And if you can't move to USB3 right away, NDIS (finally) supports USB selective suspend, so that a USB-composite WWAN adapter can go to sleep and allow the USB bus to sleep too.  This had surprisingly large power-savings when I measured it.
• And a more bunch improvements that I don't know about, of course :)

So traditional laptops have some things to be happy about too.

Answer 9

Hi Jeffrey,

Thanks for your so quick reply. You had help me a lot.

Yes, I'm in the business of manufacturing Notebook. And we are studying about this new tech ---- Windows 8 AOAC and we want to check the AOAC implementation requirements. About this tech, seems that there is no docs released from Microsoft yet.

1. "Just for Tablets" is compare with traditional notebooks. I supposed only three power state support on tablet (on, connected standby, off), like a cellphone.

5. May be we have different understanding about Mobile PC here. :) My understanding is that Mobile PC inculdes the devices like tablet. But Notebook is out of this range. :) As windows 8 can support ARM-based devices, X86 SOC, so for these tablet devices, is AOAC a must?

6. So for Windows 8 with Notebook, we will also get a better experience on battery-life. But how about AOAC feature? I mean does user can get the always on always updated experience? For example, in Windows 8 when Notebook wakes up from S3, does the user still have to wait for re-connect to network and then update data such email? Is there any strategy that the user can get fresh data durning sleep mode and when wake up from S3 they can find the network is already connected and the data have already updated? Or in one word, users do not have to wait?

Thanks a lot!

Answer 10

Thanks for your response Jeffrey.  One more followup question: In Andrew Ritz's slide, he mentioned "Wake patterns are a finite resource only usable by lock screen apps" (slide 10).  This seems to contradict what you said about *all* Metro apps able to receive push notifications in Connected Standby.  Can you please help clarify? 

Thanks so much for your answers.

Answer 11

I don't think I claimed that all apps can receive push notifications simultaneously :)

Andrew was referring to the fact that each push notification channel allocates a bitmap wake pattern on the NIC.  Because these wake patterns require dedicated registers on the hardware, they are scarce (ca. 4-16 of them per NIC).  If there is not enough space for another wake pattern, the miniport will reject the pattern.

Answer 12

You shouldn't get official information on designing logo'd systems from me; my area of expertise is just kernel-mode networking.  I've asked internally for somebody who can help you out with designing a logo-compliant system.

Answer 13

(contact information removed)

Answer 14

Hi Jeffrey,

    I've tried to sent an email to you  just now.    Not sure if I've sent with right address.

    Thank you very much for you help!  :)

Answer 15

I recently installed the Windows 8 Dev package on an HP Touchsmart.  I'm not sure of this but it seems that this box goes into the connected standby by default.  One problem is that when it wakes up I invariably have to go into the network trouble shooter and the trouble shooter has to reset the adapter.  It seems like the connected standby would be beneficial from an energy standpoint for desktops too.  Is there a config feature that I'm missing to keep from having to reset the adapter on wakeup?

 

Thanks

Answer 16

Your machine is not in Connected Standby, because no existing system supports it.  If it were in connected standby, the system would stay on, and only the NIC would go to sleep.

It sounds like the NIC is having trouble waking from sleep.  As a first step, check if there's a newer driver available.  If that doesn't work, you can try disabling power management on the NIC.  Go to Device Manager, NIC properties, Power Management tab and uncheck the "Allow the computer to turn off this device..." checkbox.

Answer 17

When the Cpu is in the inactive phase of connected standby, is it off (loses context), or just paused (clocks stopped, by context intact)? I want to know how much work is required to go from inactive to busy, while in connected standby.

Thanks

 

Answer 18

Hi Jeffery,
    Thank You for the wonderful write up on this. I was wondering if there are any API's to check if the system does support Connected Standby state and if the system does support say for future products if there are any APIs to switch to Connected Standby state from our Apps ?

Thanks,
Yash.

Answer 19

Generally, no.  Connected Standby should be transparent to apps.  Connected Standby is integrated with the push notification service, so everything should "just work" without apps having to directly manage it.

Answer 20

Hi Jeffrey,

I have a few questions relating to the new Connected Standby power state and it's use in commercial markets for client management. What I would like to do is wake a client up from connected standby and then perform IT admin tasks remotely e.g. install an application package, remove an application package, install updates etc. I'm sure this is possible but not exactly sure how this would be done...

I found the following reference in the Hardware Certification Requiremenst documentation

System.Fundamentals.Network.NetworkListOffloads

Target Feature: System.Fundamentals.Network

....

Feature	Requirement
No Pause on Suspend	Required
D0 offload	Required
USB Selective Suspend	Required- If USB based
Network List offload	Required
Wi-Fi PSM	Required
Wi-Fi Direct	Required
Radio Management	Required
WPS 2.0	Required
WoWLAN	Required

If Connected Standby requires WoWLAN can I just send a magic packet accross the network to wake the device and then do the admin tasks as usual? The only other option I can forsee is having a Metro App to act as a reciever to a pattern match and wake the device this way...

Thanks in advance...

Simon

Answer 21

When a system enters Connected Standby, the "normal" wake patterns are not set.  In particular, the NIC is not armed to wake for Magic Packet.  The system is instead armed to wake only when the Windows Push Notification Service (a server run by Microsoft in the cloud) wakes the PC.  Read more about the notification service.

This means that the best way to save power on AOAC-class machines is to integrate with WNS to push any needed updates to the clients as-needed.  But you might not have to implement that feature yourself; Microsoft is producing an enterprise management client for ARM-based machines that automatically checks for and installs/upgrades/uninstalls IT-mandated packages and policies.  Read more about the new enterprise management client.

Answer 22

Our customers are unlikely to be using Windows RT devices in the near future as desktop app compatability is a must. Given that devices will be x86 and on a local wifi network, why would I need/ want to use a cloud based solution? My company already offer network management software which has App management capabilities etc. All I really want to do is wake the device up from an AOAC state so the existing network management software can interact with the client. is WNS to only way to wake a device from a connected standby state?

Hope this makes sense.

Thanks, Simon

Answer 23

The cloud-based solution works no matter where the PCs are physically located (e.g., if the user brings the PC home, travels to a hotel, or is using WWAN).  The cloud servers save device battery by minimizing the number of wakes.  Unlike traditional PCs, whose network adapters can only support a limited number of wake patterns, the cloud servers scale up to dozens of apps, since the server aggregates all notifications into a single channel.

Alternatively, you can write a metro-style app that uses the background task framework to do work.  For example, you can create a background task that is triggered to run during "maintenance hour".  Be mindful that respecting users' battery life is critical, so the system will limit the maximum amount of CPU and network I/O that you can perform during any background operation.  (For the same reason, classic desktop applications are suspended during Connected Standby, and NT services are throttled.)

Answer 24

Hi Jeff,

I have some questions regarding Connected Standby,

1. How Can i make a system go to Connected Standby?

2. How can i verify a system has been to Connected Standby after resume?

Answer 25

The systems available for sale today do not go into Connected Standby.  This feature is only available on some new Windows 8 platforms.

If you are working for a Microsoft partner OEM who is manufacturing or testing these new platforms, you should talk to your internal Microsoft contact; a public forum is not the best place for this discussion.

Answer 26

which .net API my help me to check if system in Standby mode??

Answer 27

no such api exists

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 28

Hello Doron & the other MCCs MVPs and so forth:

Is there any way to completely disable Connected Standby? On my Windows 8 Clover Trail tablet, it's causing huge battery drain by not actually going to sleep when I press the power button on the tablet (happens every few days). While it would be preferable to actually find the culprit (i.e. the app or program that's keeping the device awake instead of letting it sleep), I'd like to restore Windows 7's standby behavior (i.e. true suspend to RAM) for the time being.

Is there any way to do this?

Answer 29

No, there is not a way to revert to the older standby behavior

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 30

Well that's unfortunate... how about a way to diagnose exactly which application(s) or service(s) is/are keeping the device from sleeping properly? Something similar to Android's listing the amount of CPU time used per process during sleep...?

Answer 31

bemymonkey, I too am having a similar issue with my Clovertrail tablet (Acer W510). The connected standby is draining approximately 2% battery per hour of sleep. I tried putting it in Airplane mode (wifi off) and that only drained 3% in 13 hours. Other users have reported improved battery conservation (1% per hour of sleep) with updated drivers, but none of those seem to be helping me.

See: http://community.acer.com/t5/Acer-Tablets/W510-battery-drain-fast-and-always-full-CPU-speed/td-p/28175/highlight/false/page/5

Doron, Is there some way for me to script my tablet to go into Airplane Mode on sleep and back out of it on wake? The battery situation is a major problem in a tablet form factor as I don't need to be connected if it's going to take such a toll on battery life.

Answer 32

2% per hour isn't so bad, tbh - I'm seeing something in the area of 4-5% per hour when the device is "stuck" in connected standby, and the device gets warm to the touch (warmer than it ever gets during actual use)...

Answer 33

Hi bemymonkey, I just solved my issue! It was the wifi driver after all! I posted this to the Acer forum, but I'll repeat it here in case it can help others.

The numbers:

• 83% @10:50pm
• 78% @5:45pm next day

= 5% over 19 hours = 0.26% battery drain per 1 hour of sleep

 My configuration:

• Latest Clovertrail firmware
• Latest Acer Drivers/Bios
• Downloaded latest Lenovo wireless driver
• Uninstalled all Broadcom related drivers from Control Panel -> Programs (there were 5 drivers - I didn't know what they all did or were, but didn't care)
• Uninstalled all Wireless device drivers from Device Manager (68, 76, 83 - everything)
• Rebooted (at this point, there should be no wireless connection)
• Installed the Lenovo driver
• Device Manager shows no missing hardware drivers everything looked good on reboot

These numbers are more than satisfactory for connected sleep performance. I probably still would prefer an option to have a "disconnected" sleep like Android allows, but this eliminates the battery anxiety of having to keep it plugged in all the time.

Not sure if this will help you at all but good luck!