5 ms·

Yeah modern microcontrollers are probably less efficiently used than they could be, but the AGC essentially crashed twice during the lunar landing because it di

by gok 7y ago

Yeah modern microcontrollers are probably less efficiently used than they could be, but the AGC essentially crashed twice during the lunar landing because it didn't have enough compute available.

qubex 7y ago
That’s not entirely true. It suffered from a priority inversion.
- dfox 7y ago
  It suffered from simple CPU overload, in order to have priority inversion you need to have preemptive multitasking and synchronization primitives. The scheduler on AGC was essentially cooperative. Side note: that is partly what the 90's term “Network Operating System” is about. Both Cisco and Novell managed to market the hell out of the fact that both IOS and Netware are not real multitasking OSes but essentially giant event driven state machines (nice related buzzword: “run-to-completion scheduler”), which they managed to market as being a good thing.
oldandcold 7y ago
It didn't crash. It behaved as designed. Too much work to do, and the scheduler had to deal with priority problems.
- garaetjjte 7y ago
  It ran out of memory for allocating new tasks that were stacking on top of each other, and triggered BAILOUT restart. Navigation continued because it was restart protected by loading state checkpoint from dedicated memory area.
dave_blob 7y ago
The real fun with the AGC on landing happened on Apollo 14, with a flipped bit in the abort landing flag. Percussive maintenance temporarily flipped the bit back, giving enough time for ground control to develop a hack. Didn't they just ignore the warnings on Apollo 11? And I think it was non synced timing references rather than strictly resource availability that got them on 11
- dfox 7y ago
  The reason for warnings on 11 was that the landing was done in what was essentially an unsupported configuration. Still the “kernel” behaved as designed, didn't run low priority task (that was not supposed to be running in the first place) and raised an warning about doing so.
  - garaetjjte 7y ago
    Actually radar counter wasn't handled by any software task, it was hardware interrupt hardwired to steal CPU ALU cycles to increment/decrement memory location. Abnormally high steal time caused main navigation job to run too long, and it was getting scheduled again before previous instance finished. That led to memory exhaustion and BAILOUT software restart. source: https://www.doneyles.com/LM/Tales.html https://www.doneyles.com/LM/Tales.html
- jvm_ 7y ago
  The docking (like find your way back to the mothership radar) was still turned on, so the CPU was receiving the data and having to process it. The CPU was throwing an I'm overloaded signal, but dealing with it, as the process priority put docking radar as less priority than the landing sequence. So the CPU was complaining but still doing it's job. All this is from memory :P
  - dave_blob 7y ago
    Yes, just looked it up. I was (partially) wrong about the un-synced frequency though. The synchro's for the docking radar ran from a different power circuit than the AGC, and whilst they were frequency locked they weren't in phase; resulting in timings getting thrown off and the priority issues. Edit: Superb deep dive on AGC in Ars from last week https://arstechnica.com/science/2020/01/a-deep-dive-into-the-apollo-guidance-computer-and-the-hack-that-saved-apollo-14/ https://arstechnica.com/science/2020/01/a-deep-dive-into-the...

by gok 7y ago

Yeah modern microcontrollers are probably less efficiently used than they could be, but the AGC essentially crashed twice during the lunar landing because it didn't have enough compute available.

qubex 7y ago

That’s not entirely true. It suffered from a priority inversion.

dfox 7y ago
It suffered from simple CPU overload, in order to have priority inversion you need to have preemptive multitasking and synchronization primitives. The scheduler on AGC was essentially cooperative. Side note: that is partly what the 90's term “Network Operating System” is about. Both Cisco and Novell managed to market the hell out of the fact that both IOS and Netware are not real multitasking OSes but essentially giant event driven state machines (nice related buzzword: “run-to-completion scheduler”), which they managed to market as being a good thing.

oldandcold 7y ago

It didn't crash. It behaved as designed. Too much work to do, and the scheduler had to deal with priority problems.

garaetjjte 7y ago
It ran out of memory for allocating new tasks that were stacking on top of each other, and triggered BAILOUT restart. Navigation continued because it was restart protected by loading state checkpoint from dedicated memory area.

dave_blob 7y ago

The real fun with the AGC on landing happened on Apollo 14, with a flipped bit in the abort landing flag. Percussive maintenance temporarily flipped the bit back, giving enough time for ground control to develop a hack. Didn't they just ignore the warnings on Apollo 11? And I think it was non synced timing references rather than strictly resource availability that got them on 11

dfox 7y ago
The reason for warnings on 11 was that the landing was done in what was essentially an unsupported configuration. Still the “kernel” behaved as designed, didn't run low priority task (that was not supposed to be running in the first place) and raised an warning about doing so.
- garaetjjte 7y ago
  Actually radar counter wasn't handled by any software task, it was hardware interrupt hardwired to steal CPU ALU cycles to increment/decrement memory location. Abnormally high steal time caused main navigation job to run too long, and it was getting scheduled again before previous instance finished. That led to memory exhaustion and BAILOUT software restart. source: https://www.doneyles.com/LM/Tales.html https://www.doneyles.com/LM/Tales.html
jvm_ 7y ago
The docking (like find your way back to the mothership radar) was still turned on, so the CPU was receiving the data and having to process it. The CPU was throwing an I'm overloaded signal, but dealing with it, as the process priority put docking radar as less priority than the landing sequence. So the CPU was complaining but still doing it's job. All this is from memory :P
- dave_blob 7y ago
  Yes, just looked it up. I was (partially) wrong about the un-synced frequency though. The synchro's for the docking radar ran from a different power circuit than the AGC, and whilst they were frequency locked they weren't in phase; resulting in timings getting thrown off and the priority issues. Edit: Superb deep dive on AGC in Ars from last week https://arstechnica.com/science/2020/01/a-deep-dive-into-the-apollo-guidance-computer-and-the-hack-that-saved-apollo-14/ https://arstechnica.com/science/2020/01/a-deep-dive-into-the...