Wake from S5: What PME, RTC Alarm and Wake-on-LAN Actually Do

The short answer

Most Wake-on-LAN confusion is not about Wake-on-LAN at all. It is about power states. People search for a fix, find a checkbox, enable it, and nothing changes 鈥?because the checkbox they changed belongs to a different state than the one their machine is actually in.

Here is the whole picture in one table. S5 is “soft off”: the machine is shut down, but the power supply still delivers a standby rail. G3 is “mechanical off”: no standby power at all, because the AC input is gone or the supply is switched off.

Two rules follow from that table, and they explain most real-world failures:

1. Nothing except AC restore works in G3. If the machine has lost AC input, no wake source exists, because there is no power to detect the event with.
2. S5 needs standby power, not “on” power. A mini PC on its original AC adapter almost always has a standby rail. A desktop on a switched-off PSU, or a machine behind a smart plug that cuts power, does not.

Why S5 is the state everyone means but nobody tests

S5 is what you get from a normal Windows shutdown. The session is closed, the disk is flushed, and the machine draws a fraction of a watt to keep specific circuits listening.

The complication is Fast Startup. When Fast Startup is enabled 鈥?and it is enabled by default on most Windows installations 鈥?a “shutdown” is not a true S5. Windows logs the user off and hibernates the kernel session, which is closer to S4. That single setting changes which wake paths apply, and it is why the same hardware can behave differently before and after a Windows feature update.

You can see which states your machine actually supports:

powercfg /a

If the output lists Fast Startup as active, your shutdowns are not clean S5. That is worth knowing before you spend an evening on firmware settings that govern a state you never actually enter. It is also the first thing our probability-ranked Wake-on-LAN causes page asks you to rule out, because it is free to change.

The three wake sources, and what each one really does

Wake-on-LAN magic packet

A Wake-on-LAN packet is a broadcast frame containing the target adapter’s MAC address repeated sixteen times. The NIC listens for it while the rest of the system is asleep, then asserts a wake signal.

What it depends on:

• The NIC keeps standby power in the target state.
• The firmware and driver advertise wake capability.
• The sender is on the same subnet, or something relays the packet across.
• The physical port you configured is the one with the cable in it.

That last point sounds trivial and causes more failures than any BIOS option. On our Beelink EQi12, two similarly named Realtek controllers exist. Configuring the unused one produces a perfectly configured machine that never wakes. The Realtek-specific setup walkthrough covers identifying the active adapter before you change anything.

PME 鈥?what “Power on from S5 by PME” actually means

PME stands for Power Management Event. It is a mechanism in the PCI Express specification that lets a device request a wake without the CPU being involved. The device asserts a signal, the chipset sees it, and the platform powers up.

In BIOS terms, options like Power on from S5 by PME or Wake by PCIe decide whether the chipset pays attention to those signals while the machine is in soft-off. With the option disabled, the NIC can still receive a magic packet and still see the pattern match 鈥?and then do nothing with it, because nothing is listening.

PME is the layer that most “the checkbox is enabled but it does not wake” reports fall into. It is also why a machine can wake reliably from S3 and never from S5: in S3 the operating system and driver are involved in arming the device, while in S5 it is firmware and chipset policy only.

RTC alarm 鈥?what “Power on from S5 by RTC Alarm” means

The real-time clock keeps running on standby power. An RTC alarm is simply a scheduled time at which the chipset should power the platform on.

This is the correct tool for a predictable schedule. A backup host that should be up every night at 02:00, or a machine that should be warm before you get home, does not need a network packet from another device. The RTC alarm needs no sender, no subnet, no broadcast delivery, and no second machine that has to be awake at the right moment.

Its limitation is equally simple: it fires at the programmed time and nowhere else. If you need on-demand startup, you want Wake-on-LAN.

Measured: what S5 wake actually did on our test unit

Everything below comes from a five-cycle test on a Beelink EQi12 (Core i3-1215U) running Windows 11 with Docker, Jellyfin, PostgreSQL and Redis. The raw evidence is published in our open measurement repository, eqi12-measurement-data under network/EQi12_S5鍏虫満WOL涓庡喎鍚姩_5杞粨璁?txt.

Container startup time after wake, seconds:

The method matters as much as the result. The sending machine broadcast magic packets to UDP ports 7 and 9 every fifteen seconds, the target performed a complete shutdown each round, and no one touched the power button. Each round was recorded on video so that the “off, link LEDs dark, then boot” sequence could be reviewed afterwards rather than assumed.

