@@ -84,7 +84,7 @@ The applied offset is always at least one step below the confirmed edge. Profile
 | 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\<user SID>`) 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. |
 | A run does not start next to MSI Afterburner or RivaTuner | `other_tool_refusal`, asked before anything else in `run_optimize`, `run_undervolt`, `run_all_in_one` and `run_retest`, so the window and `gao` say the same. Afterburner sets clocks and fans itself; RivaTuner hooks into every program that uses the card, the stress load among them. By file name (`MSIAfterburner.exe`, `RTSS.exe`), which is all a list of processes gives; a list that cannot be read counts as "none runs", because the run's own read-backs and the watchdog are what it relies on. Not the cause of the freeze above: on that PC Afterburner was closed and RivaTuner not installed. |
-| Before a run the tool looks at what else uses the card, names it, and asks | A run measures the card under full load, and every other program on the card takes from what it measures. That was found the long way: for a whole day of card tests the reference RTX 4070 scored about 5300 it/s in the stress load and read 444 to 455 GB/s of memory bandwidth, scattering by 0.4 to 1.3 %, until an editor that had stood open since the morning was closed; from that second on it read 480 GB/s and 5750 to 5830 it/s, steady to 0.2 % (hardware check 96). The editor was idle and used 2.2 % of the 3D engine. A video playing in a browser makes the readings jump by 3 to 8 % from one to the next. Nobody thinks of an open editor as a heavy program, so telling people to close heavy programs does not reach it; the tool has to look. **How.** Windows keeps the card's use per process and engine (the `GPU Engine` performance counters, what Task Manager shows); `gpu_use` in `src/hw/gpu_users.cpp` reads them for three seconds, for the NVIDIA adapter only, without elevation. `busy_programs` in `src/core/busy_card.cpp` adds a program's processes and engines together and names what is at `kBusyPct` (1 %) or more: the idle desktop is at 0.05 %, the editor at 2.2 %. Never named: the tool itself, and what Windows needs to draw the desktop, which nobody can close. A reading outside 0 to 100 % is left out; the counters give one now and then. **It asks, it does not refuse.** Another tuning tool writes to the card and a run is refused next to it. These programs change nothing on the card; they only make the numbers worse, and the user may have a reason to keep one open. So `busy_gate` asks through `OptimizeHooks::busy`: the window shows the list with **Check again**, **Go on anyway** and **Cancel**; the command line prints the list and does not start, unless `--busy-ok` is its last argument. The all-in-one run asks once, not in every step. **Nothing is closed by the tool**: a program may hold work that is not saved. **It is always written down.** Every look goes to the run's log (`other programs on the card: Trae (2 %)`, or `none`), also when the user goes on, so a log says what the card was shared with. That line would have saved the day this was found on. **A second look after an optimize run**, when the load is off the card again: when the programs differ from the ones before it (`busy_change`), the result carries a note that its numbers and the ones at stock were not measured on the same card. That is what happened in the run the editor was closed under: stock at 5321 it/s, the scan from then on at 5760. **Limits.** The look is taken while the card idles: under the run's own load the other programs' share reads near nothing, so the tool cannot watch during a run, only before and after. A program that is busy only now and then can be missed by a three-second look. The second look is not built for the undervolt, the all-in-one and the retest runs. And where Windows does not give the counters, nothing is found and nothing is said: this is advice, not a check a run relies on. `gao --busy` shows what a run would find. |
+| Before a run the tool looks at what else uses the card, names it, and asks | A run measures the card under full load, and every other program on the card takes from what it measures. That was found the long way: for a whole day of card tests the reference RTX 4070 scored about 5300 it/s in the stress load and read 444 to 455 GB/s of memory bandwidth, scattering by 0.4 to 1.3 %, until an editor that had stood open since the morning was closed; from that second on it read 480 GB/s and 5750 to 5830 it/s, steady to 0.2 % (hardware check 96). The editor was idle and used 2.2 % of the 3D engine. A video playing in a browser makes the readings jump by 3 to 8 % from one to the next. Nobody thinks of an open editor as a heavy program, so telling people to close heavy programs does not reach it; the tool has to look. **How.** Windows keeps the card's use per process and engine (the `GPU Engine` performance counters, what Task Manager shows); `gpu_use` in `src/hw/gpu_users.cpp` reads them for three seconds, for the NVIDIA adapter only, without elevation. `busy_programs` in `src/core/busy_card.cpp` adds a program's processes and engines together and names what is at `kBusyPct` (0.5 %) or more: programs that only stand there read 0.01 to 0.05 %, the editor 2.2 % in one look and 1 % in another. Never named: the tool itself, and what Windows needs to draw the desktop, which nobody can close. A reading outside 0 to 100 % is left out; the counters give one now and then. **It asks, it does not refuse.** Another tuning tool writes to the card and a run is refused next to it. These programs change nothing on the card; they only make the numbers worse, and the user may have a reason to keep one open. So `busy_gate` asks through `OptimizeHooks::busy`: the window shows the list with **Check again**, **Go on anyway** and **Cancel**; the command line prints the list and does not start, unless `--busy-ok` is its last argument. The all-in-one run asks once, not in every step. **Nothing is closed by the tool**: a program may hold work that is not saved. **It is always written down.** Every look goes to the run's log (`other programs on the card: Trae (2 %)`, or `none`), also when the user goes on, so a log says what the card was shared with. That line would have saved the day this was found on. **A second look after an optimize run**, when the load is off the card again: when the programs differ from the ones before it (`busy_change`), the result carries a note that its numbers and the ones at stock were not measured on the same card. That is what happened in the run the editor was closed under: stock at 5321 it/s, the scan from then on at 5760. **Limits.** The look is taken while the card idles: under the run's own load the other programs' share reads near nothing, so the tool cannot watch during a run, only before and after. A program that is busy only now and then can be missed by a three-second look. An application that draws through an embedded browser is named as that browser (`msedgewebview2`), not by its own name; the process that owns it would have to be looked up. The second look is not built for the undervolt, the all-in-one and the retest runs. And where Windows does not give the counters, nothing is found and nothing is said: this is advice, not a check a run relies on. `gao --busy` shows what a run would find. |
 | Edges are confirmed, then backed off | A 3 s probe can pass by luck; the edges get 30 s probes before the safety margin is applied, and the result must pass a 300 s soak. |
 | The search climbs to a per-card bound | A fixed +300 MHz cap decided the result on cards that hold more. The bound is the offset range the driver reports, accepted only when it is plausible (spans stock, contains the applied offset, below a sanity limit). Bisecting such a range would start hundreds of MHz too high, so the search climbs from stock. |
 | Both searches go one grid step at a time (15 MHz core, 50 MHz memory); nothing is bisected | The first value that fails is then exactly one step above the last one that passed, for an ordinary failure and for a driver reset alike, and the climb probes nothing more after a value that failed or reset the driver. The confirm probe then runs one step below an ordinary failure (at the last value that passed) and, after a reset, four steps below the last value that passed. The earlier scheme, 60 MHz strides and a bisect after the first failure, could leave the last passing value up to 45 MHz below the edge and bisected right below a value that had just reset the driver. The cost is more probes and a longer run; how much longer has not been measured. |