RIGOS advanced mining architecture program

[Deadbytes101]

RIGOS ADVANCED MINING ARCHITECTURE PROGRAM

MISSION

Turn RIGOS from a working CPU-mining appliance into the strongest
verifiable, local-first, failure-tolerant CPU-mining architecture on
commodity x86 hardware.

The target is not a startup H/s screenshot. The target is maximum
sustained useful work under heat, faults, reboot, network loss, and
long-duration operation.

RIGOS must eventually be able to compete honestly with:

• HiveOS and NiceHashOS on mining throughput and operations
• Talos Linux on immutable appliance discipline and rollback
• Alpine Linux on footprint and simplicity
• Redox OS on memory-safe architecture and fault isolation

No superiority claim is allowed without identical-hardware evidence.

NON-NEGOTIABLE DOCTRINE

• sustained H/s over transient max H/s
• accepted shares over synthetic benchmark numbers
• equal hardware, miner version, pool, thread count, and thermal state
• no unsupported MSR writes
• no permanently privileged miner
• every mutation must have readback, rollback, and restore
• one variable per benchmark round
• exact source commit, image SHA-256, manifest, and evidence JSON
• fail closed on uncertain hardware state
• local-first operation with no mandatory vendor cloud
• no tuning gain may increase rejects, throttling, crashes, or recovery time

ARCHITECTURE PHASES

PHASE 0 - FREEZE THE CURRENT AUTHORITY

• complete PR RandomX sustained-hash performance authority #15 exact image build from its final source head
• verify squashfs contents and MSR authority bytes
• flash only the exact verified image
• capture physical apply, readback, restore, and clean reboot evidence
• do not stack unrelated performance changes on PR RandomX sustained-hash performance authority #15

PHASE 1 - OBSERVABILITY TRUTH LAYER

• repair miner-health parsing of recent speed and share evidence
• publish atomic performance samples with monotonic timestamps
• record 10s, 60s, 15m, and rolling-window H/s
• record accepted, rejected, stale, reconnects, and restarts
• record package temperature, per-core clocks, throttling, pressure, and power when available
• distinguish unavailable data from zero values
• make benchmark scoring consume only authoritative samples

PHASE 2 - TOPOLOGY-AWARE RANDOMX PLANNER

• model physical cores, SMT siblings, NUMA nodes, cache hierarchy, and memory channels
• derive candidate thread and affinity plans from hardware topology
• never assume all logical CPUs are useful mining threads
• calculate cache pressure per candidate
• support exact 1/2/3/4-thread and affinity matrices on the current i3-2310M target
• keep planner output declarative and inspectable

PHASE 3 - CONTROLLED PERFORMANCE EXECUTOR

• apply one candidate plan at a time
• stop miner before any hardware-affecting mutation
• enforce warm-up, measurement, and cool-down windows
• restore the previous known-good plan after failure
• persist candidate, source, image, environment, and result identity
• reject benchmark runs with missing samples or environmental drift

PHASE 4 - THERMAL AND CLOCK STABILITY AUTHORITY

• establish warning, reject, and emergency thermal thresholds from evidence
• detect thermal throttling and clock collapse
• reject candidates that win H/s by exceeding the thermal envelope
• prefer sustained H/s after heat soak
• support controlled governor experiments only when benchmark evidence justifies them
• never hide throttling behind average values

PHASE 5 - MEMORY AND HUGE-PAGE ARCHITECTURE

• verify regular huge-page allocation and retention over time
• measure allocation latency, fallback, and fragmentation behavior
• gate 1 GiB pages on explicit CPU and kernel support
• evaluate boot-time reservation versus runtime allocation
• preserve fail-closed behavior when requested memory cannot be provisioned

PHASE 6 - MSR AND MICROARCHITECTURE PROFILES

• keep exact vendor/family/model allowlists
• store profile provenance and expected register values
• snapshot, read back, rollback, and restore every touched CPU
• reject partial and stale state before miner start
• expand support only with hardware documentation and physical proof
• never turn the miner itself into a privileged process

