dusk
What a shrinking quorum buys on hardware that only ever decays
Classic triple modular redundancy 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. dusk simulates 10,000 missions and plays each policy against the same failing hardware.
Useful output over the mission
Mean over 10,000 missions. 100% is a full voting set working every day. The shaded area is the shrinking quorum’s total useful work.
- shrinking quorum (Mru)
- fixed TMR
- standby simplex
Show the numbers
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. 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.
What autonomy adds, by how long ground support lasts
Shrinking quorum vs TMR with a ground team that commands the same fallback 30 days after it is needed. At 0 there is no ground team. Band: 95% interval.
Show the numbers
- 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. At Voyager’s 49 years so far, it is still 1.25x.
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.
Useful work vs fixed TMR
Higher is better; 1.0x is no gain. A line spans the results across that parameter’s values; the vertical rule is the default run.
Wrong results vs standby simplex
Lower is better; 100% is no gain.
Show the numbers
At an upset rate of 1e-5 there are only about 20 wrong results across all 10,000 missions, so that row’s wrong-result share is noisy. Treat it as a rough figure.
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 -- --sweep # sensitivity