Short answer
Fan RPM is revolutions per minute. Actual RPM is measured behavior; Target is a requested speed; minimum and maximum are hardware-reported bounds. Actual speed can lag or differ from Target while a fan accelerates or firmware chooses a safer response. On a fanless Mac, RPM is not zero. It is not applicable. A missing fan topology must never be converted into an assumed zero-speed fan.
Keep four values separate
| Value | Meaning | Common mistake |
|---|---|---|
| Actual RPM | The latest readable physical fan speed | Treating one sample as instantaneous proof of a fault |
| Target RPM | The speed currently requested by the active controller | Assuming the fan has already reached it |
| Minimum | The firmware-reported lower bound for that fan | Assuming every Mac can intentionally stop its fans |
| Maximum | The firmware-reported upper bound for that fan | Copying another model's RPM as a universal maximum |
Why actual RPM may differ from target
A fan has inertia and takes time to accelerate or settle. Polling also samples a continuous physical process at intervals. During a transition, Actual can reasonably trail Target. Firmware can additionally choose a safer, higher response than a requested lower target.
- Compare a short series of fresh samples, not one frame.
- Confirm which controller owns the fan while comparing values.
- Use each fan's own bounds; multi-fan Macs can expose different readings.
- Investigate a persistent substantial miss, not normal settling noise.
How a fan-curve percentage becomes RPM
A curve point expressed as a percentage should map into the discovered range between that fan's firmware minimum and maximum; it is not a percentage of zero. This lets one response shape scale across the individual fans in an already qualified topology without inventing fixed RPM numbers.
What a useful RPM investigation looks like
- Record exact model, fan count, each fan's reported range, and current controller.
- Reproduce a stable workload and watch actual RPM over time.
- On qualified hardware only, use a bounded timed target and allow it to settle.
- Return to System and verify ownership from fresh readback.
- Report persistent non-response, irregular noise, or failed handoff with diagnostics.
How Smart Breeze presents RPM honestly
Smart Breeze's fan rows separate Actual, Target, and Control. Targets are clamped to firmware-reported bounds and written targets are read back. A failed write requests an all-fan rollback; an interrupted helper path places macOS in control while Smart Breeze verifies fresh state.
That distinction is deliberate: a requested number is not proof of physical behavior, and a System button is not proof of ownership until the hardware state verifies it.
Sources and scope
Primary references and product scope
Apple sources define macOS and hardware behavior. Smart Breeze behavior is checked against the signed release and its documented safety boundaries. Where a conclusion is an inference or a method, this guide labels it as such.
- Smart Breeze safety modelSmart Breeze
- Smart Breeze compatibility and exact-model qualificationSmart Breeze
- Smart Breeze monitoring and control troubleshootingSmart Breeze
Requested is not actual
See fan speed with controller context
Smart Breeze separates the live speed, requested target, firmware bounds, and verified controller for every discovered fan.