Undervolting guide: where it came from

Where the community's undervolting guidance came from, in date order. The Discord thread "Undervolting CMP170HX 8GB version GUIDE" is not where it began: the thread opened on 2026-10-02 as a request, and the first written guide had been posted more than two months earlier, on 2026-07-27. The method in every guide is cachenetics' 170tune, a V/F-offset undervolt through NVML. How to undervolt today is on Undervolting and power limits; this page records who wrote what, and when. Long guides by one person appear here as pointers until their authors agree to have them hosted.

The thread

RH-3D opened the thread on 2026-10-02 as a request for a guide

The thread "Undervolting CMP170HX 8GB version GUIDE (Simple for every one!) Working with cmpunlocker" sits in the server's feature-requests category. @rh3dai opened it on 2026-10-02 at 07:22 UTC, asking for a "very simple guide like step by step even for bigginers" to cut power consumption with undervolt settings. The title names a guide, but the opening post is a request; the guidance in the thread is in the answers below.

Reported 8 GB
Source: @rh3dai, 2026-10-02

cibernox answered with cachenetics/170tune (2026-10-02)

At 07:51 UTC, 29 minutes after the request, @cibernox replied that cachenetics/170tune "is what you are looking for". The later answers in the thread all build on that tool.

Reported 8 GB
Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @cibernox, 2026-10-02

Vcore explained the two knobs: frequency offset and maximum frequency (2026-10-02)

At 15:07 UTC @vcore2191 explained what 170tune changes: the voltage-frequency curve, through two settings. A positive frequency offset gives more frequency at a given voltage; a maximum frequency caps the clock. To undervolt, set a positive offset and a ceiling below what that offset could reach. The stock maximum reachable frequency is 1470 MHz with the mining BIOS and 1410 MHz with the regular one. His own setting, 170tune try +190 1670, is an overclock with no undervolt (up to 1660 MHz is reachable); 170tune try +190 1470 keeps stock frequency at a lower voltage. A negative offset only overvolts and has no purpose. Asked how to do this on a headless box, he said he connects over SSH from another computer.

Reported 8 GB
Source: @vcore2191, 2026-10-02

Ryko posted the cmpunlocker and 170tune branches the tuner needs (2026-10-02)

At 17:20 UTC @vektor_prime posted two branches. vektorprime/cmpunlocker, branch fbpa-pll-170tune merges the official cmpunlocker with the asm64-cmpunlocker patches: it keeps upstream's latest changes, including the 4 extra SMs that asm64-cmpunlocker lacked, and adds core and HBM overclocking. vektorprime/170tune, branch fbpa-first-active makes 170tune work on both 8 GB and 10 GB cards. He had an LLM write both and did not review them by hand, but validated them on his 3 cards, running a core clock offset at lower power. He had first described the merged fork on 2026-09-26. Where these branches sit among the other forks: Cmpunlocker forks.

Reported 8 GB and 10 GB
Source: @vektor_prime, 2026-09-26
Source: repo github.com/vektorprime/cmpunlocker by vektorprime on GitHub, posted by @vektor_prime, 2026-10-02
Source: repo github.com/vektorprime/170tune by vektorprime on GitHub, posted by @vektor_prime, 2026-10-02

RH-3D's first try: one card short of 74 SM, and preflight refused (2026-10-02)

That evening @rh3dai tried the fork on five cards. All five work on cmpunlocker v0.4, but with the fork only four started at 74 SM. 170tune's preflight then passed every check (device id 0x20c210de, driver, helper tools, stock memory clock source, BAR0 access) except one: "FBPA privilege masks (unlock)", with the advice "Apply the cmpunlocker unlock (patched driver / hammer service) and retry". @vektor_prime answered that 170tune cannot be used without the cmpunlocker branch he had listed first.

Reported 8 GB
Source: @rh3dai, 2026-10-02
Source: @rh3dai, 2026-10-02
Source: @vektor_prime, 2026-10-02

The fork on a 32-card server: +300 and 166.32 TH/s at 189.1 W (2026-10-03)

