Hacker News Reader

Comment by gok | Hacker News Reader

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.

View on HN

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

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.

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

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

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...

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

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.

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

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.

Reply on news.ycombinator.com