Help

1. Reading the dashboard

Hashrate

One figure for each part that mines: GPU for the card(s), CPU for the CPU threads, and Total, their sum, only when both mine. A GPU rig mines on the card alone by default (THREADS=0), so it shows the GPU figure and no CPU or Total card; a CPU-only machine shows only the CPU one. With CPU threads added, the GPU number is still essentially the total — on the RTX 3080 it is about 1.61 MH/s of 1.62 MH/s, with two CPU threads contributing roughly 7 kH/s, under half a percent. Units switch by themselves: H/s, kH/s, MH/s, GH/s.

The figure is an average over the last ten seconds, not an instant reading, so it moves smoothly. A drop that lasts one ten-second tick is noise; a drop that stays is not.

Effective hashrate

Next to the hashrate there is a second figure. The hashrate is the raw work of the card: every hash it computes. Effective is the work the pool accepted: the accepted shares of the last ten minutes, each counted as the hashes it takes on average to find a share at its difficulty. The percentage compares the two over the same ten minutes. On the RTX 3080 in normal running it reads close to 100% — 99.4% measured. Over the long run it can only be lower than raw, and the gap has three causes:

• Stale shares — valid work that arrived after the pool had moved to a new job. It cost hashes and earns nothing.
• Wrong shares from an overclock — a card pushed too far computes answers the pool refuses. The card still reports full hashrate, because it is still hashing; only effective drops. This is the case the figure is best at catching: raw flat, effective falling, rejected climbing.
• Rate limit — the miner leaves a minimum gap between two share submissions, 5 ms by default, and drops a share found inside it. In normal running this costs next to nothing; it can bite only in the first minutes after a (re)connection, while the pool's difficulty is still low. See Advanced: Dropped shares.

Effective is a statistical estimate built from shares, not a measurement, so over a short window it can come out above raw — that is luck, not extra work. It rests on about a hundred shares per ten minutes, so a few percent up or down from one window to the next means nothing either. What counts is a drop that lasts, together with stale or rejected shares going up. During the first ten minutes after a start the window is shorter, and the card says so.

Efficiency

GPU hashrate divided by GPU power draw, in kH/W — how much work you get per watt. The 3080 at 300 W and 1.61 MH/s gives about 5.4 kH/W. This is the number to watch when tuning the power limit: raw hashrate almost always goes up with more watts, efficiency usually does not.

With several cards, both numbers are for all of them: the hashrate of every card divided by the power of every card. The GPUs table gives each card's own power and kH/W.

The 30-minute chart

The last half hour of two figures: the raw total hashrate, as the orange area, and the effective hashrate, as the green line on top of it (see Effective hashrate). The green line starts ten minutes after the miner does, once its window is full. The miner keeps the samples, in memory, so reloading the tab or opening the dashboard on a second device shows the whole half hour. Nothing is written to disk: when the miner restarts, the chart starts empty. It is there to show shape: a flat line is healthy, a sawtooth means something is throttling, a cliff means the miner reconnected or the card stopped.

First-start tuning

The best work size and kernel mode depend on the card, so on the first start on a card the miner tries the candidates one after another, about 8 minutes in all. It mines and sends shares all the while. A blue banner at the top says so, with the trial in progress (for each card, on a rig with several) and the time left. When it ends the banner turns green with the result: the work size, the kernel mode and the hashrate, and how much that is over the untuned default, which is measured as one of the trials. OK closes it. The result is saved, and every later start applies it at once - no banner, no trials. A new driver, or another GPU_LOOKUP_GAP, counts as a new card. If the miner stops before the end, nothing is saved and the tuning starts again next time. AUTOTUNE=0 in config.env turns it off; AUTOTUNE_FORCE=1 tunes again.

Log

