How to Tune PC Fan Curves in Windows 10, Windows 11 and Linux for Quieter Cooling

Shattered’s 12-step fan-curve guide outlines a sensible workflow: identify the hardware, measure its behavior, configure firmware, optionally add Windows or Linux software control, and repeat the test. The important qualification is that no temperature-to-speed table is universally safe, and a firmware curve is not a guaranteed automatic rescue system after software takes control. Fan Control’s own documentation makes hardware compatibility and firmware configuration explicit considerations.

The following procedure preserves that measured approach while separating useful tuning advice from settings that depend on your particular motherboard, cooler, and graphics card.

Before starting: scope and prerequisites​

This guide primarily targets desktop PCs. Fan Control supports Windows 10 and Windows 11, but its project documentation says laptop support is generally limited unless a model-specific integration exists. Installing the application does not guarantee that a computer exposes controllable fans.

Have these ready:

• Your motherboard and cooler manuals.
• A temperature and RPM monitoring utility compatible with the hardware.
• A repeatable workload representative of normal use.
• A place to record settings and results.
• Access to the original firmware settings so changes can be reversed.

Treat an hour as an initial tuning session, not a deadline. CoolerControl notes that calibration sweeps alone can take minutes per fan, and its generated profiles still require testing on the actual system.

Steps 1–3: identify, observe, and measure​

1. Map the fans before changing controls​

Shut down and disconnect the PC before tracing cables. Record which header serves the CPU cooler, case fans, radiator fans, and any pump. Use the board manual rather than assuming similarly named headers behave identically.

For firmware configuration, select the appropriate fan and control mode. ASUS’s PRIME/TUF B550 BIOS manual, for example, documents separate fan selection, PWM/DC selection, preset profiles, and manual adjustment. Those controls are an example—not a promise that every motherboard uses the same interface.

Keep pump settings outside the initial fan experiment and follow the cooler manufacturer’s instructions.

2. Confirm what the software actually detects​

Check that the intended temperature sensors and fan controls appear before building curves. In CoolerControl, the Hardware Support card explains detection results and reasons a channel may be uncontrollable. Its documentation is unequivocal: profile configuration cannot reach hardware the daemon cannot detect.

Use the same discipline on Windows: an RPM reading and a writable fan control are different capabilities. Fan Control describes itself as a layer over hardware libraries, so missing support is not necessarily a configuration error.

3. Record a baseline​

A practical editorial test routine is:

1. Let the closed-case system settle at idle.
2. Record the relevant temperatures and fan RPM.
3. Run a repeatable workload.
4. Record peak temperatures, sustained fan speeds, and performance.
5. Stop the workload and observe the cooldown.

Keep the workload, duration, case configuration, and approximate room conditions consistent for the second run. Write down which fan produced each RPM reading; one anonymous “fan speed” number is not enough for useful diagnosis.

This is a comparison method, not a claim that a particular duration certifies cooling safety.

Steps 4–6: design the behavior and configure firmware​

4. Choose sensors by cooling role​

Start with a relevant CPU temperature for the CPU cooler. For case ventilation, consider separate CPU- and GPU-driven curves combined through a maximum-output mix.

Both Fan Control and CoolerControl document mixing capabilities. Crucially, mixing curve outputs lets each component have its own temperature-to-airflow relationship before the controller chooses the greater demand. That is more deliberate than simply treating equal CPU and GPU temperatures as equivalent cooling needs.

For liquid cooling, select sensors and pump behavior according to the cooler’s supported controls and manufacturer guidance.

5. Build a gradual curve, then control oscillation​

Design three broad regions:

• Idle: reliable operation at an acceptable noise level.
• Working load: progressively increasing airflow.
• High temperature: a strong cooling response within the component’s documented operating limits.

Avoid copying an arbitrary “80°C equals full speed” endpoint across unrelated hardware.

Fan Control distinguishes hysteresis and response settings from output step limits. Its documentation provides separate Step up % and Step down % controls, while calibration identifies starting and stopping behavior. These are different adjustments: a temperature dead band is not the same thing as limiting how quickly the speed command changes.

A reasonable tuning objective is a prompt cooling response with a less abrupt reduction afterward. Do not add so much smoothing that sustained heat receives an inadequate response.

6. Establish workable firmware settings​

Configure the selected header, choose its control mode, apply an appropriate profile, and save the original settings before experimenting. ASUS’s documented QFan interface supports selecting a fan, choosing PWM or DC, and applying either a preset or manual configuration. Other boards require their own procedures.

