| Source file | Consolidated | Known | Coverage ·durable/known | Last activity |
|---|
Known = bytes the fleet has ever verified for this source (rangemap). Consolidated = those bytes
durably folded into the hub's never-evicted per-source sparse file. Coverage = consolidated ÷ known —
100% means every byte we know is durably archived; a shortfall is orphaned (rangemap remembers it but
the backing bytes were evicted before consolidation, so the hub can't re-serve it). Last activity =
the most recent BeamCore transfer of this source file, or a fresher verified range-learn on the hub if
there is one — so it keeps reading true across hub restarts and for files whose chunk grid the fleet has
already fully learned. live·net = a transfer of this file is in flight;
in rotation·net = used within the last ~30-minute transfer cycle.
BeamCore's API names sources only by an opaque id, so the file is identified by matching the transfer's
(jittered) chunk size against the sizes in the fleet rangemap — those are unique per source.
·net = NETWORK-WIDE, not "your boxes worked on it" — this hub is shared across fleets, and the
two jobs BeamCore fires each half-hour go to different pools: the ~100 GiB
ecx_20_b_gb.bin job is pool=qualified (prism_final_score_desc,
151 miners) while the 1 GiB test1gb.bin job is pool=qualifying
(qualifying_equal_share_rotation, 26 miners). A qualified orchestrator is never a
candidate for the qualifying rotation, so it takes zero chunks of that file however busy the
row looks here. Per-fleet share is the Orchestrators / Workers tables, not this one.
| Miner | Hotkey | UID | Pool | PRISM | Success | Verified Mbps | Tasks | Penalty | Failed PoP | Weight % | Ready |
|---|
Tracked by hotkey (ss58), not UID — a UID slot can be lost and re-registered under a different hotkey. The UID column shows whichever slot our hotkey currently holds; dark = the hotkey isn't registered. Verified Mbps is server-timed per BATCH at its slowest chunk over the dispatch→result-ingestion window (post-07-17 there is no accept/lease leg). PRISM = 0.4·throughput + 0.6·reliability, fleet-normalized — but emissions are tiered on raw score (PRISM×tasks): the top-24 split ~80%, so task volume + zero missed transfers matter more than headline Mbps. Source: data.b1m.ai.
| Worker | Fleet | Warmed ·of hub | Intervals | Sources | In sync | Blob L0 | Free disk | Last beacon |
|---|
Sparse coverage = each worker's local durable sparse tier (its splice corpus), reported as physical
disk allocation (st_blocks) — so it reads a little high and isn't directly comparable box-to-box (a
heavy-ingest fleet allocates more blocks at the same unique coverage). In sync therefore
judges against the hub's servable content (its consolidated archive, shown in the header): a worker
is ✓ in sync once it has warmed everything the hub can serve,
behind by the shown gap while it's still pulling, stale if
it hasn't beaconed recently, or no sparse if it isn't running warm-sparse. The
remaining hub gap (e.g. rx_50_p) is unbacked bytes no worker can pull — see the coverage table.
All fleets on the shared hub are shown so each team can see their own boxes.
| Worker | Hotkey | Live | Status | Region | Tasks | OK | Fail | Cache ·L0 | Free | Last seen | Last beacon |
|---|
Every worker we run, by hotkey (always listed, even with no recent tasks). Conn / tasks / last-seen from BeamCore; Last beacon = the last per-chunk timing beacon we received (our own pipeline). ○ = not connected / not found on BeamCore.
| Class | Tasks | Get | Put | Result ack | Window | DP Mbps | Window Mbps ·≈scored |
|---|
p50 per stage from worker beacons. cache-served = the chunk went out with no source GET (cache/L0-L1 exact hit · splice = range assembled from overlapping verified blocks · race:* = cache-hit PUT raced across the mesh, winner named · racesplice:* = spliced-assembly PUT raced across the mesh, 07-21). fetched = a source GET was on the critical path (pipeline/serial single-box · racemiss:* = GET+PUT raced across the mesh). Since the 2026-07-17 protocol there is no accept/lease: the scored window is dispatch → result ingestion and a batch is scored at its slowest chunk — so Window Mbps (bytes ÷ offer→result-ack) is the closest thing to what BeamCore scores, and the p90/tail matters more than the median. DP Mbps (bytes ÷ data-plane only) is diagnostic. Result ack = result-submit → BeamCore ack; it is inside the scored window now.
| Worker | Mode | Bytes | GET | PUT | Window | Window Mbps ·≈scored | ✓ |
|---|
Green mode = cache-served (no source GET). Window = offer→result-ack (≈ the scored window); ✓ ● = BeamCore accepted our result, ◐ = sent but superseded/late, ○ = failed.
| Worker | Region | Solo p50 | Sync p50 | Contention | n solo/sync | Recent mbps |
|---|
Each worker does a single-stream 30 MiB presigned PUT to R2 between real chunks (skipped while the worker is mid-transfer). Solo = that worker alone; Sync = all workers fire simultaneously. Contention = solo÷sync; ≫1 means per-worker throughput collapses when co-located workers transmit together — a shared NIC/host bottleneck. The sparkline is recent per-sample mbps (newest at right). This is the raw single-stream PUT rate — the PUT leg of the scored window (the window also includes the GET, when one runs, and the result submit).