The status line the miner prints in its console every 10 seconds, the last 100 lines of it (about sixteen minutes): hashrate (total, CPU, GPU or each card), shares as submitted/accepted/rejected/stale, and uptime. The dashboard shows the time each line was printed and the hashrates in the same units as the rest of the page (1.61 MH/s); the console keeps the raw figure (1610100.36 H/s). Like the chart, it is kept in memory and starts empty when the miner restarts. The newest line is at the top; scroll down to look back, and the lines you are reading stay in place while new ones arrive above them.

Session, rig

• Difficulty — the share difficulty the pool has set for you. It changes on its own as the pool adjusts; it is not something you control.
• Total hashes — since this miner process started, not since the rig was built.
• Current job — the pool's job ID. It should change every few seconds. If it stops changing for minutes, the pool connection is stale.
• Uptime — of the miner process. It resets on every restart, including the automatic one after an intensity change.
• GPUs active — how many cards this miner initialised.

2. Shares: accepted, rejected, stale

A share is a proof of work sent to the pool. Three outcomes, and they do not mean the same thing at all.

The bar under the three numbers shows their proportions. A healthy bar is almost entirely green with a thin amber sliver.

The Shares card shows the counters of the newest line in the log, so its numbers are always the ones on the log's top line. That line is printed every 10 seconds, so the card can be up to 10 seconds behind the pool; until the first line exists, a few seconds after a start, it shows the live counters instead.

3. Temperature, power, load

• GPU temperature — green below 70 °C, amber 70–80 °C, red above 80 °C. This is the core temperature. The 3080 in this rig sits around 62 °C.
• GPU load — should be pinned at 100% while mining. Anything less means the card is waiting for something.
• Power draw — live watts. With a 300 W limit the card will sit just under it, around 299 W.
• Memory used — this miner's scratchpad. Each work-item needs 128 KB, so 16384 work-items is about 2 GB. It does not change while mining.
• CPU temperature — the host processor, read from the kernel. Same colour thresholds. Unrelated to the GPU.

A reading the machine cannot give is left out, and the whole card when none is available — a computer without an NVIDIA card, or without its driver. The GPU readings come from the NVIDIA driver: through nvidia-smi on Linux, through nvml.dll (or nvidia-smi) on Windows. The CPU temperature is Linux-only for now.

4. The settings, one by one

At the top, under the token, is the rig's own configuration: where it mines and with what. Below it, the tuning. Three tuning controls are in plain view because they are the ones worth touching. The rest are behind Advanced because on this algorithm they mostly do not help, and a wrong value there costs more than it gains.

Mining configuration

What it holds. The wallet the pool pays, the pool and its port, how many CPU threads mine, and which graphics cards are used. There is no worker name: the pool has none and would ignore it. The same settings as in config.env, and saving writes them there.

Saving. Nothing changes until you press Save & restart at the bottom of the Mining configuration box; it saves every field of the box at once. While something is changed but not saved, the box is outlined in orange and says what: Not saved yet: CPU threads 2 → 3. The Save & restart next to GPU intensity saves the intensity only, and asks first if the box above has unsaved changes.

CPU threads. auto uses half the logical cores, and the list says what that comes to on this machine. Under it is what the CPU is actually adding right now, as a share of the total. On a rig with a card that is well under one percent — the RTX 3080 does about 99.6% of the work next to two CPU threads — which is why this setting barely matters there. 0 — GPU only is offered only while a card is mining; with no card mining, 0 would mine nothing.

Graphics cards. Listed by name as the driver reports them, with their PCI address, which tells two cards of the same model apart: all of them, one, or several. With a single card there is nothing to choose and the row just names it.

Checked before anything is written. A wallet is 0x followed by 40 hex digits, and the all-zero example address is refused. The pool must be a bare host name or address — no stratum+tcp://, no port — and the miner checks that it resolves, because a typo there would leave it retrying forever. The page checks as you type; the miner checks again and has the last word, so a save can never leave a configuration it will not start with.

Wallet and pool ask twice. They decide where the work and the payout go, so a change to either asks for confirmation, naming the new address or pool, before anything is sent.

