From a0e675b3c89fa7a52457560f2743e878b0d67064 Mon Sep 17 00:00:00 2001 From: Rovey Date: Sun, 11 Oct 2026 18:20:46 +0200 Subject: [PATCH 1/2] docs: on the reference card the memory offset is decided by noise; hardware check 94 Three runs on one day applied +650, +1600 and +550. The two logged scans show the bandwidth rising in a straight line to +2450 and the first wrong result at +2550: there is no peak before the errors on this card, and the scan ends where two readings in a row happen to fall 1 % under a high one. Co-Authored-By: Claude Opus 5.5 --- docs/development.md | 1 + docs/hardware-checks.md | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/development.md b/docs/development.md index 7662aec..0722533 100644 --- a/docs/development.md +++ b/docs/development.md @@ -79,6 +79,7 @@ The applied offset is always at least one step below the confirmed edge. Profile | Without the bandwidth measurement the memory is left at stock | The search used to fall back to a climb on stability alone when the measurement failed at +0. On a tester's 3080 Ti (0.4.3) that climb went to +2300 MHz with the score falling from +2150 on, got its first wrong result there, and the machine froze with a corrupted screen in the 30 s confirm probes just below it. The first wrong result is no edge to stand next to: the memory was correcting errors for hundreds of MHz before it. Now a measurement that does not work means no memory overclock (`left_at_stock`), the run says so, and the core is still searched. `optimize` keeps the stability climb only for a caller that gives no measurement at all; the app always gives one. Why the measurement failed on that card is not known: the log was only in the window and went with the reboot. | | A confirm probe that is too hot at once confirms nothing | A confirm probe that ends `TOO HOT` keeps the clock edge: over 30 s the card may run a little hotter than over the power step's 20 s, and that is the soak's business, which lowers power. But the stress run stops at its first reading above the limit, so a card that is above it when the probe begins gives `TOO HOT` within a second, and that counted as holding too. It happened on the tester's RTX 3080 Ti (hardware check 91): after a driver reset the health probe loads the card at stock power, which on that card means 76 C against a limit of 75, and `confirm core +225` was confirmed by a probe that had tested nothing. Now such a probe counts only when the clock was loaded for `kConfirmMinS` (10 s, clearly longer than the 3 s probe that found the edge) before it got too hot. Otherwise the value is not confirmed, and the card rests (`io.rest`, the 20 s of a recovery, with the fans where the curve last put them) before the next try one step lower: without the rest every lower value would start just as hot, and heat alone would step the edge down to nothing, which is what keeping the edge on `TOO HOT` was for. The same value is not tried again; one step is the price. Not changed: the health probe still runs at stock power, and a soak that begins too hot still lowers the power limit by a step. | | A profile that promises speed keeps no result that is slower than stock | Best of my GPU ended 3.8 % slower than stock on the tester's RTX 3080 Ti (4749 against 4937 it/s, hardware check 91), with the fans at 80 % instead of 66 %, and showed it as **Done**, applied and kept at every logon. Every step had done what it is for: the card runs 83 C at stock with its fans at 100 %, the profile allows 75, so the power limit went to 65 %, and +150 MHz of core clock did not win that back. But a profile called "the best of my GPU" that leaves the card slower has not done what it says, and a result like that is not offered as one. After the soak, `optimize` compares its score with the measurement at stock that went before the run (the "before" the result screen shows, so the rule judges by the number the user sees): below `kNotSlowerScore` (0.99: one percent is what two five-minute runs differ by) the run ends as a failed one does, at stock, with nothing saved, and says what it found, why, and that Undervolt is the profile for a card that runs warm. `Objectives::faster_than_stock` marks the two profiles this holds for, Best of my GPU and Max performance. Not Quiet and Cool & efficient, which trade speed for noise and heat and say so. Not the overclock step of All in one either: it goes on to an undervolt and a fan tune, and its result is judged as a whole; whether that whole may be slower than stock is not decided. This is a backstop, not the cure: what such a card needs from these profiles is in `docs/planned.md` ("never hotter than at stock"). | +| Open: on the reference card the memory offset is decided by noise | Three runs on one day applied +650, +1600 and +550 (hardware check 94). The memory search assumes that bandwidth peaks before the memory makes errors (`kBandwidthDrop`: stop at a reading 1 % below the best, re-measured once). On the reference RTX 4070 it does not: bandwidth rises by about 0.4 % per 50 MHz step all the way to +2500, and the first wrong result comes at +2550. The readings scatter by 0.4 to 0.7 % (standard deviation), so two readings in a row 1 % under a high one happen by chance, and where that happens is where the scan ends: at +1000 twice, not at all once. When it does not happen the search stands next to the first wrong result after all, which is what the bandwidth method exists to avoid; the tie rule and the margin still put the applied offset 950 MHz below it. Nothing is changed yet. What a fix has to decide: whether a card like this should get a memory overclock by another rule (a fixed share of the range the scan covered, or of the offset of the first error), and how a real peak is told from scatter on the cards that have one (several readings per step and their median, or a drop that holds over more than one step). | | Open: why the bandwidth measurement fails on some cards, and what then | On the tester's RTX 3080 Ti it failed at +0, and since 0.4.4 that means no memory overclock at all on such a card, though it computed right far beyond +2000 MHz. The measurement gives a number only when three runs in a row agree within 1 % (`kBwSettle`), and it throws away every run the driver's timer calls disjoint (the clock changed under it). That card was held at a power limit of 65 % and ran at 83 C when it was measured; the reference card has only ever been measured at 105 %, where the measurement itself draws 179 of 210 W. So the suspicion is the power limit, and hardware check 90 tests exactly that on the reference card. What it shows decides what is built, and nothing is built before it: **(1) runs are thrown away as disjoint, and the ones that are kept agree:** the timer is what fails, not the card. Time the copy differently (wall clock around a flush, or count a disjoint run when its neighbours agree) and keep the method. **(2) the readings themselves scatter by more than 1 %:** a peak that is found by a 1 % drop (`kBandwidthDrop`) cannot be found in that noise. Then the memory has to be measured where the card is not held back: search it before the power step, at stock power, where a probe and its measurement last five seconds; or take more readings and compare medians. **(3) it does not fail at 65 % on the reference card:** the power limit is not the cause. Then it was the heat (a card throttling at its temperature limit changes clock as well), or another program, and only the tester's `run.log` can say: since this change a measurement that never settled writes how many runs gave a reading, between which values, and how many were thrown away. In no case does the climb on stability alone come back. **Outcome of check 90: (3).** On the reference card the measurement gave a number fifteen times out of fifteen at 100, 80 and 65 %, in three or four runs, with nothing thrown away, and the bandwidth was the same at every limit. The power limit is ruled out; (1) and (2) are not built. What is left is the heat of that card, another program, or a timer query that failed, and the tester's `run.log` is the next thing that can tell them apart. **The tester's run (check 91): it is (2), but only inside a run.** Twenty readings between 763.9 and 821.2 GB/s, none thrown away, three seconds after the load began; after thirty seconds of load the same card read within 0.2 %. The suspicion now is the moment, not the card: the measurement is taken while the power limiter is still catching up. If `gao --bandwidth --after-load 3` scatters on that card and `--after-load 30` does not, that is it, and the fix is to measure when the card has settled (keep taking runs for some seconds instead of twenty runs), not to change the method. | | Every line of a run is also in `run.log` | `logged()` wraps the log hook of both front ends: a line is appended and flushed before it is shown, so the step a machine freezes in is the last line on disk. One file in the state folder, moved aside at 1 MB (`run.log.old`). Only elevated and only after `ensure_app_dir` has verified the folder: an elevated process appends to nothing a user could have put there. | | A run does not start while the NVIDIA app's Automatic Tuning is on | Switched on, a service of the driver scans the card when it sees fit: it loads it, changes its clocks, and starts again by itself (hardware check 89: a scan that was stopped started again 14 ms later, and after a restart of the service it resumed within two seconds). A run next to that measures nothing it can trust, so it is refused, like a run next to Afterburner, and with the same weight: a courtesy, not a guard. Read from where that service keeps the switch, `%ProgramData%\NVIDIA Corporation\nvtopps\nvtopps.db3`, table `ocScannerSettings`, fields `backgroundScanEnabled` and `grdOcEnabled`, joined to `TelemetryGpuCfg` so that only a card that is in the PC counts (a row of an earlier card can never be switched off again). That this is the source and not a copy of it was measured, not assumed: with the field set the service took the scan up again after every restart, with it cleared it did not, while the NVIDIA app itself showed the switch as off. Nothing documents the file. So: opened read-only and immutable (no lock, the service never waits for us), through `winsqlite3.dll` from System32 (no dependency added), and everything that is not exactly as expected reads as "unknown", which starts the run as before. The registry value the app sets next to it (`HKLM\SOFTWARE\NVIDIA Corporation\Global\NvApp\OC\`) changes at the same moment but belongs to the app, not to the service, and is not used. **The overlay is not checked:** no setting for it was found, its processes run whether it is open or not, and the one value that moved (`IsShadowPlayEnabled`) followed the service being up, not a switch. NVAPI was not tried: an undocumented call is no better than an undocumented file, and it cannot be compared with anything. | diff --git a/docs/hardware-checks.md b/docs/hardware-checks.md index d61d03d..056f866 100644 --- a/docs/hardware-checks.md +++ b/docs/hardware-checks.md @@ -121,7 +121,7 @@ root; adjust the path for a Debug build. | 91 | A whole run on a second card: the tester's RTX 3080 Ti Founders Edition | v0.4.5, **Best of my GPU** from the window, MSI Afterburner closed; the result screen and `run.log` sent by the tester | yes | the run gets through, the memory search never goes past where the bandwidth stops rising, and `run.log` says what happened | Pass for the run, with three findings (2026-10-11, from `run.log` and a picture of the result). Stock stopped at 86 C after 159 s with the driver's fans at 66 % and the run went on. Power: 65 % (73 C; 70 % read 80 C). The journal held the earlier freeze: `a previous run froze the machine at mem +2200; staying below it from now on`. Memory: `mem +0: bandwidth 795.5 GB/s`, then at +50 `bandwidth did not settle within 20 runs: 20 readings from 763.9 to 821.2 GB/s (spread 7.5 %)`, so the scan ended with +0 and nothing was thrown away for a clock change. Core: stable to +285, `DEVICE LOST` at +300, the driver came back (reconnect, 20 s rest, health `STABLE`), confirmed +225, applied +150, soak `STABLE`. Result: power 65 %, core +150, memory +0; 4749 it/s where stock scored 4937 (-3.8 %), 73 C instead of 86, 226 W instead of 287, fans at 80 % instead of 66 %. **Finding 1:** inside a run the bandwidth readings of this card scatter by 7.5 % within about a second, where the same card read 815.9 to 817.6 GB/s after thirty seconds of load (check 90). The measurement comes three seconds after the load starts; the confirm probe below drew 302 W in its first second at a limit of 227 W, so the power limiter had not caught up yet. Not confirmed. **Finding 2:** `confirm core +225 / mem +0: TOO HOT ... peak=76 C power=302 W` ended within a second, because the health probe after the reset runs at stock power and had heated the card to 76 C; a confirm probe that is too hot counts as holding, so +225 was confirmed by a probe that tested nothing. The soak at +150 did run its five minutes. Changed since: a confirm probe that is too hot before the clock was loaded for ten seconds does not confirm, and the card rests before the next, lower try (see the decision "A confirm probe that is too hot at once confirms nothing"). On a card: not run yet; it needs a driver reset on a card that runs hot. **Finding 3:** the result is slower and louder than stock, as the open design point in `docs/planned.md` expects for a card that is above the profile's 75 C at stock. | | 92 | The undervolt profile starts with the measurement at stock every run uses, and a hot card is not refused | Elevated, the tray app exited, a copy of `gao.json` kept. (a) `gao --undervolt` to the end; then `gao --status`. (b) The same with a test build whose stock limit is lowered to a temperature the reference card passes under load (63 C; it reaches 67). Put the copy of `gao.json` back. (c) Only on a card that is above the profile's limit at stock with the fans at 100 % (the tester's RTX 3080 Ti: 82 to 83 C): the **Undervolt** profile from the window, to the end, and its `run.log` | yes | (a) `the card at stock, five minutes`, a `stock: STABLE ...` line with the driver's fan speed, then `baseline: the measurement at stock`, and no second five minutes at stock: the first candidate follows at once; no `candidates are stopped at` line; `RESULT:`; `before:` shows 300 s and the fan speed the driver chose. (b) `stock: TOO HOT ... peak=64 C`, the line that the measurement stopped there, the cool-down, then `baseline: the measurement at stock` and a search that runs to `RESULT:` with `before:` showing the shortened time; no `candidates are stopped at` line, because 64 C is under the profile's 75. (c) no `not stable at stock`; `the card reached 86 C at stock: candidates are stopped at 85 C, not at the profile's 75 C`; candidates that end `STABLE` or `WRONG RESULT`, none `TOO HOT`; a result that is cooler and draws less than stock at the same clock | First run: **not as expected**, and that found a fault (2026-10-11, reference RTX 4070, driver 617.42, a test build of d1c99e9, started elevated by a script). The first halves held: (a) `stock: STABLE ... peak=65 C fan=70 %`, then `baseline: the measurement at stock` four seconds later and no second five minutes; (b) `stock: TOO HOT ... peak=64 C`, stopped after 34 s, the run went on, no `candidates are stopped at` line. But both runs then ended with `the card held no undervolt: the first step below its own voltage already failed`: their first candidates read `1070 mV (+15 MHz): SLOW ... clock=2323 MHz` and `1050 mV (+15 MHz): SLOW ... clock=2411 MHz`, on a card that ran 2791 MHz in the measurement just before. The search's load had not run yet when that candidate began (see the decision "With its reference handed over, the undervolt search warms its load up before the first candidate"). Second run, with the warm-up: **pass** for (a) and (b) (same day, a test build of 0733695). (a) `stock: STABLE score=5426 it/s clock=2788 MHz peak=66 C fan=70 %`, four seconds later `baseline: the measurement at stock`, `warming the load up: 5 s at stock`, `target: 2790 MHz, which the card reaches at 1090 mV by itself`, and the first candidate `1085 mV (+15 MHz): STABLE ... clock=2775 MHz`; 26 candidates, none `SLOW` or `TOO HOT`, the edge at 950 mV, `RESULT: 2790 MHz at 990 mV instead of 1090 mV`; `before:` 5426 it/s, 189 W, fan 70 % (300 s), `after:` 5325 it/s, 149 W, fan 53 % (300 s). (b) `stock: TOO HOT ... peak=64 C`, stopped after 74 s, the run went on, the same warm-up and a search to the same result (990 mV, edge 950 mV); `before:` shows 75 s; no `candidates are stopped at` line. The saved tune of before the test was put back and applied. (c) not run. | | 93 | A speed profile that would end slower than stock keeps nothing | Only on a card that is warmer at stock than the profile allows (the tester's RTX 3080 Ti; the reference card ends faster than stock with every speed profile): **Best of my GPU** from the window, to the end; the result screen, the dashboard and `run.log` | yes | the run goes through all its steps and its soak; then **Not applied** with `the result is slower than stock: N it/s against M (-X %)`, the power limit it had to go down to, and the pointer to Undervolt; `The card is back at stock.`; the dashboard shows stock and the saved tune of before the run, if there was one; `run.log` ends with `stopped: the result is slower than stock ... -- card restored to stock` | Not run yet. On the reference card: nothing to see, by design. | -| 94 | All in one, with the undervolt step searching for the first time | Elevated, the tray app exited, a copy of `gao.json` kept: `gao --optimize all` to the end with a build that has the warm-up of the undervolt step; then `gao --status`; put the copy back | yes | five steps; in step 3 a `warming the load up` line, a first candidate that is not `SLOW`, and a descent; steps 4 and 5 run on the tune of steps 2 and 3; `RESULT:` | **Not as expected at step 4**, and that found a fault (2026-10-11, reference RTX 4070, driver 617.42, a test build of 0733695, unattended). Step 1: `stock: STABLE score=5325 it/s peak=65 C fan=70 % power=186 W`. Step 2: power 105 %, `mem: bandwidth peak +2300, confirmed +2300, applying +1600`, `core: highest stable +210, confirmed +210, applying +135`, soak `STABLE score=5568 it/s peak=70 C power=197 W`. Step 3, as wanted: `warming the load up: 5 s with the overclock`, `target: 2865 MHz, which the card reaches at 1050 mV with the overclock`, nine candidates `STABLE` from 1045 mV down, `WRONG RESULT` at 990 mV, confirmed at 1010 mV after two tries, and `applying 1050 mV (+135 MHz at that point)`: the margin left no raise above the overclock, so the curve was cut off, as in the runs before the warm-up; soak `STABLE score=5434 it/s peak=67 C power=176 W`. Step 4 did not begin: `the tune could not be applied for the fan tune: the undervolt was not applied: the point already runs more than the target -- card at stock`. The saved tune of before the test was put back and applied. Cause and fix: the decision "A flat top goes back on a card that is cooler than when it was found". Second run, with the `gao.exe` of the released v0.4.6: **pass, all five steps** (same day, started elevated by a script). Step 1: `stock: STABLE score=5309 it/s peak=66 C fan=70 % power=185 W`. Step 2: power 105 %, `mem: bandwidth peak +850, confirmed +850, applying +550`, `core: highest stable +210, confirmed +210, applying +135`, soak `STABLE score=5568 it/s`. Step 3: `target: 2850 MHz, which the card reaches at 1045 mV with the overclock`, `undervolt: lowest stable 975 mV, confirmed 985 mV, applying 1025 mV (+165 MHz at that point)`, soak `STABLE score=5363 it/s peak=66 C power=163 W`. Step 4: the tune went back on the card, `fan 60 %: 63 C`, `fan 55 %: 65 C`, `fan 52 %: 67 C`, `fan tune: 52 % holds 67 C`. Step 5: the final test ran its 300 s. `RESULT: power 105 %, core +135 MHz, mem +550 MHz, 2850 MHz at 1025 mV, fans 52 % at 67 C`; `stock: 5309 it/s, 185 W, fan 70 %, 66 C`, `now: 5353 it/s, 166 W, fan 52 %, 70 C`: `+0.8 % score and -10.3 % power against stock`; `undervolt: applied`. The saved tune of before the test was put back. **What this run did not show:** its undervolt had a raise of its own (+165 over an offset of +135), so the anchor was raised and not merely cut off, and the case of the first run (an anchor that reads a step above the target on a cooler card) did not come up. That fix has still only its tests. Also seen: the memory offset differs a lot from run to run on this card: +1600 in the first run (bandwidth peak +2300), +550 in the second (peak +850), +650 in the run that saved the tune in use that morning. | +| 94 | All in one, with the undervolt step searching for the first time | Elevated, the tray app exited, a copy of `gao.json` kept: `gao --optimize all` to the end with a build that has the warm-up of the undervolt step; then `gao --status`; put the copy back | yes | five steps; in step 3 a `warming the load up` line, a first candidate that is not `SLOW`, and a descent; steps 4 and 5 run on the tune of steps 2 and 3; `RESULT:` | **Not as expected at step 4**, and that found a fault (2026-10-11, reference RTX 4070, driver 617.42, a test build of 0733695, unattended). Step 1: `stock: STABLE score=5325 it/s peak=65 C fan=70 % power=186 W`. Step 2: power 105 %, `mem: bandwidth peak +2300, confirmed +2300, applying +1600`, `core: highest stable +210, confirmed +210, applying +135`, soak `STABLE score=5568 it/s peak=70 C power=197 W`. Step 3, as wanted: `warming the load up: 5 s with the overclock`, `target: 2865 MHz, which the card reaches at 1050 mV with the overclock`, nine candidates `STABLE` from 1045 mV down, `WRONG RESULT` at 990 mV, confirmed at 1010 mV after two tries, and `applying 1050 mV (+135 MHz at that point)`: the margin left no raise above the overclock, so the curve was cut off, as in the runs before the warm-up; soak `STABLE score=5434 it/s peak=67 C power=176 W`. Step 4 did not begin: `the tune could not be applied for the fan tune: the undervolt was not applied: the point already runs more than the target -- card at stock`. The saved tune of before the test was put back and applied. Cause and fix: the decision "A flat top goes back on a card that is cooler than when it was found". Second run, with the `gao.exe` of the released v0.4.6: **pass, all five steps** (same day, started elevated by a script). Step 1: `stock: STABLE score=5309 it/s peak=66 C fan=70 % power=185 W`. Step 2: power 105 %, `mem: bandwidth peak +850, confirmed +850, applying +550`, `core: highest stable +210, confirmed +210, applying +135`, soak `STABLE score=5568 it/s`. Step 3: `target: 2850 MHz, which the card reaches at 1045 mV with the overclock`, `undervolt: lowest stable 975 mV, confirmed 985 mV, applying 1025 mV (+165 MHz at that point)`, soak `STABLE score=5363 it/s peak=66 C power=163 W`. Step 4: the tune went back on the card, `fan 60 %: 63 C`, `fan 55 %: 65 C`, `fan 52 %: 67 C`, `fan tune: 52 % holds 67 C`. Step 5: the final test ran its 300 s. `RESULT: power 105 %, core +135 MHz, mem +550 MHz, 2850 MHz at 1025 mV, fans 52 % at 67 C`; `stock: 5309 it/s, 185 W, fan 70 %, 66 C`, `now: 5353 it/s, 166 W, fan 52 %, 70 C`: `+0.8 % score and -10.3 % power against stock`; `undervolt: applied`. The saved tune of before the test was put back. **What this run did not show:** its undervolt had a raise of its own (+165 over an offset of +135), so the anchor was raised and not merely cut off, and the case of the first run (an anchor that reads a step above the target on a cooler card) did not come up. That fix has still only its tests. **The memory offset differs a lot from run to run on this card, and the two logs say why:** +1600 in the first run (bandwidth peak +2300), +550 in the second (peak +850), +650 in the run that saved the tune in use that morning (the journal shows its scan ending at +1000 too). The card was in the same state each time (68 C, power 105 %, a reading every three to four seconds). In both logged scans the bandwidth rises in a straight line, 0.36 and 0.46 % per 50 MHz step, from 420 GB/s at +0 to 509 GB/s at +2450; the first run went on to `WRONG RESULT` at +2550 without the bandwidth ever turning down. The readings scatter around that line with a standard deviation of 0.4 and 0.7 %, single ones by more than 1 %. The scan ends at a reading more than 1 % below the best so far when a second reading agrees, and in the second run that was chance: +950 read high (462.8 GB/s, where the line is at about 458), +1000 read 456.6 twice, 1.3 % below it. In the first run the one low reading (+600) was followed by a higher one, and the scan ran to the first wrong result. So on this card there is no bandwidth peak before the errors, and where the scan stops is decided by noise. | ## Notes From 07fc794d2485fb8eb66365090f66dc561ae09ffb Mon Sep 17 00:00:00 2001 From: Rovey Date: Sun, 11 Oct 2026 18:20:46 +0200 Subject: [PATCH 2/2] docs: the README's All in one numbers are those of the run of hardware check 94 5309 to 5353 it/s, 185 to 166 W, fans 70 to 52 %, in 31 minutes, with v0.4.6. The two earlier runs are named next to it; the screenshot is of the first of them and says so. Co-Authored-By: Claude Opus 5.5 --- README.md | 22 +++++++++++----------- docs/images/hero.svg | 20 ++++++++++---------- 2 files changed, 21 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index c579197..25c410e 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ [**Download**](https://github.com/Rovey/gpu-auto-optimizer/releases/latest) · [What one click does](#one-click-then-nothing) · [How it works](#how-it-works) · [Command line](#command-line) · [FAQ](#faq) -One click on the reference RTX 4070: 1.6 % more speed on 8 % less power, with the fans at 62 % instead of 73 %. Best of my GPU alone: 4.5 % more speed. Undervolt alone: 20 % less power, 8 °C cooler. +One click on the reference RTX 4070: 0.8 % more speed on 10 % less power, with the fans at 52 % instead of 70 %. Best of my GPU alone: 4.5 % more speed. Undervolt alone: 20 % less power, 8 °C cooler. The GPU Auto Optimizer dashboard: live telemetry, the current tuning, the profiles and the log @@ -46,22 +46,22 @@ What else is in it:
-The result screen of an All in one run on the reference RTX 4070: core +135 MHz, memory +1500 MHz, power limit 105 %, 2850 MHz at 1035 mV, fans 52 % at 70 °C; score 5728 to 5820 iterations per second, power 196 to 180 watts, fan speed 73 to 62 percent +The result screen of an earlier All in one run on the reference RTX 4070: core +135 MHz, memory +1500 MHz, power limit 105 %, 2850 MHz at 1035 mV, fans 52 % at 70 °C; score 5728 to 5820 iterations per second, power 196 to 180 watts, fan speed 73 to 62 percent
-**All in one** is the default: it overclocks, undervolts on top of that, measures the quietest fan curve and tests the whole for five minutes. One run on the reference card, both columns five minutes of full load: +**All in one** is the default: it overclocks, undervolts on top of that, measures the quietest fan curve and tests the whole for five minutes. One run on the reference card, both columns five minutes of full load (the picture above is of an earlier run and shows that run's numbers): | | Stock | After one click | |---|---|---| -| Stress-test score | 5728 it/s | **5820 it/s (+1.6 %)** | -| Power under load | 196 W | **180 W (−8.2 %)** | -| Fan speed | 73 % | **62 %** | -| Temperature | 67 °C | 71 °C | -| Core clock under load | 2789 MHz | 2835 MHz | -| Memory clock under load | 10495 MHz | 12000 MHz | +| Stress-test score | 5309 it/s | **5353 it/s (+0.8 %)** | +| Power under load | 185 W | **166 W (−10.3 %)** | +| Fan speed | 70 % | **52 %** | +| Temperature | 66 °C | 70 °C | +| Core clock under load | 2787 MHz | 2835 MHz | +| Memory clock under load | 10474 MHz | 11051 MHz | -A little faster, on less power, with slower fans. The card is warmer because the fans are allowed to be: the fan tune aims for 70 °C, 5 °C under the profile's limit, and found that 52 % holds it. With the NVIDIA driver's own fan curve the same settings ran at 63 °C on 176 W. The run took 34 minutes. A second run gave 0.9 % more score on 10.8 % less power, with the fans at 55 %. +As fast or a little faster, on a tenth less power, with much slower fans. The card is warmer because the fans are allowed to be: the fan tune aims for 70 °C, 5 °C under the profile's limit, and found that 52 % holds it. Before the fan tune, with the fans on the profile's own curve, the same settings ran at 66 °C on 163 W. The run took 31 minutes. Two earlier runs gave 1.6 % more score on 8.2 % less power with the fans at 62 %, and 0.9 % more on 10.8 % less with the fans at 55 %. How much memory offset a run finds differs from run to run on this card (+550 in this one, +1500 in the first of those); the score barely moves with it. The gains are smaller than those of the two sections below, and that is the point of it. An overclock and an undervolt do not add up: an overclock moves the whole voltage/frequency curve, so at every clock the card already runs on less voltage, and with the same safety margin there is nothing left to take off. They are two ends of one line. All in one takes the middle, where the card beats stock on both counts; **Best of my GPU** and **Undervolt** are the ends. @@ -70,7 +70,7 @@ The gains are smaller than those of the two sections below, and that is the poin > [!NOTE] -> Close games and other programs that use the graphics card before a run. In an earlier run an emulator on 11 % of the card cost 6 % of the score; the run now says so when its final test does not match the step before it. The logs are in [docs/hardware-checks.md](docs/hardware-checks.md) (checks 75 and 76). +> Close games and other programs that use the graphics card before a run. In an earlier run an emulator on 11 % of the card cost 6 % of the score; the run now says so when its final test does not match the step before it. The logs are in [docs/hardware-checks.md](docs/hardware-checks.md) (checks 75, 76 and 94). ## All of the speed instead: +4.5 % performance diff --git a/docs/images/hero.svg b/docs/images/hero.svg index 4ea249e..fad3824 100644 --- a/docs/images/hero.svg +++ b/docs/images/hero.svg @@ -1,6 +1,6 @@ - One click on the reference RTX 4070: 1.6 % more speed on 8 % less power, with the fans at 62 % instead of 73 % - One All in one run, five minutes of full load at stock against five minutes after it. Stress-test score 5728 to 5820 iterations per second, power 196 to 180 watts, fan speed 73 to 62 percent. A second run gave 0.9 percent more score on 10.8 percent less power with the fans at 55 percent. The profiles that go for one thing only: Best of my GPU, 4.5 percent more speed; Undervolt, 20 percent less power and 8 degrees cooler. + One click on the reference RTX 4070: 0.8 % more speed on 10 % less power, with the fans at 52 % instead of 70 % + One All in one run, five minutes of full load at stock against five minutes after it. Stress-test score 5309 to 5353 iterations per second, power 185 to 166 watts, fan speed 70 to 52 percent. Two earlier runs gave 1.6 percent more score on 8.2 percent less power with the fans at 62 percent, and 0.9 percent more on 10.8 percent less with the fans at 55 percent. The profiles that go for one thing only: Best of my GPU, 4.5 percent more speed; Undervolt, 20 percent less power and 8 degrees cooler. @@ -14,21 +14,21 @@ SPEED - +1.6 % - 5728 to 5820 it/s + +0.8 % + 5309 to 5353 it/s POWER - −8 % - 196 W to 180 W under full load + −10 % + 185 W to 166 W under full load FAN SPEED - 62 % - was 73 %, measured for this card + 52 % + was 70 %, measured for this card - All in one, the default: overclock, undervolt and fan curve in one 34-minute run, tested as a whole. + All in one, the default: overclock, undervolt and fan curve in one 31-minute run, tested as a whole. Want all of one thing? Best of my GPU: +4.5 % speed. Undervolt: −20 % power, 8 °C cooler. - NVIDIA GeForce RTX 4070 · five minutes at stock against five minutes after · a second run: +0.9 %, −10.8 %, 55 % + RTX 4070 · five minutes at stock against five minutes after · earlier runs: +1.6 % and +0.9 %, −8 % and −11 %