A network card's link is in its deepest low-power state: transmitters off, receivers off, reference clock stopped. A packet arrives from the network. The card must tell the host it has work, but the link it would normally use to say so is asleep, and nobody is listening on it. Waking needs a path that works while the main path does not.
How does a sleeping side get woken, and how fast does it need to be?
The obvious answer is to send a wake message over the link. In a light state, with the receiver still listening, that works. In a deep state, there is no receiver to hear it. Either part of the receiver must stay alive just to detect a simple signal, or a separate wire must carry the wake. And whichever path is used, the time to wake must fit within what the waiting traffic can tolerate.
Method | How | Cost |
|---|---|---|
In-band, receiver listening | Send a special pattern on the link; the partner's receiver detects it | Receiver stays powered: suits light states |
In-band, low-power detector | A simple, low-frequency signal (a beacon or electrical idle exit) that a tiny detector can sense | A small always-on detector |
Sideband wire | A dedicated wake signal outside the link | An extra pin; works in the deepest states |
Out of band through a controller | A power controller wakes both ends (for example on a timer or interrupt) | Needs a controller that stays on |
Each device has a latency tolerance: how long it can wait for service before something goes wrong (a buffer overflows, audio crackles, a deadline passes).
Each state has an exit latency: the time from wake to traffic flowing, including any retraining.
The platform must match them: only enable states whose exit latency fits within every affected device's tolerance; deeper states are allowed when devices say they can wait.
Either side may need to wake: the host to send work, the device to report it; both directions need a path.
Protocol | Wake |
|---|---|
PCI Express | From deep states, the sideband WAKE# signal or an in-band beacon; endpoints report their tolerable latency with Latency Tolerance Reporting so the platform can choose states (facts P34 and P36). |
USB | A suspended device may signal remote wake-up if the host has enabled it (fact S19). |
Energy-Efficient Ethernet | The transmitter leaves Low Power Idle on demand; the PHY's specified wake time bounds the delay (fact S18). |
DCLink | The controller wakes the device by dropping |
A board (illustrative) routed the device's sideband wake signal to a pin that was only monitored while the platform was awake. In the deepest sleep, the network card's wake requests went unheard and remote wake never worked. The fix was to route the signal to the always-on power controller, and to test wake from every sleep state, not only the lightest.
Its receivers and clocks are off, so nothing is decoding the link; an ordinary packet would not be heard.
Not while that device needs service; the exit latency exceeds its tolerance.
A sleeping link cannot carry its own wake-up; a listening receiver, a small detector or a sideband wire must.
Both directions may need to wake, and whatever hears the wake must stay powered.
Enable a state only if its exit latency fits every affected device's latency tolerance.