Do the work.
Earn the idle.
Wake correctly.

Explore the PC: change what it does, then ask it to rest

A shop at night: the till can be quiet while the delivery door is still busy. Below is one modeled desktop. Change PC activity and watch which parts stay busy. Then Request a power change and see it enter, or see the exact rule that says no. Selecting a part only shows it; buttons act. A display turned off is not sleep, a core that is idle does not make the package idle, and a link carrying traffic keeps the package awake in this declared model.

Synthetic example machine, not detected from yours. The older, longer lessons and labs are on the reference page. Controls need JavaScript; the diagram and state list below read without it.

Event 0 of 0, X3, S0 working: Idle desktop: S0 working, nothing running.

The power states, and what this machine can do with each

Reference-only rows are explained, not simulated. S0i3 and S0ix are a platform's own hardware idle labels inside S0, never a synonym for S3. Sources: Microsoft system power states, Linux sleep states, ACPI 6.6. Hibernate here assumes the example machine has hibernation set up; a real one needs swap or a hibernation file. Arm64 profiles use their own vocabulary and never inherit x86 labels: Linux Device Tree and ACPI systems use PSCI for CPU idle and optional system suspend, and Windows on Arm uses Modern Standby with platform-defined idle names. Sources: Arm PSCI, Arm SCMI, Modern Standby, Intel S0ix terminology.

Compare: the same scenario on two machines, or your run against a baseline

Two machines can answer the same request differently, and the names they report differ too. Pick a scenario, two example machines and a boundary to line them up at. A column that cannot run the scenario says why instead of quietly doing something else.

16 rows shown; 3 differ. These are model runs, not measurements.

Capability and wake-report rows are examples of what each OS offers, from this model run. Nothing here measured your computer, and "same machine" is only claimed where the declared capabilities match.

1 Work, power, energy and time

Think of a car trip. A faster car arrives sooner, but may burn more fuel for the same trip. Voltage is the electrical potential difference that pushes charge; current is the charge flowing; power is the rate energy is used; energy is power accumulated over time; frequency is clock cycles per second. Clock gating stops selected switching, while power gating changes a domain's supply. Neither is the same as keeping its state, which is retention. Below, three fictional points each finish the same 100 units of correct work: speed is only worth something when the work is right.

Selected A. Predict: which finishes first, which uses less energy?

What this is based on: Linux OPP library, TI CMOS power note. Neither supplies the fixture numbers. Evidence type: teaching model.

2 Asking for a power change is not getting it

Order a pizza. The shop says "got it", then makes it, then it arrives. Each is a separate fact, and only the last one is on your table. Power management is the same: policy or client intent → supported driver or interface → firmware or controller → domain behavior → observation. That is an explanatory relationship, not a claim that every Windows or Linux operation uses one mailbox. RSMU is used here as Remote System Management Unit, an expansion supplied by this guide's author; no public source for a specific platform is cited, so treat it as unconfirmed.

1. Policy or client intentYou place the orderwhat software asked for
2. Driver or interfaceThe shop says "got it"the interface answered
3. Firmware or controllerThe kitchen makes itmay refuse or delay
4. Domain behaviorIt leaves the kitchenthe hardware changes state
5. ObservationIt reaches your tablea named counter or sample

Event 4 of 4, Observation: A sample is taken after the change, over a known interval. Conclusion: supported. A fresh sample shows B, as requested.

These events belong to the operating-point request phase before sleep; their sample is separate from the post-wake window.

What this is based on: Linux AMD PMC driver, v6.12, Linux amd-pstate, Linux HSMP (server), AMD-SMI overview, Community ryzen_smu. Evidence type: teaching model, with scoped public implementations.

RSMU and the mailbox: how a request reaches firmware

A hotel front desk with a pigeonhole. You do not walk into the kitchen: you write your request on a slip, put it in the pigeonhole, ring the bell and wait for the answer slip. Firmware that manages power on a Ryzen chip is reached the same way, through a small mailbox of registers: a message register (the bell), an argument register and a response register. RSMU is used in this guide for Remote System Management Unit, a name the guide's author supplied and no cited source confirms. The pattern below is the public one; the numbers are invented.

Step 1 of 7. Client: Wait for the last command. Poll the response register until it is nonzero. Zero means firmware is still working on something.

The response codes

What this is based on: Linux AMD PMC driver, v6.12, Community ryzen_smu. Evidence type: public driver source and community documentation, with an invented teaching model.

3 Which part is asleep? Power states by layer

A house has a "away" mode, a light in each room and a pump in the basement. Saying "it is off" is meaningless until you say what. A computer is the same: S states describe the system, C states a processor idling, P states active performance (modern CPPC, Collaborative Processor Performance Control, uses an abstract scale instead), D states one device and L states a PCIe link. Residency is time actually spent in a state, from a named source. Z is vendor terminology. They are scopes, not rungs of one "deeper sleep" ladder, and they coexist: a running S0 system can have an idle CPU and an active NIC.

• SThe whole housesystem: powercfg /a, /sys/power/mem_sleep
• COne room's lightprocessor idle: cpuidle residency
• PHow hard a worker worksactive performance: cpufreq, CPPC
• DOne appliancea device: runtime_status
• LThe pipe to ita PCIe link: ASPM

