Did the 1202 error and associated reboot prevent disaster on Apollo 11 landing?What were the problems on the Apollo 11 lunar module?Why did a phase mismatch between the Apollo 11 LM's RR and AGC generate a large numbers of interrupts?Provenance of the Apollo 11 landing presented in a NASA PR filmHow did the Apollo computers evaluate transcendental functions like sine, arctangent, log?How does the Apollo LM ascent guidance program P12 actually work?Why did Neil Armstrong alone, not NASA, end up coming up with the first words uttered on the moon?How many AGC keystrokes did an Apollo rendezvous take?How did the Apollo guidance computer handle parity bit errors?How did sloshing prevent the Apollo Service Module from moving safely away from the Command Module and how was this fixed?How far off did Apollo 11 land?How much could “sublimator operation” have possibly contributed to Apollo 11's “sizable downrange miss”?Why did a phase mismatch between the Apollo 11 LM's RR and AGC generate a large numbers of interrupts?
Academic progression in Germany, what happens after a postdoc? What is the next step?
Should I intervene when a colleague in a different department makes students run laps as part of their grade?
Should students have access to past exams or an exam bank?
In the Schrödinger equation, can I have a Hamiltonian without a kinetic term?
How do I respond appropriately to an overseas company that obtained a visa for me without hiring me?
Why didn't General Martok receive discommendation in Star Trek: Deep Space Nine?
Why don't short runways use ramps for takeoff?
Introduction to the Sicilian
Easy way to get process information from a window
Would people understand me speaking German all over Europe?
Prepare a user to perform an action before proceeding to the next step
Balancing Humanoid fantasy races: Elves
PCB design using code instead of clicking a mouse?
Applying for mortgage when living together but only one will be on the mortgage
Why does the Rust compiler not optimize code assuming that two mutable references cannot alias?
How to efficiently shred a lot of cabbage?
May a hotel provide accommodation for fewer people than booked?
Reducing the time for rolling hash
Word for giving preference to the oldest child
Best Ergonomic Design for a handheld ranged weapon
Move arrows along a contour
Numerically Stable IIR filter
Adding a (stair/baby) gate without facing walls
How to innovate in OR
Did the 1202 error and associated reboot prevent disaster on Apollo 11 landing?
What were the problems on the Apollo 11 lunar module?Why did a phase mismatch between the Apollo 11 LM's RR and AGC generate a large numbers of interrupts?Provenance of the Apollo 11 landing presented in a NASA PR filmHow did the Apollo computers evaluate transcendental functions like sine, arctangent, log?How does the Apollo LM ascent guidance program P12 actually work?Why did Neil Armstrong alone, not NASA, end up coming up with the first words uttered on the moon?How many AGC keystrokes did an Apollo rendezvous take?How did the Apollo guidance computer handle parity bit errors?How did sloshing prevent the Apollo Service Module from moving safely away from the Command Module and how was this fixed?How far off did Apollo 11 land?How much could “sublimator operation” have possibly contributed to Apollo 11's “sizable downrange miss”?Why did a phase mismatch between the Apollo 11 LM's RR and AGC generate a large numbers of interrupts?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
$begingroup$
Most accounts of the famous 1202 error reported by the AGS during landing of the Apollo 11 LM characterize the event as result of the successful operation of the AGS, flushing an resetting an overloaded computer while preserving critical data needed to proceed on restart.
However Alan Klumpp's retelling describes a situation in which overloading of the AGS could result in disaster:
...throttle and steering commands ... were often incompletely
computed, and were queued for later completion. Any attempt to queue a
command when the queue was already full (about five commands) would
cause the computer to flush the queue and issue the alarm. But when
the radar’s power supply was in phase, queued commands, valid only at
some remote past time, could be completed and issued in reverse order,
momentarily taking control to guide the LM off its normal landing
trajectory. Although flushing commands would cause alarms, issuing
faulty commands would not. Simulations showed that faulty commands
could put the LM on a crash course, and guidance would attempt to take
the LM to the landing site via a trajectory that passed beneath the
lunar surface.
However, it's not clear when or if this situation actually occurred. Is this passage meant to confirm the general account: that the flushing behavior associated with a 1202 error prevented this disaster from occurring. Or is he saying that this could have been going on when the 1202 errors were reported, or at some other time during the mission? (In fact, one interpretation is that the out of phase overloading that triggered the 1202 errors insured against such a catastrophe.)
Did the 1202 error and associated reboot prevent disaster on Apollo 11 landing?
history flight-computer apollo-11 guidance
asked Jul 21 at 20:37
oromeorome
2202 silver badges11 bronze badges
$endgroup$
add a comment |
$begingroup$
Most accounts of the famous 1202 error reported by the AGS during landing of the Apollo 11 LM characterize the event as result of the successful operation of the AGS, flushing an resetting an overloaded computer while preserving critical data needed to proceed on restart.
However Alan Klumpp's retelling describes a situation in which overloading of the AGS could result in disaster:
...throttle and steering commands ... were often incompletely
computed, and were queued for later completion. Any attempt to queue a
command when the queue was already full (about five commands) would
cause the computer to flush the queue and issue the alarm. But when
the radar’s power supply was in phase, queued commands, valid only at
some remote past time, could be completed and issued in reverse order,
momentarily taking control to guide the LM off its normal landing
trajectory. Although flushing commands would cause alarms, issuing
faulty commands would not. Simulations showed that faulty commands
could put the LM on a crash course, and guidance would attempt to take
the LM to the landing site via a trajectory that passed beneath the
lunar surface.
However, it's not clear when or if this situation actually occurred. Is this passage meant to confirm the general account: that the flushing behavior associated with a 1202 error prevented this disaster from occurring. Or is he saying that this could have been going on when the 1202 errors were reported, or at some other time during the mission? (In fact, one interpretation is that the out of phase overloading that triggered the 1202 errors insured against such a catastrophe.)
Did the 1202 error and associated reboot prevent disaster on Apollo 11 landing?
history flight-computer apollo-11 guidance
asked Jul 21 at 20:37
oromeorome
2202 silver badges11 bronze badges
$endgroup$
$begingroup$
A recent article in WIRED wired.com/story/apollo-11-mission-out-of-control has some interesting background on the queue, etc.
$endgroup$
– Mark Stewart
Jul 24 at 18:37
add a comment |
$begingroup$
Most accounts of the famous 1202 error reported by the AGS during landing of the Apollo 11 LM characterize the event as result of the successful operation of the AGS, flushing an resetting an overloaded computer while preserving critical data needed to proceed on restart.
However Alan Klumpp's retelling describes a situation in which overloading of the AGS could result in disaster:
...throttle and steering commands ... were often incompletely
computed, and were queued for later completion. Any attempt to queue a
command when the queue was already full (about five commands) would
cause the computer to flush the queue and issue the alarm. But when
the radar’s power supply was in phase, queued commands, valid only at
some remote past time, could be completed and issued in reverse order,
momentarily taking control to guide the LM off its normal landing
trajectory. Although flushing commands would cause alarms, issuing
faulty commands would not. Simulations showed that faulty commands
could put the LM on a crash course, and guidance would attempt to take
the LM to the landing site via a trajectory that passed beneath the
lunar surface.
However, it's not clear when or if this situation actually occurred. Is this passage meant to confirm the general account: that the flushing behavior associated with a 1202 error prevented this disaster from occurring. Or is he saying that this could have been going on when the 1202 errors were reported, or at some other time during the mission? (In fact, one interpretation is that the out of phase overloading that triggered the 1202 errors insured against such a catastrophe.)
Did the 1202 error and associated reboot prevent disaster on Apollo 11 landing?
history flight-computer apollo-11 guidance
asked Jul 21 at 20:37
oromeorome
2202 silver badges11 bronze badges
$endgroup$
Most accounts of the famous 1202 error reported by the AGS during landing of the Apollo 11 LM characterize the event as result of the successful operation of the AGS, flushing an resetting an overloaded computer while preserving critical data needed to proceed on restart.
However Alan Klumpp's retelling describes a situation in which overloading of the AGS could result in disaster:
...throttle and steering commands ... were often incompletely
computed, and were queued for later completion. Any attempt to queue a
command when the queue was already full (about five commands) would
cause the computer to flush the queue and issue the alarm. But when
the radar’s power supply was in phase, queued commands, valid only at
some remote past time, could be completed and issued in reverse order,
momentarily taking control to guide the LM off its normal landing
trajectory. Although flushing commands would cause alarms, issuing
faulty commands would not. Simulations showed that faulty commands
could put the LM on a crash course, and guidance would attempt to take
the LM to the landing site via a trajectory that passed beneath the
lunar surface.
However, it's not clear when or if this situation actually occurred. Is this passage meant to confirm the general account: that the flushing behavior associated with a 1202 error prevented this disaster from occurring. Or is he saying that this could have been going on when the 1202 errors were reported, or at some other time during the mission? (In fact, one interpretation is that the out of phase overloading that triggered the 1202 errors insured against such a catastrophe.)
Did the 1202 error and associated reboot prevent disaster on Apollo 11 landing?
history flight-computer apollo-11 guidance
history flight-computer apollo-11 guidance
asked Jul 21 at 20:37
oromeorome
2202 silver badges11 bronze badges
asked Jul 21 at 20:37
oromeorome
2202 silver badges11 bronze badges
edited Jul 28 at 17:24
orome
asked Jul 21 at 20:37
oromeorome
2202 silver badges11 bronze badges
asked Jul 21 at 20:37
oromeorome
2202 silver badges11 bronze badges
asked Jul 21 at 20:37
oromeorome
2202 silver badges11 bronze badges
2202 silver badges11 bronze badges
$begingroup$
A recent article in WIRED wired.com/story/apollo-11-mission-out-of-control has some interesting background on the queue, etc.
$endgroup$
– Mark Stewart
Jul 24 at 18:37
add a comment |
$begingroup$
A recent article in WIRED wired.com/story/apollo-11-mission-out-of-control has some interesting background on the queue, etc.
$endgroup$
– Mark Stewart
Jul 24 at 18:37
$begingroup$
A recent article in WIRED wired.com/story/apollo-11-mission-out-of-control has some interesting background on the queue, etc.
$endgroup$
– Mark Stewart
Jul 24 at 18:37
$begingroup$
A recent article in WIRED wired.com/story/apollo-11-mission-out-of-control has some interesting background on the queue, etc.
$endgroup$
– Mark Stewart
Jul 24 at 18:37
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
I agree with your comment "it's not clear when or if this situation actually occurred." From reading both Klumpp's account and his colleague Don Eyles' book Sunburst and Luminary I do not think we have enough information to know if the situation could have existed on Apollo 11. I think we know it did not exist on Apollo 11, because the radar power supply was not in phase, and Klumpp says
But when the radar’s power supply was in phase, queued commands,
valid only at some remote past time, could be completed and issued in
reverse order, momentarily taking control to guide the LM off its
normal landing trajectory.
(Emphasis mine)
Here is Eyles' account of the problem from pp. 215-16 of S&L.
As 1970 dawned, with P66 Auto finished and onboard for the upcoming
mission, Allan and I found time to reconsider the problem that so
nearly ruined the Apollo 11 landing — deprivation of processor time,
which we called TLOSS-— but we went about it in different ways.
Allan kept the IBM 360 humming as he ran simulations on the Apollo 13
rope to see how it behaved under varying amounts of TLOSS. We already
knew that if the amount of TLOSS was just right, then during a period
of high activity incomplete SERVICER jobs could accumulate in the
Executive queue. The last thing the SERVICER did on each pass was send
information to the DSKY for display. Just before it did that it issued
attitude commands, and before that, throttle commands. What concerned
Allan was what would happen if a SERVICER job was cut off before the
throttle or attitude command was sent out. If enough of these
suspended jobs accumulated, a software restart would occur, as it did
on Apollo 11, and the suspended jobs would disappear. But what if the
computational burden eased before they were flushed?
What could happen, Allan found, was that the suspended jobs (Allan
dubbed them “lurkers”) could come back to life, unaware that they had
been in hibernation, and proceed to issue an attitude or throttle
command applicable to an earlier point in the trajectory. Suddenly the
LM might maneuver to the wrong attitude. The worst cases were when
suspended jobs that accumulated during P64 were executed after the
transition to P66.
On March 4 Allan put out a carefully written memo describing
“a collection of known manifestations of time loss.” Allan described
eight separate modes of bad behavior, starting at a TLOSS of about 8
percent. In an unusual precaution Allan signed the memo, and asked
Gerry Levine to sign as having approved it.
(Emphasis mine)
My interpretation is that for the problem to happen,
- the rendezvous radar power supply would have to be in sync
- something would have to happen that made the SERVICER jobs run long and not complete
- Whatever caused 2) would have to go away before the situation got bad enough to flush the queue
We know that on Apollo 11 1) was not the case, but I do not know if we have enough information to know if 2) happened or not.
This answer attempts to explain the part about the radar power supply being out of phase.
answered Jul 21 at 22:12
Organic MarbleOrganic Marble
72.8k4 gold badges212 silver badges312 bronze badges
$endgroup$
2
$begingroup$
@orome I think you only got the alarms if the computer actually restarted. This kind of intermediate problem where jobs were suspended, then resumed, but the computer didn't restart may have resulted in trajectory problems with no alarm - which is worrisome indeed. That's all my interpretation though.
$endgroup$
– Organic Marble
Jul 21 at 23:23
1
$begingroup$
Ah, yes, I think you're right. The alarm indicates that things are ok because there's been a restart. (Basically it's the AGS's way of saying, I'm overloaded, and am going to deal with it by taking a sec to clean up and return to high priority tasks.) The described freighting situation would only have arisen in the absence of a 1202 alarm.
$endgroup$
– orome
Jul 21 at 23:28
1
$begingroup$
The account by Eyles - see linked answer - doesn't mention drifting. He makes it sound like there was a relationship established at powerup, and only some were bad enough to cause issues. But I can't rule out what you say.
$endgroup$
– Organic Marble
Jul 22 at 15:42
1
$begingroup$
I think that's correct. It sounds like the phase relationship was established at power up (can we know for sure?), so the situation mentioned in Klumpp remark is just something that could happen and not meant to describe what was going on during the Apollo 11 landing.
$endgroup$
– orome
Jul 23 at 17:40
1
$begingroup$
I have a follow up about why the RR and AGC being out of phase cause so many interrupts in the first place.
$endgroup$
– orome
Jul 27 at 19:52
|
show 7 more comments
$begingroup$
The lunar module had two computers. The 1202 alarm happened on the Lunar Guidance Computer, which did many different tasks -- in fact, the 1202 alarm was a warning that its multitasking system was at risk of being (but not yet completely) overloaded.
There also was the Abort Guidance System. Its computer and software were completely different designs than the LGC, developed by different contractors. The AGS had only one job: get the LM back into space, where it could be picked up by the CSM. It couldn't be overloaded by the extra tasks that the LGC had to do. Although the AGS never had to be used on an actual mission, it was thoroughly tested, and there's no reason to think it would malfunction.
Apollo crews practiced recognizing when an abort was needed, and activating the AGS. The ArsTechnica article you cite even states as much:
And, to be clear, an abort during landing was not a minor thing. The procedure would have involved Armstrong pressing the "ABORT STAGE" button on the LM’s panel, which would have fired explosive bolts and guillotines and separated the LM’s ascent stage from its descent stage. Then, the ascent engine would fire, doing its best to add velocity back to the descending ship, attempting to push it back into some kind of stable orbit so that the crew could find and rendezvous with the Command Module. It was something the crews trained to do — but it wouldn’t have been easy. And it would have carried with it the stigma of an aborted mission.
The 1202 issue did not interfere with the control of the spacecraft, and that's why the crew was given the go-ahead to land. However, had it actually somehow interfered with control of the spacecraft, Armstrong's training was to immediately activate the AGS. So no disaster would have happened, but the opportunity to land on the moon would be lost.
answered Jul 21 at 21:36
DrSheldonDrSheldon
12.7k4 gold badges48 silver badges112 bronze badges
$endgroup$
$begingroup$
Sorry that's not the question: the question hinges on the relationship between "queued commands, valid only at some remote past time, could be completed and issued in reverse order" could happen, and what that has to do with the situation that occurred (when the 1202 happened).
$endgroup$
– orome
Jul 21 at 21:45
$begingroup$
It's not data that gets queued, it's tasks (much like Unix process threads). The Executive program decides which task runs next based on priority. During a soft reboot, the task queues are cleared out; they don't get corrupted or reversed. It's not going to issue steering commands in reverse order.
$endgroup$
– DrSheldon
Jul 21 at 22:07
1
$begingroup$
According to Eyles' book, the tasks get restarted, and that's what causes the issuance of the bad commands. The case happens when the tasks are paused but the system recovers before a reboot.
$endgroup$
– Organic Marble
Jul 21 at 22:17
2
$begingroup$
Ghaa. Simulators didn't have real AGCs? 😳
$endgroup$
– Russell Borogove
Jul 21 at 22:29
1
$begingroup$
@RussellBorogove no, they were too expensive and getting current 'ropes' was an issue. They were emulated in simulation software. The Shuttle training simulators had real flight computers, but I think that was an innovation. The B-52 bomber simulators I worked on also had emulated flight computers. The ISS training simulators have emulated onboard computers too.
$endgroup$
– Organic Marble
Jul 21 at 22:32
|
show 2 more comments
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "508"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fspace.stackexchange.com%2fquestions%2f37549%2fdid-the-1202-error-and-associated-reboot-prevent-disaster-on-apollo-11-landing%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
I agree with your comment "it's not clear when or if this situation actually occurred." From reading both Klumpp's account and his colleague Don Eyles' book Sunburst and Luminary I do not think we have enough information to know if the situation could have existed on Apollo 11. I think we know it did not exist on Apollo 11, because the radar power supply was not in phase, and Klumpp says
But when the radar’s power supply was in phase, queued commands,
valid only at some remote past time, could be completed and issued in
reverse order, momentarily taking control to guide the LM off its
normal landing trajectory.
(Emphasis mine)
Here is Eyles' account of the problem from pp. 215-16 of S&L.
As 1970 dawned, with P66 Auto finished and onboard for the upcoming
mission, Allan and I found time to reconsider the problem that so
nearly ruined the Apollo 11 landing — deprivation of processor time,
which we called TLOSS-— but we went about it in different ways.
Allan kept the IBM 360 humming as he ran simulations on the Apollo 13
rope to see how it behaved under varying amounts of TLOSS. We already
knew that if the amount of TLOSS was just right, then during a period
of high activity incomplete SERVICER jobs could accumulate in the
Executive queue. The last thing the SERVICER did on each pass was send
information to the DSKY for display. Just before it did that it issued
attitude commands, and before that, throttle commands. What concerned
Allan was what would happen if a SERVICER job was cut off before the
throttle or attitude command was sent out. If enough of these
suspended jobs accumulated, a software restart would occur, as it did
on Apollo 11, and the suspended jobs would disappear. But what if the
computational burden eased before they were flushed?
What could happen, Allan found, was that the suspended jobs (Allan
dubbed them “lurkers”) could come back to life, unaware that they had
been in hibernation, and proceed to issue an attitude or throttle
command applicable to an earlier point in the trajectory. Suddenly the
LM might maneuver to the wrong attitude. The worst cases were when
suspended jobs that accumulated during P64 were executed after the
transition to P66.
On March 4 Allan put out a carefully written memo describing
“a collection of known manifestations of time loss.” Allan described
eight separate modes of bad behavior, starting at a TLOSS of about 8
percent. In an unusual precaution Allan signed the memo, and asked
Gerry Levine to sign as having approved it.
(Emphasis mine)
My interpretation is that for the problem to happen,
- the rendezvous radar power supply would have to be in sync
- something would have to happen that made the SERVICER jobs run long and not complete
- Whatever caused 2) would have to go away before the situation got bad enough to flush the queue
We know that on Apollo 11 1) was not the case, but I do not know if we have enough information to know if 2) happened or not.
This answer attempts to explain the part about the radar power supply being out of phase.
answered Jul 21 at 22:12
Organic MarbleOrganic Marble
72.8k4 gold badges212 silver badges312 bronze badges
$endgroup$
2
$begingroup$
@orome I think you only got the alarms if the computer actually restarted. This kind of intermediate problem where jobs were suspended, then resumed, but the computer didn't restart may have resulted in trajectory problems with no alarm - which is worrisome indeed. That's all my interpretation though.
$endgroup$
– Organic Marble
Jul 21 at 23:23
1
$begingroup$
Ah, yes, I think you're right. The alarm indicates that things are ok because there's been a restart. (Basically it's the AGS's way of saying, I'm overloaded, and am going to deal with it by taking a sec to clean up and return to high priority tasks.) The described freighting situation would only have arisen in the absence of a 1202 alarm.
$endgroup$
– orome
Jul 21 at 23:28
1
$begingroup$
The account by Eyles - see linked answer - doesn't mention drifting. He makes it sound like there was a relationship established at powerup, and only some were bad enough to cause issues. But I can't rule out what you say.
$endgroup$
– Organic Marble
Jul 22 at 15:42
1
$begingroup$
I think that's correct. It sounds like the phase relationship was established at power up (can we know for sure?), so the situation mentioned in Klumpp remark is just something that could happen and not meant to describe what was going on during the Apollo 11 landing.
$endgroup$
– orome
Jul 23 at 17:40
1
$begingroup$
I have a follow up about why the RR and AGC being out of phase cause so many interrupts in the first place.
$endgroup$
– orome
Jul 27 at 19:52
|
show 7 more comments
$begingroup$
I agree with your comment "it's not clear when or if this situation actually occurred." From reading both Klumpp's account and his colleague Don Eyles' book Sunburst and Luminary I do not think we have enough information to know if the situation could have existed on Apollo 11. I think we know it did not exist on Apollo 11, because the radar power supply was not in phase, and Klumpp says
But when the radar’s power supply was in phase, queued commands,
valid only at some remote past time, could be completed and issued in
reverse order, momentarily taking control to guide the LM off its
normal landing trajectory.
(Emphasis mine)
Here is Eyles' account of the problem from pp. 215-16 of S&L.
As 1970 dawned, with P66 Auto finished and onboard for the upcoming
mission, Allan and I found time to reconsider the problem that so
nearly ruined the Apollo 11 landing — deprivation of processor time,
which we called TLOSS-— but we went about it in different ways.
Allan kept the IBM 360 humming as he ran simulations on the Apollo 13
rope to see how it behaved under varying amounts of TLOSS. We already
knew that if the amount of TLOSS was just right, then during a period
of high activity incomplete SERVICER jobs could accumulate in the
Executive queue. The last thing the SERVICER did on each pass was send
information to the DSKY for display. Just before it did that it issued
attitude commands, and before that, throttle commands. What concerned
Allan was what would happen if a SERVICER job was cut off before the
throttle or attitude command was sent out. If enough of these
suspended jobs accumulated, a software restart would occur, as it did
on Apollo 11, and the suspended jobs would disappear. But what if the
computational burden eased before they were flushed?
What could happen, Allan found, was that the suspended jobs (Allan
dubbed them “lurkers”) could come back to life, unaware that they had
been in hibernation, and proceed to issue an attitude or throttle
command applicable to an earlier point in the trajectory. Suddenly the
LM might maneuver to the wrong attitude. The worst cases were when
suspended jobs that accumulated during P64 were executed after the
transition to P66.
On March 4 Allan put out a carefully written memo describing
“a collection of known manifestations of time loss.” Allan described
eight separate modes of bad behavior, starting at a TLOSS of about 8
percent. In an unusual precaution Allan signed the memo, and asked
Gerry Levine to sign as having approved it.
(Emphasis mine)
My interpretation is that for the problem to happen,
- the rendezvous radar power supply would have to be in sync
- something would have to happen that made the SERVICER jobs run long and not complete
- Whatever caused 2) would have to go away before the situation got bad enough to flush the queue
We know that on Apollo 11 1) was not the case, but I do not know if we have enough information to know if 2) happened or not.
This answer attempts to explain the part about the radar power supply being out of phase.
answered Jul 21 at 22:12
Organic MarbleOrganic Marble
72.8k4 gold badges212 silver badges312 bronze badges
$endgroup$
2
$begingroup$
@orome I think you only got the alarms if the computer actually restarted. This kind of intermediate problem where jobs were suspended, then resumed, but the computer didn't restart may have resulted in trajectory problems with no alarm - which is worrisome indeed. That's all my interpretation though.
$endgroup$
– Organic Marble
Jul 21 at 23:23
1
$begingroup$
Ah, yes, I think you're right. The alarm indicates that things are ok because there's been a restart. (Basically it's the AGS's way of saying, I'm overloaded, and am going to deal with it by taking a sec to clean up and return to high priority tasks.) The described freighting situation would only have arisen in the absence of a 1202 alarm.
$endgroup$
– orome
Jul 21 at 23:28
1
$begingroup$
The account by Eyles - see linked answer - doesn't mention drifting. He makes it sound like there was a relationship established at powerup, and only some were bad enough to cause issues. But I can't rule out what you say.
$endgroup$
– Organic Marble
Jul 22 at 15:42
1
$begingroup$
I think that's correct. It sounds like the phase relationship was established at power up (can we know for sure?), so the situation mentioned in Klumpp remark is just something that could happen and not meant to describe what was going on during the Apollo 11 landing.
$endgroup$
– orome
Jul 23 at 17:40
1
$begingroup$
I have a follow up about why the RR and AGC being out of phase cause so many interrupts in the first place.
$endgroup$
– orome
Jul 27 at 19:52
|
show 7 more comments
$begingroup$
I agree with your comment "it's not clear when or if this situation actually occurred." From reading both Klumpp's account and his colleague Don Eyles' book Sunburst and Luminary I do not think we have enough information to know if the situation could have existed on Apollo 11. I think we know it did not exist on Apollo 11, because the radar power supply was not in phase, and Klumpp says
But when the radar’s power supply was in phase, queued commands,
valid only at some remote past time, could be completed and issued in
reverse order, momentarily taking control to guide the LM off its
normal landing trajectory.
(Emphasis mine)
Here is Eyles' account of the problem from pp. 215-16 of S&L.
As 1970 dawned, with P66 Auto finished and onboard for the upcoming
mission, Allan and I found time to reconsider the problem that so
nearly ruined the Apollo 11 landing — deprivation of processor time,
which we called TLOSS-— but we went about it in different ways.
Allan kept the IBM 360 humming as he ran simulations on the Apollo 13
rope to see how it behaved under varying amounts of TLOSS. We already
knew that if the amount of TLOSS was just right, then during a period
of high activity incomplete SERVICER jobs could accumulate in the
Executive queue. The last thing the SERVICER did on each pass was send
information to the DSKY for display. Just before it did that it issued
attitude commands, and before that, throttle commands. What concerned
Allan was what would happen if a SERVICER job was cut off before the
throttle or attitude command was sent out. If enough of these
suspended jobs accumulated, a software restart would occur, as it did
on Apollo 11, and the suspended jobs would disappear. But what if the
computational burden eased before they were flushed?
What could happen, Allan found, was that the suspended jobs (Allan
dubbed them “lurkers”) could come back to life, unaware that they had
been in hibernation, and proceed to issue an attitude or throttle
command applicable to an earlier point in the trajectory. Suddenly the
LM might maneuver to the wrong attitude. The worst cases were when
suspended jobs that accumulated during P64 were executed after the
transition to P66.
On March 4 Allan put out a carefully written memo describing
“a collection of known manifestations of time loss.” Allan described
eight separate modes of bad behavior, starting at a TLOSS of about 8
percent. In an unusual precaution Allan signed the memo, and asked
Gerry Levine to sign as having approved it.
(Emphasis mine)
My interpretation is that for the problem to happen,
- the rendezvous radar power supply would have to be in sync
- something would have to happen that made the SERVICER jobs run long and not complete
- Whatever caused 2) would have to go away before the situation got bad enough to flush the queue
We know that on Apollo 11 1) was not the case, but I do not know if we have enough information to know if 2) happened or not.
This answer attempts to explain the part about the radar power supply being out of phase.
answered Jul 21 at 22:12
Organic MarbleOrganic Marble
72.8k4 gold badges212 silver badges312 bronze badges
$endgroup$
I agree with your comment "it's not clear when or if this situation actually occurred." From reading both Klumpp's account and his colleague Don Eyles' book Sunburst and Luminary I do not think we have enough information to know if the situation could have existed on Apollo 11. I think we know it did not exist on Apollo 11, because the radar power supply was not in phase, and Klumpp says
But when the radar’s power supply was in phase, queued commands,
valid only at some remote past time, could be completed and issued in
reverse order, momentarily taking control to guide the LM off its
normal landing trajectory.
(Emphasis mine)
Here is Eyles' account of the problem from pp. 215-16 of S&L.
As 1970 dawned, with P66 Auto finished and onboard for the upcoming
mission, Allan and I found time to reconsider the problem that so
nearly ruined the Apollo 11 landing — deprivation of processor time,
which we called TLOSS-— but we went about it in different ways.
Allan kept the IBM 360 humming as he ran simulations on the Apollo 13
rope to see how it behaved under varying amounts of TLOSS. We already
knew that if the amount of TLOSS was just right, then during a period
of high activity incomplete SERVICER jobs could accumulate in the
Executive queue. The last thing the SERVICER did on each pass was send
information to the DSKY for display. Just before it did that it issued
attitude commands, and before that, throttle commands. What concerned
Allan was what would happen if a SERVICER job was cut off before the
throttle or attitude command was sent out. If enough of these
suspended jobs accumulated, a software restart would occur, as it did
on Apollo 11, and the suspended jobs would disappear. But what if the
computational burden eased before they were flushed?
What could happen, Allan found, was that the suspended jobs (Allan
dubbed them “lurkers”) could come back to life, unaware that they had
been in hibernation, and proceed to issue an attitude or throttle
command applicable to an earlier point in the trajectory. Suddenly the
LM might maneuver to the wrong attitude. The worst cases were when
suspended jobs that accumulated during P64 were executed after the
transition to P66.
On March 4 Allan put out a carefully written memo describing
“a collection of known manifestations of time loss.” Allan described
eight separate modes of bad behavior, starting at a TLOSS of about 8
percent. In an unusual precaution Allan signed the memo, and asked
Gerry Levine to sign as having approved it.
(Emphasis mine)
My interpretation is that for the problem to happen,
- the rendezvous radar power supply would have to be in sync
- something would have to happen that made the SERVICER jobs run long and not complete
- Whatever caused 2) would have to go away before the situation got bad enough to flush the queue
We know that on Apollo 11 1) was not the case, but I do not know if we have enough information to know if 2) happened or not.
This answer attempts to explain the part about the radar power supply being out of phase.
answered Jul 21 at 22:12
Organic MarbleOrganic Marble
72.8k4 gold badges212 silver badges312 bronze badges
edited Jul 21 at 23:36
answered Jul 21 at 22:12
Organic MarbleOrganic Marble
72.8k4 gold badges212 silver badges312 bronze badges
answered Jul 21 at 22:12
Organic MarbleOrganic Marble
72.8k4 gold badges212 silver badges312 bronze badges
answered Jul 21 at 22:12
Organic MarbleOrganic Marble
72.8k4 gold badges212 silver badges312 bronze badges
72.8k4 gold badges212 silver badges312 bronze badges
2
$begingroup$
@orome I think you only got the alarms if the computer actually restarted. This kind of intermediate problem where jobs were suspended, then resumed, but the computer didn't restart may have resulted in trajectory problems with no alarm - which is worrisome indeed. That's all my interpretation though.
$endgroup$
– Organic Marble
Jul 21 at 23:23
1
$begingroup$
Ah, yes, I think you're right. The alarm indicates that things are ok because there's been a restart. (Basically it's the AGS's way of saying, I'm overloaded, and am going to deal with it by taking a sec to clean up and return to high priority tasks.) The described freighting situation would only have arisen in the absence of a 1202 alarm.
$endgroup$
– orome
Jul 21 at 23:28
1
$begingroup$
The account by Eyles - see linked answer - doesn't mention drifting. He makes it sound like there was a relationship established at powerup, and only some were bad enough to cause issues. But I can't rule out what you say.
$endgroup$
– Organic Marble
Jul 22 at 15:42
1
$begingroup$
I think that's correct. It sounds like the phase relationship was established at power up (can we know for sure?), so the situation mentioned in Klumpp remark is just something that could happen and not meant to describe what was going on during the Apollo 11 landing.
$endgroup$
– orome
Jul 23 at 17:40
1
$begingroup$
I have a follow up about why the RR and AGC being out of phase cause so many interrupts in the first place.
$endgroup$
– orome
Jul 27 at 19:52
|
show 7 more comments
2
$begingroup$
@orome I think you only got the alarms if the computer actually restarted. This kind of intermediate problem where jobs were suspended, then resumed, but the computer didn't restart may have resulted in trajectory problems with no alarm - which is worrisome indeed. That's all my interpretation though.
$endgroup$
– Organic Marble
Jul 21 at 23:23
1
$begingroup$
Ah, yes, I think you're right. The alarm indicates that things are ok because there's been a restart. (Basically it's the AGS's way of saying, I'm overloaded, and am going to deal with it by taking a sec to clean up and return to high priority tasks.) The described freighting situation would only have arisen in the absence of a 1202 alarm.
$endgroup$
– orome
Jul 21 at 23:28
1
$begingroup$
The account by Eyles - see linked answer - doesn't mention drifting. He makes it sound like there was a relationship established at powerup, and only some were bad enough to cause issues. But I can't rule out what you say.
$endgroup$
– Organic Marble
Jul 22 at 15:42
1
$begingroup$
I think that's correct. It sounds like the phase relationship was established at power up (can we know for sure?), so the situation mentioned in Klumpp remark is just something that could happen and not meant to describe what was going on during the Apollo 11 landing.
$endgroup$
– orome
Jul 23 at 17:40
1
$begingroup$
I have a follow up about why the RR and AGC being out of phase cause so many interrupts in the first place.
$endgroup$
– orome
Jul 27 at 19:52
2
2
$begingroup$
@orome I think you only got the alarms if the computer actually restarted. This kind of intermediate problem where jobs were suspended, then resumed, but the computer didn't restart may have resulted in trajectory problems with no alarm - which is worrisome indeed. That's all my interpretation though.
$endgroup$
– Organic Marble
Jul 21 at 23:23
$begingroup$
@orome I think you only got the alarms if the computer actually restarted. This kind of intermediate problem where jobs were suspended, then resumed, but the computer didn't restart may have resulted in trajectory problems with no alarm - which is worrisome indeed. That's all my interpretation though.
$endgroup$
– Organic Marble
Jul 21 at 23:23
1
1
$begingroup$
Ah, yes, I think you're right. The alarm indicates that things are ok because there's been a restart. (Basically it's the AGS's way of saying, I'm overloaded, and am going to deal with it by taking a sec to clean up and return to high priority tasks.) The described freighting situation would only have arisen in the absence of a 1202 alarm.
$endgroup$
– orome
Jul 21 at 23:28
$begingroup$
Ah, yes, I think you're right. The alarm indicates that things are ok because there's been a restart. (Basically it's the AGS's way of saying, I'm overloaded, and am going to deal with it by taking a sec to clean up and return to high priority tasks.) The described freighting situation would only have arisen in the absence of a 1202 alarm.
$endgroup$
– orome
Jul 21 at 23:28
1
1
$begingroup$
The account by Eyles - see linked answer - doesn't mention drifting. He makes it sound like there was a relationship established at powerup, and only some were bad enough to cause issues. But I can't rule out what you say.
$endgroup$
– Organic Marble
Jul 22 at 15:42
$begingroup$
The account by Eyles - see linked answer - doesn't mention drifting. He makes it sound like there was a relationship established at powerup, and only some were bad enough to cause issues. But I can't rule out what you say.
$endgroup$
– Organic Marble
Jul 22 at 15:42
1
1
$begingroup$
I think that's correct. It sounds like the phase relationship was established at power up (can we know for sure?), so the situation mentioned in Klumpp remark is just something that could happen and not meant to describe what was going on during the Apollo 11 landing.
$endgroup$
– orome
Jul 23 at 17:40
$begingroup$
I think that's correct. It sounds like the phase relationship was established at power up (can we know for sure?), so the situation mentioned in Klumpp remark is just something that could happen and not meant to describe what was going on during the Apollo 11 landing.
$endgroup$
– orome
Jul 23 at 17:40
1
1
$begingroup$
I have a follow up about why the RR and AGC being out of phase cause so many interrupts in the first place.
$endgroup$
– orome
Jul 27 at 19:52
$begingroup$
I have a follow up about why the RR and AGC being out of phase cause so many interrupts in the first place.
$endgroup$
– orome
Jul 27 at 19:52
|
show 7 more comments
$begingroup$
The lunar module had two computers. The 1202 alarm happened on the Lunar Guidance Computer, which did many different tasks -- in fact, the 1202 alarm was a warning that its multitasking system was at risk of being (but not yet completely) overloaded.
There also was the Abort Guidance System. Its computer and software were completely different designs than the LGC, developed by different contractors. The AGS had only one job: get the LM back into space, where it could be picked up by the CSM. It couldn't be overloaded by the extra tasks that the LGC had to do. Although the AGS never had to be used on an actual mission, it was thoroughly tested, and there's no reason to think it would malfunction.
Apollo crews practiced recognizing when an abort was needed, and activating the AGS. The ArsTechnica article you cite even states as much:
And, to be clear, an abort during landing was not a minor thing. The procedure would have involved Armstrong pressing the "ABORT STAGE" button on the LM’s panel, which would have fired explosive bolts and guillotines and separated the LM’s ascent stage from its descent stage. Then, the ascent engine would fire, doing its best to add velocity back to the descending ship, attempting to push it back into some kind of stable orbit so that the crew could find and rendezvous with the Command Module. It was something the crews trained to do — but it wouldn’t have been easy. And it would have carried with it the stigma of an aborted mission.
The 1202 issue did not interfere with the control of the spacecraft, and that's why the crew was given the go-ahead to land. However, had it actually somehow interfered with control of the spacecraft, Armstrong's training was to immediately activate the AGS. So no disaster would have happened, but the opportunity to land on the moon would be lost.
answered Jul 21 at 21:36
DrSheldonDrSheldon
12.7k4 gold badges48 silver badges112 bronze badges
$endgroup$
$begingroup$
Sorry that's not the question: the question hinges on the relationship between "queued commands, valid only at some remote past time, could be completed and issued in reverse order" could happen, and what that has to do with the situation that occurred (when the 1202 happened).
$endgroup$
– orome
Jul 21 at 21:45
$begingroup$
It's not data that gets queued, it's tasks (much like Unix process threads). The Executive program decides which task runs next based on priority. During a soft reboot, the task queues are cleared out; they don't get corrupted or reversed. It's not going to issue steering commands in reverse order.
$endgroup$
– DrSheldon
Jul 21 at 22:07
1
$begingroup$
According to Eyles' book, the tasks get restarted, and that's what causes the issuance of the bad commands. The case happens when the tasks are paused but the system recovers before a reboot.
$endgroup$
– Organic Marble
Jul 21 at 22:17
2
$begingroup$
Ghaa. Simulators didn't have real AGCs? 😳
$endgroup$
– Russell Borogove
Jul 21 at 22:29
1
$begingroup$
@RussellBorogove no, they were too expensive and getting current 'ropes' was an issue. They were emulated in simulation software. The Shuttle training simulators had real flight computers, but I think that was an innovation. The B-52 bomber simulators I worked on also had emulated flight computers. The ISS training simulators have emulated onboard computers too.
$endgroup$
– Organic Marble
Jul 21 at 22:32
|
show 2 more comments
$begingroup$
The lunar module had two computers. The 1202 alarm happened on the Lunar Guidance Computer, which did many different tasks -- in fact, the 1202 alarm was a warning that its multitasking system was at risk of being (but not yet completely) overloaded.
There also was the Abort Guidance System. Its computer and software were completely different designs than the LGC, developed by different contractors. The AGS had only one job: get the LM back into space, where it could be picked up by the CSM. It couldn't be overloaded by the extra tasks that the LGC had to do. Although the AGS never had to be used on an actual mission, it was thoroughly tested, and there's no reason to think it would malfunction.
Apollo crews practiced recognizing when an abort was needed, and activating the AGS. The ArsTechnica article you cite even states as much:
And, to be clear, an abort during landing was not a minor thing. The procedure would have involved Armstrong pressing the "ABORT STAGE" button on the LM’s panel, which would have fired explosive bolts and guillotines and separated the LM’s ascent stage from its descent stage. Then, the ascent engine would fire, doing its best to add velocity back to the descending ship, attempting to push it back into some kind of stable orbit so that the crew could find and rendezvous with the Command Module. It was something the crews trained to do — but it wouldn’t have been easy. And it would have carried with it the stigma of an aborted mission.
The 1202 issue did not interfere with the control of the spacecraft, and that's why the crew was given the go-ahead to land. However, had it actually somehow interfered with control of the spacecraft, Armstrong's training was to immediately activate the AGS. So no disaster would have happened, but the opportunity to land on the moon would be lost.
answered Jul 21 at 21:36
DrSheldonDrSheldon
12.7k4 gold badges48 silver badges112 bronze badges
$endgroup$
$begingroup$
Sorry that's not the question: the question hinges on the relationship between "queued commands, valid only at some remote past time, could be completed and issued in reverse order" could happen, and what that has to do with the situation that occurred (when the 1202 happened).
$endgroup$
– orome
Jul 21 at 21:45
$begingroup$
It's not data that gets queued, it's tasks (much like Unix process threads). The Executive program decides which task runs next based on priority. During a soft reboot, the task queues are cleared out; they don't get corrupted or reversed. It's not going to issue steering commands in reverse order.
$endgroup$
– DrSheldon
Jul 21 at 22:07
1
$begingroup$
According to Eyles' book, the tasks get restarted, and that's what causes the issuance of the bad commands. The case happens when the tasks are paused but the system recovers before a reboot.
$endgroup$
– Organic Marble
Jul 21 at 22:17
2
$begingroup$
Ghaa. Simulators didn't have real AGCs? 😳
$endgroup$
– Russell Borogove
Jul 21 at 22:29
1
$begingroup$
@RussellBorogove no, they were too expensive and getting current 'ropes' was an issue. They were emulated in simulation software. The Shuttle training simulators had real flight computers, but I think that was an innovation. The B-52 bomber simulators I worked on also had emulated flight computers. The ISS training simulators have emulated onboard computers too.
$endgroup$
– Organic Marble
Jul 21 at 22:32
|
show 2 more comments
$begingroup$
The lunar module had two computers. The 1202 alarm happened on the Lunar Guidance Computer, which did many different tasks -- in fact, the 1202 alarm was a warning that its multitasking system was at risk of being (but not yet completely) overloaded.
There also was the Abort Guidance System. Its computer and software were completely different designs than the LGC, developed by different contractors. The AGS had only one job: get the LM back into space, where it could be picked up by the CSM. It couldn't be overloaded by the extra tasks that the LGC had to do. Although the AGS never had to be used on an actual mission, it was thoroughly tested, and there's no reason to think it would malfunction.
Apollo crews practiced recognizing when an abort was needed, and activating the AGS. The ArsTechnica article you cite even states as much:
And, to be clear, an abort during landing was not a minor thing. The procedure would have involved Armstrong pressing the "ABORT STAGE" button on the LM’s panel, which would have fired explosive bolts and guillotines and separated the LM’s ascent stage from its descent stage. Then, the ascent engine would fire, doing its best to add velocity back to the descending ship, attempting to push it back into some kind of stable orbit so that the crew could find and rendezvous with the Command Module. It was something the crews trained to do — but it wouldn’t have been easy. And it would have carried with it the stigma of an aborted mission.
The 1202 issue did not interfere with the control of the spacecraft, and that's why the crew was given the go-ahead to land. However, had it actually somehow interfered with control of the spacecraft, Armstrong's training was to immediately activate the AGS. So no disaster would have happened, but the opportunity to land on the moon would be lost.
answered Jul 21 at 21:36
DrSheldonDrSheldon
12.7k4 gold badges48 silver badges112 bronze badges
$endgroup$
The lunar module had two computers. The 1202 alarm happened on the Lunar Guidance Computer, which did many different tasks -- in fact, the 1202 alarm was a warning that its multitasking system was at risk of being (but not yet completely) overloaded.
There also was the Abort Guidance System. Its computer and software were completely different designs than the LGC, developed by different contractors. The AGS had only one job: get the LM back into space, where it could be picked up by the CSM. It couldn't be overloaded by the extra tasks that the LGC had to do. Although the AGS never had to be used on an actual mission, it was thoroughly tested, and there's no reason to think it would malfunction.
Apollo crews practiced recognizing when an abort was needed, and activating the AGS. The ArsTechnica article you cite even states as much:
And, to be clear, an abort during landing was not a minor thing. The procedure would have involved Armstrong pressing the "ABORT STAGE" button on the LM’s panel, which would have fired explosive bolts and guillotines and separated the LM’s ascent stage from its descent stage. Then, the ascent engine would fire, doing its best to add velocity back to the descending ship, attempting to push it back into some kind of stable orbit so that the crew could find and rendezvous with the Command Module. It was something the crews trained to do — but it wouldn’t have been easy. And it would have carried with it the stigma of an aborted mission.
The 1202 issue did not interfere with the control of the spacecraft, and that's why the crew was given the go-ahead to land. However, had it actually somehow interfered with control of the spacecraft, Armstrong's training was to immediately activate the AGS. So no disaster would have happened, but the opportunity to land on the moon would be lost.
answered Jul 21 at 21:36
DrSheldonDrSheldon
12.7k4 gold badges48 silver badges112 bronze badges
answered Jul 21 at 21:36
DrSheldonDrSheldon
12.7k4 gold badges48 silver badges112 bronze badges
answered Jul 21 at 21:36
DrSheldonDrSheldon
12.7k4 gold badges48 silver badges112 bronze badges
answered Jul 21 at 21:36
DrSheldonDrSheldon
12.7k4 gold badges48 silver badges112 bronze badges
12.7k4 gold badges48 silver badges112 bronze badges
$begingroup$
Sorry that's not the question: the question hinges on the relationship between "queued commands, valid only at some remote past time, could be completed and issued in reverse order" could happen, and what that has to do with the situation that occurred (when the 1202 happened).
$endgroup$
– orome
Jul 21 at 21:45
$begingroup$
It's not data that gets queued, it's tasks (much like Unix process threads). The Executive program decides which task runs next based on priority. During a soft reboot, the task queues are cleared out; they don't get corrupted or reversed. It's not going to issue steering commands in reverse order.
$endgroup$
– DrSheldon
Jul 21 at 22:07
1
$begingroup$
According to Eyles' book, the tasks get restarted, and that's what causes the issuance of the bad commands. The case happens when the tasks are paused but the system recovers before a reboot.
$endgroup$
– Organic Marble
Jul 21 at 22:17
2
$begingroup$
Ghaa. Simulators didn't have real AGCs? 😳
$endgroup$
– Russell Borogove
Jul 21 at 22:29
1
$begingroup$
@RussellBorogove no, they were too expensive and getting current 'ropes' was an issue. They were emulated in simulation software. The Shuttle training simulators had real flight computers, but I think that was an innovation. The B-52 bomber simulators I worked on also had emulated flight computers. The ISS training simulators have emulated onboard computers too.
$endgroup$
– Organic Marble
Jul 21 at 22:32
|
show 2 more comments
$begingroup$
Sorry that's not the question: the question hinges on the relationship between "queued commands, valid only at some remote past time, could be completed and issued in reverse order" could happen, and what that has to do with the situation that occurred (when the 1202 happened).
$endgroup$
– orome
Jul 21 at 21:45
$begingroup$
It's not data that gets queued, it's tasks (much like Unix process threads). The Executive program decides which task runs next based on priority. During a soft reboot, the task queues are cleared out; they don't get corrupted or reversed. It's not going to issue steering commands in reverse order.
$endgroup$
– DrSheldon
Jul 21 at 22:07
1
$begingroup$
According to Eyles' book, the tasks get restarted, and that's what causes the issuance of the bad commands. The case happens when the tasks are paused but the system recovers before a reboot.
$endgroup$
– Organic Marble
Jul 21 at 22:17
2
$begingroup$
Ghaa. Simulators didn't have real AGCs? 😳
$endgroup$
– Russell Borogove
Jul 21 at 22:29
1
$begingroup$
@RussellBorogove no, they were too expensive and getting current 'ropes' was an issue. They were emulated in simulation software. The Shuttle training simulators had real flight computers, but I think that was an innovation. The B-52 bomber simulators I worked on also had emulated flight computers. The ISS training simulators have emulated onboard computers too.
$endgroup$
– Organic Marble
Jul 21 at 22:32
$begingroup$
Sorry that's not the question: the question hinges on the relationship between "queued commands, valid only at some remote past time, could be completed and issued in reverse order" could happen, and what that has to do with the situation that occurred (when the 1202 happened).
$endgroup$
– orome
Jul 21 at 21:45
$begingroup$
Sorry that's not the question: the question hinges on the relationship between "queued commands, valid only at some remote past time, could be completed and issued in reverse order" could happen, and what that has to do with the situation that occurred (when the 1202 happened).
$endgroup$
– orome
Jul 21 at 21:45
$begingroup$
It's not data that gets queued, it's tasks (much like Unix process threads). The Executive program decides which task runs next based on priority. During a soft reboot, the task queues are cleared out; they don't get corrupted or reversed. It's not going to issue steering commands in reverse order.
$endgroup$
– DrSheldon
Jul 21 at 22:07
$begingroup$
It's not data that gets queued, it's tasks (much like Unix process threads). The Executive program decides which task runs next based on priority. During a soft reboot, the task queues are cleared out; they don't get corrupted or reversed. It's not going to issue steering commands in reverse order.
$endgroup$
– DrSheldon
Jul 21 at 22:07
1
1
$begingroup$
According to Eyles' book, the tasks get restarted, and that's what causes the issuance of the bad commands. The case happens when the tasks are paused but the system recovers before a reboot.
$endgroup$
– Organic Marble
Jul 21 at 22:17
$begingroup$
According to Eyles' book, the tasks get restarted, and that's what causes the issuance of the bad commands. The case happens when the tasks are paused but the system recovers before a reboot.
$endgroup$
– Organic Marble
Jul 21 at 22:17
2
2
$begingroup$
Ghaa. Simulators didn't have real AGCs? 😳
$endgroup$
– Russell Borogove
Jul 21 at 22:29
$begingroup$
Ghaa. Simulators didn't have real AGCs? 😳
$endgroup$
– Russell Borogove
Jul 21 at 22:29
1
1
$begingroup$
@RussellBorogove no, they were too expensive and getting current 'ropes' was an issue. They were emulated in simulation software. The Shuttle training simulators had real flight computers, but I think that was an innovation. The B-52 bomber simulators I worked on also had emulated flight computers. The ISS training simulators have emulated onboard computers too.
$endgroup$
– Organic Marble
Jul 21 at 22:32
$begingroup$
@RussellBorogove no, they were too expensive and getting current 'ropes' was an issue. They were emulated in simulation software. The Shuttle training simulators had real flight computers, but I think that was an innovation. The B-52 bomber simulators I worked on also had emulated flight computers. The ISS training simulators have emulated onboard computers too.
$endgroup$
– Organic Marble
Jul 21 at 22:32
|
show 2 more comments
Thanks for contributing an answer to Space Exploration Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fspace.stackexchange.com%2fquestions%2f37549%2fdid-the-1202-error-and-associated-reboot-prevent-disaster-on-apollo-11-landing%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
A recent article in WIRED wired.com/story/apollo-11-mission-out-of-control has some interesting background on the queue, etc.
$endgroup$
– Mark Stewart
Jul 24 at 18:37