A run of weeks, cut to five minutes
The experiment was registered for days to weeks on the satellite. The intro call said five minutes or less, so the faults moved into the first few seconds.
The registration said the software would run for days to weeks, under 5% of one core, and log real upsets next to the satellite’s own dosimetry. The intro call on 14 October changed the first part: an experiment runs in a window of five minutes or less, if you want to watch it. The advice came from TU Graz, which runs the platform. Every run proposed on that fleet now fits five minutes. A long run with real upsets needs another route.
The dosimetry went on the 16th. PRETTY’s dosimeter data is not available to experimenters, so the sensor block’s counts stand on their own, and the roadmap line that promised the comparison is gone.
Five minutes changed the schedule twice. The first package put the faults at ticks 50, 150, 300 and 600 at a 25% CPU share, because the 5% default was for runs of days. The registration had said 5%, so the share went back the same morning and the faults moved to ticks 20, 60, 120 and 240, with the sensor scanned every 250 ticks instead of 1,000. On the laptop that is about 200 ticks a second. On the flight processor it turned out to be 45, so the last fault lands about five seconds in, and the other 105 seconds are the last replica working alone.
What five minutes buys: the two policies on the same seed and faults, back to back, the tick rate, the wall time of each reaction, and proof that every path runs on the flight system. What it cannot buy is a real upset. At 520 km a 64 MB block sees about one a day to one a week. The expected count in five minutes rounds to zero. It was zero.