Saving restarts the miner, as a change of intensity does, and the page reconnects by itself. The file is rewritten in place: every other line and comment is kept, and the previous version is saved next to it as config.env.bak. Which file that is shows under the block's title: on Linux usually /etc/dagcore-miner/config.env; on Windows the config.env in the miner's own folder, next to the .exe — created there by the first save if it did not exist.

Locked fields. A setting given on the miner's command line wins over config.env on every start, so changing it here would change nothing. Such fields are shown but locked, marked set on the command line.

Pause mining

The button in the header. Pausing stops the mining threads and closes the connection to the pool; the header says paused and a banner with a Resume button stays up. The page itself keeps working, because the miner that serves it is still running — which is also why there is no Stop button: it would take the page away with it.

A pause is not saved. If the miner restarts, it mines again. A pause is refused while a clock test runs, since the test needs shares to reach a verdict.

GPUs: one card at a time

The GPUs table lists every card mining, with its hashrate, power, temperature and kH/W, and a total row when there are several. Pause on a row stops that card alone: it takes no new work and its row says PAUSED, while the other cards and the pool connection carry on. Resume brings it back. The log says when a card pauses and resumes, and the status line every 10 seconds shows it as GPU[1]: PAUSED.

This works only in a browser on the rig itself, at http://127.0.0.1:8881 — even when METRICS_BIND=0.0.0.0 lets the rest of the network see the dashboard, from another computer the table is read-only and the buttons are greyed out. It needs the control token, like the other controls. A card cannot be paused while a clock test runs or while it is being tuned.

The miner tells "the rig itself" by the address the connection comes from. A port forward on the rig (Windows netsh interface portproxy), a reverse proxy or a tunnel makes requests from the whole network arrive from 127.0.0.1, and then the token is the only thing in the way - see Security.

A pause of a card is not saved: when the miner restarts, every card in the configuration mines again. To leave a card out for good, change Graphics cards under Mining configuration.

Power limit

What it does. Caps how many watts the card may draw. Below the cap the card clocks itself freely; at the cap it pulls its clocks down to stay under.

Sensible values. The 3080 allows 100–350 W and ships at 320 W. This rig runs 300 W. Coming down from 320 to 300 costs very little hashrate and saves 20 W — that is the trade this setting is for. Going much below roughly 70% of the default starts costing real hashrate.

Risk. None to the hardware; the card cannot be damaged by a lower limit. The only cost is throughput. Use Efficiency (kH/W) to judge it: if efficiency goes up and hashrate barely moves, the lower limit was worth it.

This is the one setting that stays usable while a clock test is running, and it takes effect immediately with no test of its own.

On Windows clock offsets cannot be set from the miner: the Windows driver refuses them ("Not Supported"), so the memory and core offsets are not shown. The clock locks, the power limit and GPU intensity are there as on Linux, but a memory lock cannot go above the clock the driver allows while computing (9251 MHz on an RTX 3080). Raise the memory with MSI Afterburner instead: Memory clock here shows the clock that results, but the lock range does not know about Afterburner's offset, so leave the memory lock off. Afterburner's offset moves the clock one to one, the Linux offset below by half: +1200 here is about +600 there. Without it Windows mines slower — on an RTX 3080 at 300 W, 1.43–1.53 MH/s at 9251 MHz, against 1.63 MH/s at 10277 MHz raised in Afterburner and 1.61 MH/s on Linux with +1200. The locks and the power limit need the miner started as administrator (start.bat).

Memory offset — the main tuning knob

Why this one. The algorithm this miner runs is scrypt with N=1024, which needs a 128 KB scratchpad per work-item. It spends its time moving data in and out of VRAM, not doing arithmetic — it is memory-bound. Faster memory means more hashes. Faster core does not.

How the number works. The offset is given in data-rate MHz, and the actual memory clock moves by half of it. The card has a fixed table of memory clocks, and the offset shifts the whole table:

memory clock = base table entry + offset / 2