At 01:56 UTC on 2026-10-03 @rh3dai reported the fork working on his second server, 32 cards, which gained "another 128SM" (4 per card). He ran the hottest card at a +300 offset on Pearl mining. The miner showed that card (#13) at 166.32 TH/s, 189.1 W and 39 C (miner version 0.51.3), with its HBM at 1,890 MHz and 55 C. One card still gave trouble: he considered going back from Ubuntu 26.04 with driver 610.57.04 to 24.04 with 610.43.02, or running that card alone at 70 SM.

Reported 8 GB
Source: @rh3dai, 2026-10-03
Source: @rh3dai, 2026-10-03

Earlier written guides

Studebaker's 170hx-tuning-guide.md (2026-07-27): the first written guide

Pointer: a longer write-up by @_studebaker_ exists: 170hx-tuning-guide.md (26,987 bytes, posted in #testing-general on 2026-07-27), the first written tuning guide in the Discord history, posted with bf16 TFLOPS/W and GFLOP/W charts; see Discord. It is not reproduced here until the author agrees. Source: @_studebaker_, 2026-07-27

Studebaker's chart notes: the right offset depends on the clock ceiling (2026-07-27)

With the charts @_studebaker_ posted two findings in the message text. 1590/+400 hangs while 1650/+400 runs: past the wall, behaviour stops being monotonic once the clock stretcher engages. And +250 is the wrong offset at high ceilings (1650/+250 gives 1067 GFLOPS/W against 1149 at +350) because the arbiter cannot reach the requested clock. LetterC67 asked whether the bf16 figure is tensor-core throughput; there is no answer in the history. Later that day, in #general, he concluded from his sweeps that the right tuning saves watts but cannot lower temperatures on air: "getting lower hbm temps on air seems impossible".

Reported 8 GB
Source: @_studebaker_, 2026-07-27
Source: @_studebaker_, 2026-07-27
Source: @_studebaker_, 2026-07-27

170tune: the guide's tool, on GitHub the same day (2026-07-27)

The guide uses a tool called 170hx-oc. When @costak asked where to get it, @_studebaker_ answered with cachenetics/170tune, "a tuning and qualification harness"; @ju5t5omedude asked how to make the settings persist, and options for that followed. 170tune applies an SM clock ceiling and a V/F-offset undervolt through NVML, sets the HBM clock and timings live, and gates every setting with a memory and compute check; the card always boots stock. On 2026-07-31 it recognized only the 8 GB card's device ID, so a 10 GB card showed an offset range of [0 .. +0] until a commit that day fixed it. On 2026-08-04 Studebaker said it reaches the same speeds with about 50 to 80 W less. From August on it was the standard answer to clock and undervolting questions: @robbbbbb7973 (2026-08-20), @_arcanum_ (2026-08-26), @wakeupmbrc1 (2026-09-01) and @cibernox (2026-09-19) all pointed people to it. The history does not say whether Studebaker runs the cachenetics account.

Reported 8 GB and 10 GB
Source: @costak, 2026-07-27
Source: repo github.com/cachenetics/170tune by cachenetics on GitHub, posted by @_studebaker_, 2026-07-27
Source: @ju5t5omedude, 2026-07-27
Source: @_studebaker_, 2026-08-04
Source: @robbbbbb7973, 2026-08-20
Source: @_arcanum_, 2026-08-26
Source: @wakeupmbrc1, 2026-09-01
Source: @cibernox, 2026-09-19

Miséricorde's 170tune quick guide (2026-09-16)

Pointer: a longer write-up by @wakeupmbrc1 exists: CMP170HX_170TUNE_QUICK_GUIDE.md (8,409 bytes, 2026-09-16), written to be handed to a coding agent that dumps the VBIOS, flashes the signed image and tunes with 170tune, with a step-by-step ladder for the power limit, the V/F offset, the SM clock ceiling and the HBM clock; see Discord. It is not reproduced here until the author agrees. Source: @wakeupmbrc1, 2026-09-16

Vcore's profile before the thread: +190, 1660, NDIV 70, refresh 96, 300 W (2026-09-27)

Five days before the thread, @vcore2191 posted the settings he runs: "+190 1660 ndiv 70 refresh 96 pl 300", read as a +190 MHz offset, a 1660 MHz ceiling, HBM NDIV 70, HBM refresh 96 and a 300 W power limit (he did not spell out the fields). He is voltage-capped, especially on MoE models, and asked whether the 170HX's voltage can be raised; failing a software route, he was considering modding the voltage regulator's feedback, without having checked the schematics. @con3po7016 said more voltage is possible but brings more heat, watts and wear for maybe a few more tokens, and that he has seen undervolting increase tok/s.

Reported
Source: @vcore2191, 2026-09-27
Source: @con3po7016, 2026-09-27

Videos

RH-3D's tuning videos and the v0.5 walkthrough (2026-10-04 to 2026-10-11)

@rh3dai posted three videos in the thread:

2026-10-04: "#011 Ultimate Tuning!!! MORE Compute!!! MORE Bandwidth!!! LESS Power", shared as the optimisation guide for undervolting with cmpunlocker (YouTube).
2026-10-07: "#012", a follow-up after the ECC merge (YouTube).
2026-10-11: "Cmpunlocker v0.5 for Nvidia CMP170HX 64GB VRAM +4SMs +ECC SRAM", a walkthrough of the v0.5 release (YouTube).

An earlier video of his on the x16 capacitor mod (YouTube) was recommended by @djpandaman on 2026-09-23 as the hands-on companion to the 170th Street guide; see PCIe x16 capacitor mod.

Pointer: the videos are not transcribed here. A written version waits for @rh3dai's agreement.

Reported 8 GB
Source: @djpandaman, 2026-09-23
Source: @rh3dai, 2026-10-04
Source: @rh3dai, 2026-10-07
Source: @rh3dai, 2026-10-11

Later posts in the thread

Ryko merged the ECC changes into his branch (2026-10-07)

On 2026-10-07 @vektor_prime merged the ECC RAM changes into his fork's branch. When @rh3dai reported 170tune still not working, Ryko's first question was whether he was on the right branch, fbpa-pll-170tune. RH-3D asked whether the updated branch also allows ECC, because he could not give up the memory overclock: "thats huge difference on the wall".

Reported
Source: @vektor_prime, 2026-10-07
Source: @rh3dai, 2026-10-07

Water-cooled HBM never reaches 170tune's HOT pass (2026-10-07)

@rh3dai cannot complete 170tune's HOT pass because the HBM on his water-cooled cards never gets hot enough (45 to 50 C), while air-cooled cards go past 70 C. He asked for the gate to be fixed for well-cooled cards. On 2026-09-22 @reala7096 had seen the same thing: with good cooling his HBM never reached 65 C during the 170tune stress test, which made overclocking hard. See Water cooling.

Reported 8 GB
Source: @reala7096, 2026-09-22
Source: @rh3dai, 2026-10-07

One card that never tunes, and the same failure on every card for drew-3 (2026-10-07 to 2026-10-12)

On 2026-10-07 @rh3dai tested cmpunlocker v0.5: the odd card now unlocked to 74 SMs, but 170tune's preflight still reported "FBPA privilege masks are closed". The other 35 of his 36 cards passed on the first try. @drew_2 saw the same preflight failure on all of his cards, with the latest cachenetics/170tune and amoghmunikote master and again with the vektorprime pair; he found no documentation on which versions belong together. RH-3D's workaround: run that card in a separate machine on the official v0.5 unlock, without 170tune. Lab notes (2026-10-25) add a second cause: on some 8 GB cards the first memory partition is floor-swept, so a tuner that always reads that partition gets an error value back; the vektorprime fbpa-first-active branch picks the first live partition instead. See 170tune.

Reported 8 GB
Source: @rh3dai, 2026-10-07
Source: @drew_2, 2026-10-07
Source: @vektor_prime, 2026-10-07
Source: @darkmaniac7, 2026-10-25 (lab notes)

RH-3D's settings on four water-cooled cards: about 202 W (2026-10-08)

On his 4-card S1 setup, water-cooled with HBM at 45 to 50 C, @rh3dai updated to the new vektorprime fork files and ran --ndiv 66 --offset 270 --clk 1410 --timings "REFRESH 24". The settings were accepted so far, at about 202 W average as reported in software. A few days earlier, in #off-topic, he had reported 164 TH/s on Pearl at about 200 W with --ndiv 66 --offset 240 --clk 1380.

Reported 8 GB
Source: @rh3dai, 2026-10-04
Source: @rh3dai, 2026-10-08

markshowa: lower NDIV for Pearl, and doubts about 55 C at 1,890 MHz (2026-10-26)

Replying to the 2026-10-03 post, @markshowa wrote that for Pearl mining you can lower the HBM clock: he runs NDIV 45 with refresh 24, which saves some heat and does not change the hash rate; for LLM work NDIV has to go back up. As far as he found, NDIV cannot be changed at runtime, only at boot. That conflicts with the idle p-state work, which reports switching between an idle NDIV of 30 and a busy NDIV of 64 (see P-states and idle power). He called 55 C on HBM at 1,890 MHz and 189 W while mining "dream values" unless the card runs on near-freezing water.

Reported 8 GB
Source: @markshowa, 2026-10-26