Coil Whine Database: GPU, PSU & AIO Community Census

By LK Wood IV · Published 2026-08-12 · Updated 2026-11-04 · ~5 min read · St. Louis County, MO

The short version

This census links each owner’s observation to its part number and workload. It collects GPUs, PSUs and AIO pumps on an anchored 0–4 severity scale, with per-model distributions published only after five reports. There are 47 reports. They cannot tell you the odds that your next purchase whines.

If you are trying to locate a new noise, start with locating GPU or PSU coil whine before swapping parts. Its blank test log records the scene, cap and fan state before you file a report here.

The raw data, schema, and intake all live in the open repository: github.com/iBlessi/coil-whine-db (CC BY 4.0).

Why distributions, never verdicts

The defining fact about coil whine is the design constraint for the whole dataset: it varies unit to unit. The same GPU model ships silent units and screaming units, because the outcome depends on which inductors a particular board received, how they were potted, the PSU feeding them, and the load pattern — not on the model name. A review unit that stays quiet proves nothing about the unit you will receive, and one loud unit on a forum proves nothing about the model.

So the per-model answer is never “the RTX 4090 whines” or “it doesn’t.” It is a distribution: out of n reported units, this share was inaudible, this share was audible at the desk, this share screamed even at idle. That is what this database publishes: the distribution among reported units, not the odds for every unit sold.

The schema

One row = one physical unit an owner listened to. Full machine-readable definitions live in schema.json.

The severity scale (anchored)

Score the unit at its loudest normal state. The anchors are fixed on purpose: changing them would make old and new rows incomparable, so any future anchor change bumps the dataset’s major version instead of quietly redefining the numbers.

How to submit a unit

One report = one physical unit you own or owned, judged by your own ears — not a model you read about. A severity-0 report (“mine is silent”) belongs in the same denominator as an audible unit. We do not know what share of owners in either group chooses to report.

1. No git knowledge needed — fill in the coil whine report issue form. It mirrors the schema field-for-field; a maintainer transcribes accepted reports into the CSV, with submitted_date taken from the issue’s creation date and source_issue set to the issue number.
2. The CSV path — add one row to data/submissions.csv following the schema, and open a pull request. A stdlib validator runs on every PR and blocks malformed rows.

Every submission passes two layers before it lands: the mechanical schema check, and a maintainer review for outlier and troll patterns — duplicate-account bursts filing the same model at the same severity, impossible combinations like a purchase year before the model existed, and rows that summarize other people’s threads instead of a unit the submitter heard. The full acceptance rules are in CONTRIBUTING.md.

Capture a report someone else can compare

Copy the exact model and optional SKU from the box or label. A GPU family name such as RX 9070 XT does not identify the board, so when comparing a report with your own card, check the brand and board line before assuming that two products with the same chip have the same power circuitry or cooler. If the label is inaccessible, leave the optional SKU blank. Do not guess.

Use the noise test log to keep the game, repeatable scene, actual FPS cap, fan state and listening position together. It is a personal worksheet. Submit through the existing issue form or the schema above; its columns belong to a different format.

Put the most useful comparison in the form’s 280-character notes field. A format example is “Same menu with a 60 FPS cap. Closed case. Audible at desk. Fans stayed at similar RPM.” Replace those details with your own observations. That sentence is a format example and is not an accepted report.

The severity score remains the loudest normal state on the fixed scale. Record the quieter capped condition in the notes rather than changing what the scale means. If you have not tried a frame cap, leave that answer untested; a missing answer is different from testing a cap and hearing no change. If the source is unclear, use the diagnostic guide before assigning it to a component.

When comparing products, match the board line and available SKU first, then the workload. Read the original report.

The model counts below show how much evidence is available. They are not a shortlist of quiet or noisy products. Buying a model absent from this table does not buy you a known-silent unit.

Noise guidance and warranty questions

ASUS’s US graphics-card FAQ describes slight high-frequency noise as a component characteristic. Corsair’s US PSU support article explains inductor vibration and directs concerned owners to support. Neither decides an individual warranty claim. Check the terms for your product, seller and region, and describe the workload and noise when requesting service.

For diagnosis, AMD documents the effect of frame-rate limits on GPU power demand. A changed sound after a cap is useful evidence about that setup; it cannot by itself identify whether the GPU or PSU made the noise. Keep the PSU closed. Corsair warns that its capacitors can retain charge after unplugging.

What publishes as the census grows

The activation floor, stated verbatim: per-model n + severity distribution once a model has >=5 reports. Below that floor a model is listed as collecting, with its report count and no severity breakdown. As models cross the floor, their distributions render on this page with n first, then the share of reports at each severity level, always with the sample size in the same breath as the percentages.

From September 30, 2026 the graphics-card reports are also grouped by GPU name, across board partners, under the same floor: a GPU shows n and its severity distribution once it holds five reports. That is a weaker statement than a model’s own distribution, because the whine lives in the inductors a particular board got, and a GPU group mixes boards. So the GPU table sits below the model table, names the boards it holds, and never stands in for a model’s count.

The census opened at 0 rows by design. A dataset about unit-to-unit variance cannot be seeded from published reviews, because each review describes a single unit that is not ours to report. Every row is a real owner reporting a real unit.

Where the census stands