RTX 3080 base table: 9501, 9251, 5001, 810, 405 MHz
with offset +1200  : 10101, 9851, 5601, 1410, 1005 MHz

That is why the dashboard can offer a lock at 9851 MHz even though the card's own supported-clocks list stops at 9501 — the list is the table before the offset.

How to tune. Small steps. +100 or +150 at a time, Apply, then let the ten-minute test finish before the next step. The failure mode is not a crash: it is rejected shares, and they can take minutes to appear. On this rig +1200 is stable; that does not mean +1200 is right for another 3080, because memory silicon varies between cards.

Intensity

What it does. Asks for more work-items per batch, 0–100. More work-items keep the card busier between round trips.

Why it needs a restart. The scratchpad buffers are allocated once, when the GPU is initialised. Changing their size means allocating again, which means starting over. The dashboard saves the value and the miner restarts — systemd brings it back on Linux, and on Windows it starts itself again in the same window. It comes back in a few seconds and the page reconnects by itself.

Why 100 is not a magic number. The request is clamped to what VRAM can actually hold. Intensity 100 asks for 2²⁰ work-items, which at 128 KB each would be 128 GB — far past any card. On the 3080 the limit works out to 16384 work-items, about 2 GB, and both intensity 80 and intensity 100 end up there. Raising intensity past the point where VRAM is the constraint changes nothing at all.

Risk. None beyond the restart itself, which costs a few seconds of mining.

Advanced: Memory clock

What it does. Pins the memory to one clock instead of letting the driver pick.

Why the values are restricted. A lock has to land on an entry of the card's table — with the offset applied, that is 10101, 9851, 5601, 1410 or 1005 MHz on this rig. Anything you type is snapped to the nearest one. What gets saved is the step, not the frequency, so when you later change the offset the lock follows the table instead of being left behind.

"Auto (driver)" is usually the right answer. While mining, the card already sits at its top memory state the whole time. Locking it there gains nothing, and locking it lower only costs hashrate. The setting is here for diagnosis — pinning memory low to see whether a problem is memory-related — not for everyday tuning.

Advanced: Core clock and Core offset

Why they barely matter here. The algorithm is waiting on memory. Giving the core more clock speeds up a part that is already idle-waiting. On this rig the core sits around 1800–1830 MHz under the power cap and raising it does not move the hashrate.

When a negative offset does help. A lower core costs almost no hashrate but frees watts inside the power limit — and those watts go to the memory controller, which is the part doing the work. On a power-limited card a core offset of −100 or −200 can leave hashrate unchanged while dropping temperature, or let the same power budget sustain a higher memory clock. That is the real use for these two controls.

Risk. A positive core offset that the silicon cannot hold produces the same rejected shares as a bad memory offset, for no gain.

Advanced: Adopt current state

What it is for. A rig tuned with another tool before this miner arrived. Rather than re-entering the same numbers and sitting through a test to reach the state the card is already in, Adopt writes what is applied right now into the miner's own settings, with no test. From then on the miner re-applies them on every start.

Offsets are adopted automatically. Clock locks are not — they have checkboxes, unticked by default, and you have to tick what you know is locked.

Why you have to tell it. NVML — the NVIDIA library this all goes through — can set a locked clock and clear it, but it has no call to read one back. There is no way to ask the card "is memory locked, and to what". Earlier versions of this page guessed by watching whether a clock held still; it was wrong in both directions on this very rig, once re-adding a lock that had just been removed. Guessing was removed. You know what you locked; the software cannot find out.

Advanced: Dropped shares

What it shows. Shares the card found that the miner never sent to the pool, because they came less than the submit gap after the previous one. Two figures: how many in the last ten minutes, with their share of everything found in that time, and the total since the miner started. Then the gap in use.

