02What it does
Six areas of control, and one rule running through all of them: a value the hardware did not
report is shown as unavailable, never as a plausible number standing in for it.
Each area is enabled by what the machine answers, not by what this page claims. See Compatibility below.
| Area | What you get |
|---|
| Fans | An editable temperature-to-level curve, a safety floor that overrides the stock 0 % entry, a manual calibration sweep to find your own chassis’s raw band, and a Max mode. |
| GPU power | Custom TGP and Dynamic Boost as separate switches, GPU mode, and the ceiling re-asserted on a timer because the firmware takes it back. |
| CPU tuning | Sustained and boost power limits, thermal limit, and a per-knob enable, so a limit you have not set is never written. |
| Adaptive tuning | Moves the sustained power limit within a range you set, steering on temperature and demand together. |
| Measurement | A repeatable load test with saved runs, the five-way bottleneck table, per-phase poll timing, and a thermal log. |
| Windows | Power plans, timer resolution, MMCSS, process priority, and per-application GPU routing. |
Adaptive tuning steers on demand, not on heat alone
A controller watching temperature by itself has a failure mode that reads as success: an idle
machine is cool, so the limit goes up, which is harmless right up until the limit is high
enough that the idle machine warms to the target and stays there. The temperature reading says
the controller is working. Version 1.1.0 shipped exactly that.
The direction is now a function of three things — package temperature, the limit in
force, and how much the processor is actually drawing against it. A cool machine that is not
asking for power gets none, because there is nothing there to give it.
One heatpipe, two chips
CPU and GPU are cooled by the same heatpipe but were tuned as independent knobs, so a
GPU-bound game left the CPU holding a sustained limit it was not using while the package sat
at its thermal target. The CPU yields when the GPU is busy and the package has
reached target. Both conditions are required — a busy GPU on a cool machine is not
competing for anything.
The load test exists because a release was wrong
Version 1.1.1 compiled, passed every test, and stopped its own adaptive controller within
seconds of launch. Nothing in the application could tell you that, and a ninety-second look at
the temperature readout could not either. The Diagnostics tab pins every core for a duration
you choose and records temperature, package power, CPU clock and fan speed, then reports
median, p90, max and the clock floor — the figure that moves when sustained
behaviour does. Runs are saved to disk, so two builds can be compared instead of described.
The load test only reads. No fan commands and no power writes, so it is safe
to run while OmniHub is driving the fans — which is the only condition under which its
numbers mean anything. Also available headless as
OmniHub.exe -LoadTest <minutes>.
What is limiting the processor
Five constraints, each as a fraction of its own limit: sustained power, boost power, EDC, TDC
and temperature. Sitting at 99 % of core current and 60 % of power says plainly that
raising the power limit will change nothing — which no single figure on the page could
say. Without an SMU the whole table is hidden rather than filled in with an estimate.