Do not assume the BIOS instantly resumes control after an application crash. Fan Control’s own FAQ recommends avoiding competing firmware “smart” control and suggests a fixed default speed as a possible configuration. That differs from the blanket claim that an active BIOS curve always remains underneath software as an independent safety net. Follow the application’s guidance for the actual controller and verify normal startup and shutdown behavior.

Steps 7–8: configure Fan Control on Windows​

7. Pair and calibrate the controls​

Install Fan Control through its official distribution route, then identify the detected channels.

Its documentation specifies the order:

1. Pair a control with its RPM sensor, manually or through automatic pairing.
2. Run calibration.
3. Review the measured operating range.

Pairing is required for calibration. Calibration determines starting and stopping points and the relationship between percentage commands and RPM. Avoid running a heavy workload during a procedure that deliberately explores low fan speeds.

8. Create and assign the curves​

Create a graph curve for the CPU, another for GPU-related case-airflow demand, and a maximum-output mix where appropriate. Assign the intended curve through each control card’s curve dropdown.

Check the assignment, not just the graph: a carefully drawn curve accomplishes nothing if the wrong channel uses it. Fan Control’s documented minimum, start, stop, and step settings provide additional control over the resulting behavior.

Enable the application’s supported startup mechanism and verify that the configuration loads after a restart.

Step 9: use the Linux route appropriate to the machine​

CoolerControl separates its required hardware-control daemon, coolercontrold, from its optional desktop application. The daemon also supplies a browser interface on localhost, port 11987.

Its documented manual workflow is:

1. Create a Graph Profile.
2. Select the temperature sensor and shape the curve.
3. Open the desired fan channel under Cooling.
4. Apply the profile.
5. Reuse it on other suitable channels if needed.

Calibration deserves special attention. CoolerControl says it remaps the effective duty range, so existing profiles may need adjustment afterward. A displayed percentage should not automatically be interpreted as the same raw hardware command before and after calibration.

The older fancontrol route remains an alternative discussed by Shattered, but do not transplant its illustrative hardware paths or configuration file into another computer. Controller identifiers and supported interfaces must match the local installation.

Step 10: decide whether GPU control needs changing​

Leaving the graphics card’s existing fan behavior alone is a valid outcome. If you do change it, use one software controller for that task.

For supported hardware, MSI documents this Afterburner procedure:

1. Open Settings.
2. Select Fan.
3. Enable user-defined software automatic fan control.
4. Adjust the curve’s nodes.
5. Click Apply.

MSI also warns that Afterburner should be downloaded only from MSI or Guru3D because counterfeit distribution sites exist.

AMD’s Adrenalin documentation describes Fan Tuning, a Zero RPM option, and an Advanced Control temperature/PWM curve, with available features depending on the GPU. Zero RPM is intended to stop fans during light operation; its presence is not itself evidence of a fault.

There is another practical Windows consideration: Fan Control warns that applying AMD GPU fan settings through its integration can reset Adrenalin overclocking settings. Record any existing tuning before handing over GPU fan control.

Steps 11–12: prove the result and preserve it​

11. Repeat the baseline​

Run the same workload under comparable conditions. Compare:

• Sustained and maximum temperatures.
• RPM for each relevant fan channel.
• Speed oscillation during steady workloads.
• Cooldown behavior.
• Any performance loss or thermal throttling.

Success means acceptable thermal behavior and a better acoustic experience—not merely a lower average RPM. If temperatures rise unacceptably or performance deteriorates, restore the previous settings and investigate before lowering speeds further.

12. Test normal operation, then save​

Before considering the profile finished, check:

• A cold boot.
• A restart.
• Sleep and resume, if normally used.
• A sustained representative workload.
• A return to idle.

Save the configuration and record its sensor choices, header assignments, and software versions. Retest after changes rather than assuming an old profile remains appropriate indefinitely.

What the Python examples can—and cannot—prove​

Shattered’s accompanying curve.py is a behavior preview, not a hardware controller. Its fanlab.py generates synthetic demonstrations and offers a sensor-logging path. The demonstration numbers therefore do not establish a real reduction in noise or an improvement in cooling.

Code inspection also reveals a measurement limitation: the logger selects the highest RPM across all returned fans for each sample. That can switch between different physical fans, making its swing count misleading as a measure of one channel’s oscillation. Its preview also limits upward changes, so it should not be described as delivering an unrestricted immediate speed increase.

Use those examples as programming exercises, not validation results. For actual tuning, preserve individual channel identities and verify sensor availability on the target platform.

The winning fan curve is not the prettiest graph. It is the one that starts reliably, responds to the right heat source, behaves predictably after a reboot, and keeps the PC comfortable without narrating every background task.