Read the ten-minute figure, not the total. The total comes almost entirely from the first minutes after a start: the pool begins every connection at a low difficulty and raises it over the first minutes (vardiff), and until it does the card finds a share in nearly every batch of work, about one every 10 ms on an RTX 3080. The old default gap, 20 ms, dropped every other one of those; the current 5 ms lets them through. Once the difficulty settles, drops all but stop. A large total is not an ongoing loss.

Why it is here and not on the front page. It is not a fault. A dropped share is not a rejected one: the card did nothing wrong, and it says nothing about an overclock. It is the price of the limiter, and on its own it would look like an alarm.

What to do with it. Usually nothing; keep the 5 ms default. If your config.env still says SUBMIT_MIN_INTERVAL_MS=20 — it came with older installs — change it to 5. Only if the ten-minute figure stays above a percent or two in normal running is it worth going lower: SUBMIT_MIN_INTERVAL_MS=2, or 0 for no limit, then restart the miner. Fewer drops means more accepted work, as long as the pool tolerates the burst; if it starts refusing shares or disconnecting, go back up. It cannot be changed from this page.

Advanced: GPU candidates

What it shows. The card works in batches — on an RTX 3080, 16384 hashes, about 10 ms each. Found counts every share the card turned up in them. Beyond the first in a batch counts the second, third and later ones of the same batch.

Why that second number matters. Until this version the card reported only one share per batch, and the others were dropped before anyone counted them. That hardly matters once the pool's difficulty has settled — a batch then almost never holds two — but in the first minutes of every connection nearly every batch does, and those shares were lost. The second number is what the change recovers.

How they are sent. The first share of a batch goes to the pool at once. The others come a fraction of a millisecond after it, too close for the 5 ms gap between submissions, so a queue sends them one at a time: half a millisecond apart, never more than 8 per batch, and only while fewer than 8 submissions are still waiting for the pool's answer — sending everything at once could trip the pool's flood protection. A share whose job changes while it waits is discarded, since the pool would only call it stale. Sent by the queue counts the ones that went out; not sent the ones over the per-batch limit, the ones with no room in the queue, and the discarded ones. The limits are SUBMIT_BURST_MAX, SUBMIT_BURST_GAP_US and SUBMIT_MAX_INFLIGHT in config.env; SUBMIT_BURST_MAX=0 goes back to one share per batch.

If did not fit ever appears, a batch found more shares than the 64 slots it reports; that should not happen at any difficulty the pool uses.

5. How a change is made

1. One setting at a time. If two things change together and rejected shares appear, you cannot tell which caused it — and the test cannot either.
2. Type a value and press Apply. That is the whole action. The change goes to the card immediately; you see it in the readings within a few seconds.
3. A ten-minute test starts by itself for clock and offset changes. A banner appears at the top of Settings with a countdown and a live count of rejected shares. You do not have to wait or keep the page open — the miner runs the test whether the browser is there or not.
4. While the test runs, the other clock controls are locked, with the reason on each row. The power limit stays available; changing it restarts the test, because the power cap changes the very thing being measured.
5. If rejected shares appear, the change is undone automatically and nothing is saved. The banner turns red and tells you what it went back to.
6. If ten clean minutes pass, the value is saved and re-applied on every future start. The banner turns green.

Cancel test — in the banner — stops a test early and puts the previous value back immediately. Use it when you change your mind, or when the rig clearly does not like what you did and you do not want to wait.

Default — on each row — restores the card's own factory value, not zero. For the power limit that is the card's default in watts (320 W on the 3080). For a clock it means Auto, handing the domain back to the driver. For an offset it means 0. You never need to press Default before changing something: Apply replaces whatever is there.

What is saved where. Settings you apply here are written to the miner's own override file, not to the file an operator edits. The miner reads both at startup: the operator's configuration first, then your overrides on top of it.

6. Every message you can see

While a test is running

Test results

Connection and restart

Controls unavailable

Power limit

Clock warning

7. Troubleshooting

Rejected shares started appearing after an overclock