• System · ACPI S states

  Plain meaning

  S0 is the working state; a supported low-power idle system can spend time in very low-power conditions and still be in S0. S3 is a separate sleep path where the platform supports it.

  Example evidence

  Windows powercfg /a; Linux /sys/power/mem_sleep.

  Does not prove

  That any state was reached.

• CPU activity · P states and CPPC

  Plain meaning

  Performance while the CPU is working. Modern CPPC interfaces use an abstract performance scale and may not expose a simple ladder of P states.

  Example evidence

  Linux cpufreq policy and scaling driver (for example amd-pstate).

  Does not prove

  A voltage, or an exact delivered frequency: a performance request is not a voltage command.

• CPU idle · C states

  Plain meaning

  Processor idle states. Core and package observations are labeled separately.

  Example evidence

  Linux cpuidle counters; turbostat hardware columns.

  Does not prove

  That an OS idle-state name is a directly measured hardware residency.

• CPU package · residency

  Plain meaning

  How long the whole package spent in a package idle state: observed separately from any one core.

  Example evidence

  A named counter with its units and interval.

  Does not prove

  That the GPU, NIC or system were also idle.

• GPU and NIC · device D states

  Plain meaning

  Each device has its own power state. D3hot (power kept) and D3cold (power removed) differ and matter only in advanced reading.

  Example evidence

  Linux power/runtime_status (runtime PM status, not a direct reading of the hardware D state); Windows traces.

  Does not prove

  The state of the whole system.

• PCIe connection · link states

  Plain meaning

  The state of the link between two ends: a separate fact from either end.

  Example evidence

  Link power-state reports where exposed.

  Does not prove

  That the endpoint, package or system is asleep.

• Vendor platform · Z terminology

  Plain meaning

  Platform-specific. The one sourced example is the Ryzen 7040 public Z8 overview: AMD's public presentation names Z8 a deep low-power state.

  Example evidence

  That presentation, page 15.

  Does not prove

  A universal Z0 to Zn ladder, a control interface, or equivalence with S0i3. Other families and numbers are unknown until sourced.

State of what? Name the scope first; then ask what evidence belongs to it.

S0 low-power idle, zoomed in

Three names are often blurred. Windows S0 low-power idle (Modern Standby) and Linux suspend-to-idle (s2idle) are operating-system paths. A platform hardware low-power state (sometimes called S0i3) is a hardware result in that platform's own terms. S0i3 is not an ACPI system state. Entering the OS path does not prove the hardware got there.

What this is based on: ACPI 6.6 concepts, Linux system sleep states, Linux CPUIdle, Linux CPU performance scaling, Microsoft Modern Standby, Modern Standby SleepStudy, AMD Ryzen 7040 Hot Chips 2023, page 15. Evidence type: public specification and documentation; the diagrams are teaching drawings.

4 Watching a workload: what the evidence can show

A doctor does not diagnose from one number. Pick the claim, then pick the measurement that can settle it, over the same time window for every lane. Idle may include short background wakeups. Video can keep a media engine busy while the 3D engine rests. Graphics work raises demand on its engines. Bursty work alternates activity and idle. These are possible patterns, not guaranteed transitions or fixed frequencies, and CPU use alone does not decide a P, C or Z state. A failed wake means no post-wake window. After a successful wake, this example's NIC guard can withhold the selected job's CPU and engine fixture while an independent clock sample remains; idle background activity is not a completed job.

A media engine can be busy while the CPU and 3D engine stay light.

Linux: /sys/power/mem_sleep, cpuidle counters, runtime_status, suspend_stats.

The page never runs a command, reads your devices or sends diagnostics. Creating a report or trace on your own machine is a different step from reading a value, and you decide whether to do it.

What this is based on: Powercfg reference, Modern Standby SleepStudy, WPA Modern Standby analysis, ADLX GPU metrics, Linux system sleep states, Linux CPUIdle, Linux AMD debugging, turbostat v6.12 manual, AMDGPU monitoring. Evidence type: public documentation. The traces on this page are invented.

5 Waking from sleep to the desktop, step by step

Waking a hotel at dawn: the lobby lights come on, the kitchen starts, and the guests' doors unlock, but not all at once and not in a fixed order. Here the lanes are the system, the CPU, the GPU and display, the GPU's clock reading and the NIC. Pick an example and press Next step, reading across: each lane keeps its own known state. A visible desktop shows a working display path, not that every engine or every device is validated.

This example makes the NIC a prerequisite for the workload. Readiness allows submission; a checked result shows completion.

Step 5 of 5, Desktop. System: Interactive. NIC: Ready for traffic. Work gate: Open. Evidence: Correct work, checked.

What this is based on: Linux device power management, Linux runtime PM, Power management framework, Modern Standby versus S3, Windows Wake-on-LAN notes, Linux ethtool WoL interface. Evidence type: public documentation; this timeline is a teaching model.

6 What can we conclude from the evidence?

A courtroom does not convict on "he said he would". Here the claim is the target was achieved and useful work resumed. The run is the one you set in sections 2 to 5: its request, wake and readiness choices carry over, so a blocked wake can never read as resumed work. Predict, press Compare, and read the strongest statement the evidence allows. A contrary sample stays visible, a stale one stays inconclusive, and a check nobody ran stays unresolved.

supported: B was observed and this work resumed. Nothing broader is established.

Evidence type: teaching model. The record you can download is synthetic, its events are model ticks and its run IDs are local.