Timeline for How did restarts resolve parity errors triggered by broken core-rope wires?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 3, 2019 at 16:06 | comment | added | supercat | @DrSheldon: Having a small patch area would not only allow for diagnosis/workarounds for computer problems, but also for other problems. For example, there was one mission where a faulty sensor could have wreaked major havoc if it had tripped at the wrong moment, but by chance it was possible to jinx things to work by switching modes at the right time; the time window was long enough to make that practical by hand. Having a couple dozen words of storage for a patch could have increased the range of fixes that could have been employed to include those that would require well-timed actions. | |
| Aug 2, 2019 at 4:57 | comment | added | DrSheldon | @supercat: It would be theoretically possible. However, the memory space was almost entirely filled, and there was a campaign late in the development to condense the code. Code needed for flight was a high priority, and diagnostic routines were not a priority. | |
| Aug 1, 2019 at 16:22 | comment | added | supercat | Would there have been any particular difficulty with having certain parts of the code check whether a certain word holds a particular "magic value" and--if so--branching to a small otherwise-unused section of RAM? That would create some failure modes, but would seem like it would increase the range of problems that could be fixed "on the fly". | |
| Aug 1, 2019 at 15:52 | history | edited | DrSheldon | CC BY-SA 4.0 |
explain that attempts to repair are pointless
|
| Aug 1, 2019 at 15:27 | comment | added | orome | Could you ad something to the effect that "Damage to the fixed memory would be permanent, and although the AGC was in the cabin, attempting to repair it would likely cause more damage" to the answer? | |
| Aug 1, 2019 at 15:24 | comment | added | DrSheldon | Patching the code was not an option. The fixed memory was physically permanent. Even if you could write code to the erasable memory, there was no mechanism to execute code at an arbitrary address. There was no power-on-self-test, because you need to be able to reboot the computer and try something else, without the computer getting in the way of that. | |
| Aug 1, 2019 at 15:17 | comment | added | DrSheldon | I have a paper on transient errors of the AGC, which I did not quote because the question was on broken core-rope. It and other sources indicate that parity errors were expected to be either mis-reads of a memory location, or a flipped bit of the erasable memory. Either is temporary and recoverable. Damage to the fixed memory would be permanent, and although the AGC was in the cabin, attempting to repair it would likely cause more damage. The alternative was to use something else that does not use the affected memory. | |
| Aug 1, 2019 at 14:18 | comment | added | orome | So the answer is that the wire would (unless the problem was transient) still be broken and the memory location thus unusable. What happens next would depend on where the break was. But I don't really see a practical way to proceed. Could the crew, during a mission, locate the fault and avoid it? Can a single address be avoided, or would whole banks of memory need to be taken out pro commission? | |
| Jul 31, 2019 at 21:07 | history | answered | DrSheldon | CC BY-SA 4.0 |