As of September 26, 2026, the census holds 47 reports from 40 graphics cards and 7 power supplies, spread across 44 models. Nobody has reported an AIO pump yet. No model has reached five reports, so every model in the model tables is still collecting, with no severity breakdown. One model has three reports and another has two. The rest have one. Grouped by GPU, one group has reached five: the RX 9070 XT, 5 reports across 4 boards, 4 at severity 2 and 1 at severity 3.

Readers filed 51 reports through the issue form between September 1 and 23, and I transcribed 46 of them. One repeated a card that was already on file. On September 15 I asked eight of the submitters one question each, and two answered within the hour. The owner of #48 agreed to a 3, the score for its loudest state above 1,000 fps, and the owner of #50 confirmed a 2 under gaming load. Three more answered by the next day, and two of those went in on September 26. #11 is a Corsair SF450, not the SF540 the form first said. #24 settled on a 3, which makes it the third MERC 319 on file. The owner of #37 named two different Sapphire lines and no longer has the card, so it was closed without a row. #52, filed on September 23, went in at a 2.

Four need one more detail from the person who filed them. Two of those give two different severities for the same unit, one may be fan noise, and one needs its model line confirmed. None of the four is in the data: #37 was closed on September 29 because its receipt names two different Sapphire RX 6800 boards and the card is gone, and the other three on September 30 after two weeks without an answer. Each goes in if its owner answers. Each row names its issue in the CSV’s source_issue column, and the Issues links below open the original reports.

Report #1 is still my own ASUS ROG Astral RTX 5080 OC. It scores 1, audible only in uncapped game menus and silenced by any frame cap, and it is the same physical card behind the Astral 5080 bench dataset. That card package now includes the same observation as reusable JSON and CSV, with its subjective method limits attached. Those files repackage issue #1 for card-specific reuse; the 47-row community census still contains one report for this unit.

Of the 40 graphics-card reports, 28 answered whether a frame cap changes the whine: 15 said it does and 13 said it does not. That is a count of answers from self-selected owners, not a rate for any model and not the odds a cap quiets your card; 12 left it blank, which the schema reads as untested.

Graphics cards (40 reports, 37 models)

Graphics cards by GPU (40 reports, 23 GPUs)

Power supplies (7 reports, 7 models)

The verdict rules

• No verdicts below n = 5. A model with three angry reports is collecting, not “a whiner.”
• Reports are self-selected. Annoyed owners may be more likely to submit a report, but the size and direction of the resulting bias are not measured here. A reported whine percentage is neither a population estimate nor a guaranteed upper bound. Reports of silent units add useful observations; they do not make the sample representative. The five-report publication threshold does not change that limit.
• Anchors never drift. The 0–4 scale above is frozen; a change would be a new major version, and old rows would be marked as scored on the old scale.

Use the data (CC BY 4.0)

The live dataset is one file: data/submissions.csv — one row per reported unit, in the schema order above. License: Creative Commons Attribution 4.0. Attribute as “TechFuelHQ Community Coil Whine Census” linking to this page.

A brand-new buzz paired with crashes belongs in the PSU failure symptoms guide rather than a census form. If capping FPS quiets your card and you want the deeper fix, the GPU undervolt settings database is the companion dataset. The GPU sag census measures card droop, while the GPU hotspot delta census groups same-session core and hotspot readings. They use the same published-floor rule for different things a graphics card does.

Change log

• 0.1.0 (2026-08-12) — schema, anchored severity scale, intake (issue form + PR path), validator, and the empty census opened: 0 rows, no seeded data.
• 0.1.1 (2026-08-13) — first accepted report: the maintainer’s own Astral RTX 5080 OC via the issue-form flow (issue #1 -> validated row). n=1; every model remains below the n>=5 distribution floor.
• 0.2.0 (2026-09-14): 41 reader reports from issues #2 to #51 transcribed, for 42 rows across 40 models. No model has reached n>=5. The CSV gains an optional source_issue column naming the issue each row came from.
• 0.2.1 (2026-09-15): two reports held for a clarifying question are transcribed after their submitters answered, #48 at severity 3 and #50 at severity 2, for 44 rows across 42 models. Six reports still wait on an answer. No model has reached n>=5.
• 0.2.2 (2026-09-26): three reports go in, for 47 rows across 44 models. #11 and #24 are transcribed after their submitters answered the clarifying question, #11 at severity 0 and #24 at severity 3, and #52 went in at severity 2. #37 named two Sapphire lines and waits on one more detail, as #2, #16 and #17 still wait on an answer. No model has reached n>=5.
• Page, 2026-09-30: the graphics-card reports are also grouped by GPU name across boards, under the same five-report floor; the RX 9070 XT is the first group to show a distribution, five reports with four at severity 2 and one at 3. The 28 frame-cap answers are counted on the page, 15 yes and 13 no. The dataset itself is unchanged at 0.2.2.
• Page, 2026-10-01: the four reports held for one more detail were closed without a row, #37 on September 29 and #2, #16 and #17 on September 30; each goes in if its owner answers. The dataset itself is unchanged at 0.2.2.
• Page, 2026-10-03: linked the card-specific JSON and CSV export of the maintainer’s existing Astral report. It is a reusable copy of issue #1; the census still counts that report once and its dataset remains at 0.2.2.
• Page, 2026-10-04: added a source-isolation guide, blank test log and exact-model capture guidance. Rechecked the public CSV: still 47 reports across 44 models, version 0.2.2. Replaced general warranty assumptions with current US manufacturer guidance. No owner observation or dataset row changed.