You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 9036862
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/development.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -79,6 +79,7 @@ The applied offset is always at least one step below the confirmed edge. Profile
79
79
| 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. |
80
80
| Memory is searched before the core | The first driver reset ends exploring (see the reset budget row). The assumption, not measured, is that a reset is far more likely in the core climb than in the memory scan: memory normally loses bandwidth long before it fails, and both resets seen so far came from the core. With the core first, its reset would leave the memory untuned. The core climb runs with the chosen memory offset applied; memory is tuned at stock core clocks, and the combination is proven by the soak. If the memory search itself has a reset, the core is still searched (seen on the reference RTX 4070: a memory scan ended in a reset, the core climb ends in a wrong result), and the run can then take one more reset. |
81
81
| The optimize run reconnects after a driver reset | The edge is found by crossing it, and past it the driver resets. A call into NVML faulted after a reset, in the tray app (hardware check 33) and in an optimize run (check 51), so the run owns guarded connections: a fault inside a driver DLL becomes a failed call, a reconnect re-creates both libraries, and it never happens with a journal entry open. A fault that still escapes ends the run with the entry closed as `CRASHED`, and the card is then reset to stock. |
82
+
| One NVML session for the process, and the power limit and the fan speed are asked first | On driver 617.42 the clock, temperature and power readings come from memory the driver shares with the process. A driver reset takes that memory away, the library goes on reading it, and every such call is an access violation from then on (hardware check 84); one that was caught leaves `nvmlShutdown` waiting for ever (check 80). Only a complete `nvmlShutdown` and a new `nvmlInit` bring the memory back. The calls that ask the driver instead answer a reset with a status, so `device()` in `nvml.cpp` makes two of them before every other call on a card: when one that worked before says the card is gone, nothing reads, and two seconds later the session is stopped and started again. `nvmlInit` is counted by the library, so all `Nvml` objects share one session: with one each, the window's would keep the stale session alive under the reconnect of a run. |
82
83
| A probe that computes almost nothing is `STALLED`| Past its edge an RTX 5070 passed a probe at 3 % of its baseline score with no wrong value and no lost device (hardware check 51). Below a quarter of the baseline a "stable" probe is `STALLED`. A running probe ends as soon as its last three seconds fall below that floor, so a 300 s soak does not keep loading a card that stopped computing; three seconds, so that one delayed batch does not look like a dead card. Probes shorter than that are judged after they end. |
83
84
| A clock search stops exploring at its first driver reset; a run ends at one more than its searches may have | Nothing can guarantee that a probe will not reset the driver, so resets are counted. What counts: a probe that ends `DEVICE LOST`, `STALLED` or `NO TELEMETRY`; a candidate, power or soak write that fails; a failed bandwidth measurement on an overclocked candidate, unless the load measured and its readings only did not agree (other programs using the card): that ends the memory scan at the best value measured and counts as nothing. At the first one in a clock search that search ends at the last value that passed (in a bandwidth scan: the bandwidth peak of the values that passed), confirmation starts four steps lower, and a reset during a confirm probe or the soak moves the next try four steps down instead of one. Each clock has its own search: after a reset in the memory search the core is still searched, because on the reference RTX 4070 a memory scan ended in a driver reset at +2550 MHz while the core climb ends in a wrong result, and skipping the core left that card with no core offset at all (hardware check 52). A run allows one reset, and two when the first came in the memory search and the core is searched after it; at one more the run ends at stock, nothing saved, nothing else started. With no clock offset applied (the baseline, the power step, a soak at stock clocks) there is nothing to back off to, and the first one ends the run. Only `DEVICE LOST` proves a reset; the others suggest one, so `gao` can count a reset the Windows log does not show. |
84
85
| After a reset: rest, then prove the card is back | In round A of hardware check 51 the first probe after a forced reset, at core +30 and about two seconds after the driver restarted, scored 325 it/s at 45 W and was judged `STALLED`; the desktop was unusable afterwards. Why that probe scored so low is not known: in the build round A ran on, the stress load re-created its D3D device and recompiled its shader in the first batch after a lost device, and that time was counted in the probe's score; the card itself may or may not have been back. So before any further candidate the search reconnects, writes stock, leaves the card without load for 20 s, and runs a 5 s probe at stock that must be `STABLE` at 90 % of the baseline or better: up to three such probes, a rest before each. A card that does not come back ends the run, and so does a reset during that check: no step of the recovery starts another recovery. The numbers are first choices, not measured. |
0 commit comments