The card is computing wrong answers. It will not crash and the temperature may look fine — rejected shares are the only symptom. If you are inside a test, it reverts by itself within ten minutes. If the value was already saved, lower it: go back one step, Apply, and let the test confirm. Memory offset is the usual culprit; core offset is next.

Hashrate is drifting down while temperature looks fine

Almost always memory heat. The core temperature you can see says nothing about the memory, and on Linux the memory junction temperature is not exposed by the driver at all. Symptoms: hashrate sags over ten or twenty minutes with the core in the sixties, and improves after the rig is left idle.

What helps: lower the memory offset a step, lower the power limit (less heat in the whole card), or improve airflow over the back of the board.

The miner did not come back after a restart

systemctl status bdag-miner
journalctl -u bdag-miner -n 50 --no-pager

The log shows what it refused at startup. A common one is a setting the card will not accept any more — the miner prints a warning naming the key and keeps mining without it.

Only one of my cards is being used

Check the GPUs active figure on the dashboard against how many cards the machine has. If it says 1 and you have more, the miner was told to use one.

The setting is GPU_DEVICE in /etc/dagcore-miner/config.env:

sudo sed -i 's/^GPU_DEVICE=.*/GPU_DEVICE=all/' /etc/dagcore-miner/config.env
sudo systemctl restart dagcore-miner

The installer sets this for you: one card gives GPU_DEVICE=0, more than one gives all.

I lost the control token

It is stored on the rig, readable only by root:

sudo cat /etc/dagcore-miner/api-token

It is also printed once, the first time it is created, in journalctl -u bdag-miner. To force a new one, delete the file and restart the miner — every browser that had the old token will need the new one.

Where the logs are

journalctl -u bdag-miner -f            # live
journalctl -u bdag-miner -n 100        # last 100 lines
journalctl -u bdag-miner --since today

Where the settings live

Two files on purpose: tuning never touches the file that defines the rig, and throwing all tuning away is one deleted file. The dashboard does write config.env, but only through Mining configuration: five settings, checked first, the rest of the file kept as it was. To inspect them:

sudo cat /etc/dagcore-miner/config.env
sudo cat /var/lib/dagcore-miner/overrides.env

To throw away all dashboard tuning and go back to the operator's configuration, delete the overrides file and restart.

8. Security

Changing settings does need the token, but that only protects writes. The token itself travels in plain HTTP — anyone who can watch the traffic on the network can copy it and then change your clocks.

What that means in practice:

• The miner binds to 127.0.0.1 by default, so out of the box the dashboard is reachable only from the rig itself.
• To open it to your network, the rig must be started with METRICS_BIND=0.0.0.0, or better with the rig's own LAN address so it is not offered on every interface. The miner prints a warning in its log whenever it binds beyond localhost.
• Port forward, reverse proxy or tunnel: make sure the control token is set. If you leave METRICS_BIND=127.0.0.1 and open the dashboard to the network some other way - Windows netsh interface portproxy, nginx, Caddy, a Cloudflare or ssh tunnel - the miner sees every request from the network as coming from 127.0.0.1, the rig itself. Pausing a card, which is otherwise kept to the rig, then works from anywhere the forward reaches, and the control token is the only protection left for every control, the wallet included. Check that the miner has a token (it prints Control API token at start; the file is api-token, next to the .exe on Windows, /etc/dagcore-miner/api-token on Linux), paste it only into browsers you trust, and replace it (delete the file and restart) if it has been shown to anyone else. A plain TCP forward such as portproxy adds no X-Forwarded-For header, so the miner cannot tell the difference itself.
• Never expose this to the internet. Not with a port forward, not through a router's "DMZ". It is a plain HTTP endpoint with a shared secret and your wallet address on it.
• If you want it from outside the LAN, tunnel instead of forwarding:

  ssh -L 8881:127.0.0.1:8881 user@rig

  then open http://127.0.0.1:8881/ on your own machine. The traffic is encrypted and nothing is exposed.
• The token is stored in your browser's local storage, per browser. Clearing site data means entering it again.