One honest caveat about evidence quality: powercfg /lastwake does not give a reliable wake source for a cold S5 boot, because there is no prior session to report against. That is why the conclusion rests on the sender’s continuous transmission log and five separate video recordings, not on a single Windows command.

S3 and S5 are not the same difficulty: a timing comparison

The S5 numbers above look excellent. The sleep numbers tell a more nuanced story. Here is the S3 cycle log, also published in the repository as network/EQi12_S3_WOL_5cycles.log:

All five cycles resumed. But cycle 5 took 4 minutes 53 seconds from sleep call to resume, against roughly 31 seconds for cycles 1 to 4. The recovery times after resume stayed tight; the delay was in the resume itself.

That is the reason our S5 works / S3 fails diagnostic rates sleep wake as 4/5 rather than 5/5, even though the raw pass count is five out of five. A wake method that works four times quickly and once after five minutes is not a reliable scheduling mechanism. It is fine for a machine you wake by hand; it is not fine for one that must be up when a backup window opens.

Recovery time differs by more than an order of magnitude between the two states: about 3.2 to 3.7 seconds for the network stack after an S3 resume, versus about 42 seconds average before the Jellyfin container was serving after an S5 boot. If your automation assumes the service is up as soon as the host responds to ping, plan for that gap.

How to check and configure each source

Check what your hardware and OS currently support, in this order:

powercfg /a              :: which sleep states are available
powercfg /lastwake       :: last recorded wake source (reliable for S3, not for S5 cold boot)
powercfg /waketimers     :: scheduled timers allowed to wake the machine
powercfg /devicequery wake_armed   :: devices currently armed to wake

powercfg /devicequery wake_armed is the fastest way to confirm you configured the adapter that is actually connected. If the list is empty, the operating system has no device armed for wake, and no BIOS setting will compensate.

Then verify firmware policy, because S5 wake is decided below the operating system:

ERP Ready deserves a note. It exists to meet European standby-power limits, and it does so by cutting standby rails. That is exactly the power Wake-on-LAN needs. If S5 wake will not work no matter what you enable, look for ERP before you look anywhere else.

The AMI BIOS walkthrough shows where these options sit on our test unit’s Aptio firmware, including the Chipset area where the PME option hides.

Pick the wake source for the job

Work down this list and stop at the first row that matches:

That last row is not a joke. Our measurements put a Docker-and-Jellyfin stack at roughly 12W at idle and about 13W during Intel QSV hardware transcoding, against 37W under sustained CPU load. The annual electricity difference between always-on and wake-on-demand is smaller than most people expect, and it is worth calculating before you spend a weekend on firmware.

When S5 wake works once and then never again

The pattern is distinctive and almost always has one of three causes:

• The first test was not from S5. With Fast Startup enabled, the first shutdown may have been a hybrid state. Later tests land in a genuinely different state and behave differently.
• Standby power disappeared. A smart plug, a switched PDU, a BIOS update that re-enabled ERP, or a power adapter swapped for a lower-rated one. The machine is in S5 but the NIC has nothing to listen with.
• The link never came up. At S5 some adapters negotiate at full speed and fail to detect the packet, which is why WOL & Shutdown Link Speed set to 10 Mbps First is a real fix and not a superstition. The adapter trades link speed for pattern-detection reliability in a state where speed is irrelevant.

If you want to work through it interactively, the Wake-on-LAN troubleshooter walks the symptom-first path and scores S5 and S3 reliability separately, because those are two different tests with two different expected results.

Where the boundaries of this page are

This page covers what the states mean and which wake source applies to each. It deliberately does not cover the full ranked fault list, the S3-versus-S5 symptom diagnosis, or the Realtek driver configuration, because those already exist and duplicating them would scatter the same answer across four URLs:

• Ranked causes and a five-run test protocol: Wake-on-LAN Not Working: 12 Causes Ranked
• Symptom-first S5 works / S3 fails path: Wake-on-LAN Works from Shutdown but Not Sleep
• Realtek driver, adapter identification and BIOS: Windows Wake-on-LAN on Realtek
• Automatic boot after power loss: State After G3 and AC Power Recovery

Verification standard

A wake mechanism is not verified by one success. Run five cycles from a known state, record the starting state, the link LED behaviour, the sender, and the time to service availability for each one. Our published results report the failures and the slow cycles alongside the passes, because the boundary between works and does not work is more useful than the fix.

All measured values on this page come from the Beelink EQi12 test unit and are reproducible from the raw logs in eqi12-measurement-data (CC BY 4.0). Behaviour on other hardware will differ; the state model and the diagnostic order will not.