dusk

Classic triple modular redundancy^1,2,3 has a fixed threshold. Three processors vote, two can still detect a disagreement, and one cannot outvote anything, so the system stops. With no repairs and no ground team in reach, that throws away the last processor’s whole remaining life.

The Mru whitepaper⁴ proposes a shrinking quorum instead: vote while three processors are alive, compare while two are, and self-check on one. Falling back from TMR to simplex is not new. The question here is what it is worth when no ground team can command it. dusk simulates 10,000 missions and plays each policy against the same failing hardware.

The shrinking quorum matches fixed TMR while three processors survive. It pulls ahead once TMR starts to stop and keeps working long after. It never does less on any single mission, because the two are identical until TMR stops. The cost is a few wrong results in the single-processor tail, which TMR never lives long enough to make.

When the ground can help

Real spacecraft do not run TMR alone. When a string fails, a ground team diagnoses it and commands a fallback by hand. Voyager, launched in 1977, still has that team: it now switches off instruments to live within a power supply that falls about 4 watts a year⁵. Interstellar Probe is designed to last at least 50 years⁶. So the fair baseline is TMR plus a ground team that switches it to self-checking simplex, once it loses its majority, for as long as support lasts.

• Answer time barely matters. A fallback 1 day or 6 months after it is needed gives the same result to two decimals. The lost days are small next to decades of single-processor life.
• What matters is whether anyone is still there. If ground support never ends, autonomy adds nothing to throughput, because the ground does the same thing by hand. The whole gain comes from the years after support ends. With 49 years of support (Voyager’s so far) against a 98-year median hardware life, it is still 1.25x. The ratio of the two is what counts: shorter-lived hardware moves the curve left. With a 60-year Weibull scale, 50 years of support leaves 1.10x instead of 1.25x.

The model

Each mission is a day-by-day fault-injection run⁷. Every policy plays against the same fault history and the same upsets, so any difference between policies is the policy.

Useful work is days of correct output, weighted by throughput and summed over the whole mission: the accomplishment measure performability analysis uses for systems that degrade¹⁰. A wrong result (an undetected error) is a day of output nobody knew was bad. Intervals are 95% paired bootstrap intervals over whole missions¹¹. Curves are monotone cubics, which cannot overshoot the data¹².

How much the result depends on the assumptions

The parameters are plausible orders of magnitude, not values fitted to flight data. So each one the model cannot pin down is varied on its own, with the rest at default, over 10,000 missions per value.

All three policies

Means over the same 10,000 missions. Years are mission years.

What this does not claim

• The parameters are illustrative, not calibrated. The claim is the shape of the trade, and the sweep shows where it holds.
• The ground team is perfect: it always diagnoses correctly and its command always works. Real anomaly response is slower and less certain, so this flatters the ground.
• A day is the unit of work. Power, thermal limits, and duty cycling are not modelled.
• Two or more upsets in a vote are always caught as a split, which slightly flatters every voting policy equally.

Run it yourself

Rust, no dependencies. Results depend only on the seed, and every number on this page comes from the same seeds.

git clone https://github.com/mruspace/dusk
cd dusk
cargo run --release              # the default scenario
cargo run --release -- --ground  # against TMR with a ground team
cargo run --release -- --ground --scale-years 60  # shorter-lived hardware
cargo run --release -- --sweep   # sensitivity

Cite this

@software{binns2026dusk,
  author = {Binns, Will},
  title  = {dusk: A Monte Carlo of Redundancy Policies on Hardware That Only Ever Decays},
  year   = {2026},
  url    = {https://github.com/mruspace/dusk},
  note   = {Results at https://dusk.mru.space}
}

References

1. R. E. Lyons and W. Vanderkulk, “The Use of Triple-Modular Redundancy to Improve Computer Reliability,” IBM Journal of Research and Development, vol. 6, no. 2, pp. 200–209, 1962.
2. J. von Neumann, “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components,” in Automata Studies, C. E. Shannon and J. McCarthy, Eds. Princeton University Press, 1956, pp. 43–98.
3. D. P. Siewiorek and R. S. Swarz, Reliable Computer Systems: Design and Evaluation, 3rd ed. A K Peters, 1998.
4. W. Binns, “Mru: A Fault-Tolerant Operating System for Thousand-Year Autonomous Operation,” 2026. doi:10.5281/zenodo.20579438
5. NASA Jet Propulsion Laboratory, “NASA Turns Off 2 Voyager Science Instruments to Extend Mission,” March 5, 2025. jpl.nasa.gov
6. P. C. Brandt, E. A. Provornikova, et al., “Interstellar Probe: Humanity’s Exploration of the Galaxy Begins,” Acta Astronautica, vol. 199, pp. 364–373, 2022. doi:10.1016/j.actaastro.2022.07.011
7. M.-C. Hsueh, T. K. Tsai, and R. K. Iyer, “Fault Injection Techniques and Tools,” Computer, vol. 30, no. 4, pp. 75–82, 1997.
8. W. Weibull, “A Statistical Distribution Function of Wide Applicability,” Journal of Applied Mechanics, vol. 18, no. 3, pp. 293–297, 1951.
9. A. Avižienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing,” IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 1, pp. 11–33, 2004.
10. J. F. Meyer, “On Evaluating the Performability of Degradable Computing Systems,” IEEE Transactions on Computers, vol. C-29, no. 8, pp. 720–731, 1980.
11. B. Efron, “Bootstrap Methods: Another Look at the Jackknife,” The Annals of Statistics, vol. 7, no. 1, pp. 1–26, 1979. doi:10.1214/aos/1176344552
12. F. N. Fritsch and R. E. Carlson, “Monotone Piecewise Cubic Interpolation,” SIAM Journal on Numerical Analysis, vol. 17, no. 2, pp. 238–246, 1980. doi:10.1137/0717021