45 releases 94 tags

RSS feed

• v1.38.0 85c077aecd

  Compare

  v1.38.0 Stable

  dvb-projekt released this 2026-10-09 13:29:44 +00:00 | 23 commits to main since this release

  Added

  • Admin → Workers: a list of every known worker (search; connected,
    recently active or idle) with a Remove button behind a
    confirmation — only a live stratum session ("connected") blocks it.
    When more than 500 workers are known the page says it lists only the
    500 most recently seen of the total. A second table lists leftovers
    without a worker entry (best shares or VarDiff memory whose workers
    row the retention already evicted, GET /api/admin/workers/orphans),
    removable the same way.
    DELETE /api/admin/workers with the JSON body {"user": "<worker>"}
    (a body, because worker names can contain /) deletes the worker's
    rows in workers, best_shares, best_shares_all_time and
    vardiff_state (the V1 key and the :sv2 snapshot) in one
    transaction, and drops the in-memory reject breakdown and the Sv2
    VarDiff snapshot cache. Share history and found blocks stay. A worker
    connected over V1, V1 + TLS or Sv2 is refused with 409 (its session
    would write its state back), an unknown one with 404; the name is
    matched exactly as the miner authorized, edge blanks included. Every
    attempt, refused or failed ones too, is audited as worker.delete.
    /api/workers carries current_is_connected per worker and the
    total of known workers.
  • dvb-WarpTune: quick calibration ("Quick check now" on the devices
    page, pool action quick, audited as tune.calib.quick). The same
    stages as a full calibration, no clock search, each starting from the
    voltage its step runs at now. Every 10 mV step is first screened on the
    chip counters for about ten minutes: the start voltage gives the
    baseline error mean, and a step down is good while its error mean stays
    under baseline + 1.0 point (shifted by the miner's temperature slope),
    no chip domain latches off and no chip stands out. The candidate is the
    last good step plus one; only it gets the full share verdict (200 / 400
    shares), short of good → one step up and again, up to the start
    voltage. Apply adds a reserve of 30 mV (instead of
    calib_margin_mv), and the card tags the result as a quick one. About
    1.5–2 h per Eco/Max stage instead of 6–13 h for a full job. Offered
    only on a firmware with a chip error rate (1-minute rate or per-chip
    readings; hashrateMonitor alone is not enough); a step without a
    single error reading after twice the screen time (2 × 10 min) fails
    the stage with no_counters. Journal events screen and
    candidate; a screened step is never a result on its own.
  • dvb-WarpTune: periodic re-check. 28 days after an Apply WarpTune
    starts a quick calibration on its own, one step below the applied
    voltage — once per apply (also across a service restart), live only,
    only on a miner whose regulator mode is Max (the job pins Max for its
    screen and share verdict; Eco, Balanced or PV-governed miners keep the
    quick-check button), on a firmware with a chip error rate, never while
    another job is open. Its result waits on the card as a suggestion
    (apply or discard as before; the hint says what passed and failed
    mean).
  • dvb-WarpTune: chain re-init at the hand point (WarpAxe boards with
    a chip chain; not the dev-kit CPU miner). A chip domain latched off at
    the hand point had nowhere to go — a restore bump to the hand point is
    a no-op there (Octaxe 2026-10-09: six domains on five chips off after a
    cold start, 9.1 instead of 11.4 TH/s). WarpTune now power-cycles the
    chain: it journals the open re-init (chain_off), sends
    POST /api/v1/chips/off, waits up to 10 s for the firmware to confirm
    the chain stopped (chainStopped, phase OFF, core voltage reading
    under 100 mV), holds the rail off for chain_reinit_off_hold_s
    ([defaults] and per miner, 5–60, default 15 s; ~5.5 s re-latched
    another domain on the Octaxe), sends POST /api/v1/chips/on and waits
    up to 90 s for phase READY. The chips are never left off: an
    unconfirmed OFF still gets /on, a failing /on is retried three
    times with backoff and then the board is restarted
    (POST /api/system/restart); after a WarpTune restart mid-sequence
    the open chain_off is recovered (chain stopped → /on, running →
    closed) — only for WarpTune's own OFF, never for chips switched off in
    the WarpAxe UI. The domain counters are judged again 60 s after the
    real READY (the firmware refills them from zero). Live only, at most
    three an hour (the count survives a restart) with a 5-minute settle
    after each; a latch the re-init could not answer (settle, hourly
    bound, calibration running) is retried later without a new event;
    past the bound the latch is left and stays reported. A re-init also
    waits for a steady state (chip temperature within 3 °C of the target,
    fan within ±5 % for two minutes, five minutes since the boot and since
    the last READY). A domain off again within five minutes of the READY
    after a re-init for it is a relapse; two in a row give it up — no more
    re-inits for that domain, the others still get theirs — and the
    devices page and the journal (domain_given_up) say it keeps dropping
    out at that point, a margin question (hand voltage or clock); re-armed
    by a point change, a board boot or after a day, and read back from
    the journal at a WarpTune start. NerdNOS boards are excluded for now.
    Journal kind chain_reinit (rail off after / never read off, attempt
    or reboot, READY after, cause of a failure); the devices page shows
    the last re-init.
  • dvb-WarpTune: per-chip readings from GET /api/v2/dashboard
    (NerdOS ≥ 1.1.1-alpha4, WarpAxe ≥ 0.1.19; one parser for both): the
    hashrate and the hashrate lost to errors per chip. They feed the
    dead-chip guard's stall verdict without a hashrateMonitor, stand in
    for the 1-minute chip error rate where the firmware has none (NerdOS;
    gated by chip_error_trigger as before), and one chip whose error
    share stands out against the median of the others (≥ 3 points and
    ≥ 3×, at least three chips) is a second witness that the point is short
    of good. The journal's sample summary records the share
    (chip_error_pct). A firmware that answers 404 is asked again once an
    hour.
  • Devices page: a finished calibration message (stopped, failed) and a
    chain re-init can be dismissed (×) — per viewer, kept in the browser,
    the next message shows again. While a calibration runs and under a
    finished one the card says since when the applied calibration is in
    force ("calibrated since …").

  Changed

  • dvb-WarpTune, calibration: the yield rule. A stage's result is the
    good voltage above every bad one with the most hashrate per watt,
    (100 − chip error %) / W, with the chip error as the mean of the
    verdict window's readings (at least three; never a lone or cumulative
    reading); the lowest good
    voltage only when nothing above it is better by at least 0.5 %. Chip
    errors cost hashrate one to one at the pool (2026-10-07/08: the Gamma
    at 100.0 % of its expected hashrate, the Gaia at 94.0 % with ~6.2 %
    chip errors), so a voltage that is stable by the shares can still earn
    less per kWh than the step above it. Gamma Max 640 MHz on the journal
    of 2026-10-05: the old rule took 1030 mV (6.3 % chip errors), the new
    one 1040 mV (1.9 %). The card names the preferred voltage per stage and
    why. Journals without error rates keep the old rule. The live voltage
    search uses the same comparison — a step judged good whose errors cost
    more than its power saving goes back up — only with
    chip_error_trigger = true, on error means of at least three readings
    on the present point and with a 1 % gate instead of 0.5 % (the step
    above is remembered with its mean for seven days).
  • Stratum: the VarDiff of the NerdMiner class (CPU and ESP32 miners such
    as the WarpAxe dev kit) steps up by at most ×2 per retarget
    (max_step_up, an operator's lower max_step is kept); the window
    stays 8 shares, the way down (÷4) and the idle decay are unchanged,
    the NerdNOS class too. V1 and Sv2 alike. A lucky run of eight fast
    shares tripled the difficulty of a ~290 kH/s dev kit on 2026-10-08
    (about 13 instead of 30 shares an hour for 40 minutes until the way
    back).

  Fixed

  • dvb-WarpTune: the dead-chip guard tells a share-path stall from dead
    chips. Three verdicts now: electrical death (VR output 0 mV, silent
    chain restarts) makes the step a ceiling as before; a hashrate of 0
    with the chip counters dark or absent sends the miner to stock and
    restarts it, but holds off only the present step; a hashrate of 0
    while the chip counters still run is a stall — the miner is restarted
    at stock after six decisions (3 min), nothing is marked, no trial
    voltage fails, and a calibration stage does not count the restart as a
    guard failure. Gaia 2026-10-07: the firmware read 0 for three ticks
    with its counters at ~2 TH/s; the guard marked 320 to 380 MHz at once
    and Eco sat at 300 MHz for the hold.

  ---

  dvb-WarpPool v1.38.0 — Downloads

  Docker

  git.warppool.org/dvb-projekt/dvb-warppool:v1.38.0 (multi-arch amd64+arm64, ohne v-Präfix)

  Native packages

  • Linux .deb: amd64 + arm64 → apt install ./dvb-warppool_*.deb
  • Linux .rpm: amd64 + arm64 → dnf install ./dvb-warppool-*.rpm
  • Linux AppImage: x86_64 + aarch64 portable
  • Linux tarballs: x86_64 + aarch64 for manual installs
  • macOS .dmg: added shortly after publish (built separately) — or build from source
  • Windows .msi: paused since the forge migration (no Windows runner yet)

  Signatures

  • SHA256SUMS + cosign bundle (SHA256SUMS.bundle, project key)
  • SBOM (SPDX) for all dependencies

  Verify (project public key cosign.pub in the repo root):

  cosign verify-blob \
    --key cosign.pub \
    --bundle SHA256SUMS.bundle \
    SHA256SUMS
  sha256sum --check SHA256SUMS
  

  First-time setup: run dvb-warppool-setup for the first-run wizard.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads

  ---

  • SHA256SUMS
    0 downloads · 2026-10-09 13:30:39 +00:00 · 1.2 KiB
  • SHA256SUMS.bundle
    0 downloads · 2026-10-09 13:30:39 +00:00 · 3.6 KiB
  • dvb-WarpPool-v1.38.0-aarch64.AppImage
    0 downloads · 2026-10-09 13:29:45 +00:00 · 23 MiB
  • dvb-WarpPool-v1.38.0-aarch64.dmg
    1 download · 2026-10-09 13:30:46 +00:00 · 26 MiB
  • dvb-WarpPool-v1.38.0-x86_64.AppImage
    1 download · 2026-10-09 13:29:45 +00:00 · 24 MiB
  • dvb-WarpPool-v1.38.0-x86_64.dmg
    0 downloads · 2026-10-09 13:30:53 +00:00 · 28 MiB
  • dvb-warppool-1.38.0-1.aarch64.rpm
    0 downloads · 2026-10-09 13:29:46 +00:00 · 18 MiB
  • dvb-warppool-1.38.0-1.x86_64.rpm
    0 downloads · 2026-10-09 13:29:46 +00:00 · 19 MiB
  • dvb-warppool-v1.38.0-aarch64-apple-darwin.tar.gz
    0 downloads · 2026-10-09 13:30:58 +00:00 · 23 MiB
  • dvb-warppool-v1.38.0-aarch64-unknown-linux-gnu.tar.gz
    2 downloads · 2026-10-09 13:29:47 +00:00 · 24 MiB
  • dvb-warppool-v1.38.0-x86_64-apple-darwin.tar.gz
    0 downloads · 2026-10-09 13:31:03 +00:00 · 24 MiB
  • dvb-warppool-v1.38.0-x86_64-unknown-linux-gnu.tar.gz
    0 downloads · 2026-10-09 13:29:47 +00:00 · 25 MiB
  • dvb-warppool_1.38.0-1_amd64.deb
    0 downloads · 2026-10-09 13:29:47 +00:00 · 18 MiB
  • dvb-warppool_1.38.0-1_arm64.deb
    0 downloads · 2026-10-09 13:29:47 +00:00 · 17 MiB
  • sbom.spdx.json
    0 downloads · 2026-10-09 13:29:48 +00:00 · 1.3 MiB