PHASE 7 - AUTONOMOUS STABILITY CONTROLLER

• bounded miner restart policy
• network loss and pool outage classification
• cooldown and retry budgets
• crash-loop containment
• rollback to last known-good performance plan
• abrupt-power-loss recovery
• persistent evidence of why recovery actions occurred
• observer and controller responsibilities must remain separate

PHASE 8 - IMMUTABLE APPLIANCE AND UPDATE PATH

• read-only system image
• explicit persistent-state boundary
• exact A/B image identity
• atomic update and deterministic rollback
• no internal-disk mutation
• rollback validation after failed boot or failed runtime gate
• configuration drift detection

PHASE 9 - LOCAL-FIRST FLEET ARCHITECTURE

• multi-node inventory and health truth
• signed profile distribution
• staged rollout and automatic rollback
• local alerts and diagnostics
• no required cloud account
• optional remote layer that cannot override local safety gates
• one-node failure must not destabilize other nodes

PHASE 10 - COMPETITOR BAKE-OFF

Run RIGOS, HiveOS, NiceHashOS, and a controlled minimal Linux baseline on
identical hardware with the same miner, version, pool, wallet, thread
plan, room conditions, and test duration.

Talos, Alpine, and Redox comparisons must target architecture properties,
not pretend they are mining distributions.

MEASUREMENT MATRIX

PERFORMANCE

• sustained H/s at 15 minutes, 1 hour, and 24 hours
• 1 percent low and variance
• accepted, rejected, and stale shares
• H/s per watt when reliable power data exists
• time to first accepted share

THERMAL

• maximum and sustained package temperature
• throttle events
• effective clocks after heat soak
• recovery time after thermal rejection

RELIABILITY

• miner crash recovery
• network unplug and replug
• DNS failure
• pool outage
• malformed runtime configuration
• missing dependency
• partial MSR failure
• abrupt power loss
• failed update and rollback

EFFICIENCY

• image size
• boot time
• idle RAM and CPU
• enabled service count
• runtime process count
• update bandwidth and rollback time

OPERATIONS

• setup-to-first-share time
• local diagnostics quality
• fleet deployment time
• alert latency
• rollback precision
• mandatory external service count

CURRENT PHYSICAL BASELINE

• Intel Core i3-2310M, 2 physical cores / 4 SMT threads
• 3 MiB L3
• 8 GiB dual-channel DDR3-1333
• exact 2-thread baseline around 340.7 to 341.2 H/s at 60 seconds
• max observed 341.7 H/s
• accepted/rejected observed 26/0
• regular huge pages 100 percent
• package temperature about 81 C
• sustained clock about 2.093 GHz
• no observed miner restarts
• current health observer has a known recent-speed parsing defect

RELEASE CLAIM GATES

RIGOS may claim a performance win only when all are true:

• same-hardware controlled comparison
• at least three repeat runs per candidate
• 15-minute minimum per tuning candidate
• 24-hour soak for the selected winner
• no rejected-share regression
• no thermal-throttle regression
• no restart or recovery regression
• exact evidence artifacts published

RIGOS may claim architectural superiority only for properties directly
measured and demonstrated. No broad claim such as "better than HiveOS",
"better than Talos", or "more secure than Redox" is allowed without a
precise scope and reproducible evidence.

IMMEDIATE EXECUTION ORDER

1. Finish PR RandomX sustained-hash performance authority #15 exact image and physical MSR proof.
2. Repair performance observability truth.
3. Build the topology-aware benchmark authority.
4. Run the controlled thread/affinity matrix.
5. Add thermal rejection and last-known-good rollback.
6. Run 24-hour single-node soak.
7. Run 7-day three-node stability campaign.
8. Run same-hardware competitor bake-off.

MOTTO

NO MARKETING MAGIC.
SAME MACHINE.
SAME WORKLOAD.
READ THE BYTES.
READ THE HASHES.
READ THE TEMPERATURE.
READ THE FAILURE.