4 ms·
Well, that's what happened: "On Apollo 11, each time a 1201 or 1202 alarm appeared, the computer rebooted, restarted the important stuff, like steering the desc
by elteto 5y ago
Well, that's what happened: "On Apollo 11, each time a 1201 or 1202 alarm appeared, the computer rebooted, restarted the important stuff, like steering the descent engine and running the DSKY to let the crew know what was going on, but did not restart all the erroneously-scheduled rendezvous radar jobs."
Resource exhaustion was not immediate after reboot because the faulted tasks were low priority and did not get started after reboot right away. I can't even imagine what would have happened if one of the high priority tasks had been the problematic one.
- garaetjjte 5y ago>but did not restart all the erroneously-scheduled rendezvous radar jobs That's wrong. Excess CPU time was stolen by radar counter hardware, not by any software (counters worked by stopping CPU and using its ALU). Problem arised because main guidance routine (SERVICER job) was scheduled always every 2 seconds (by READACCS task/interrupt), and with excess stolen time it didn't finish in time, leading to scheduling of another SERVICER before previous instance finished. This repeated until memory ran out for stacking another SERVICER job. There was no "erroneously-scheduled rendezvous radar jobs", job that needed shedding was multiple stacked instances of SERVICER itself.