26

How reliable was the ferrite ring core memory system? When the power went off, did all the magnetic positions of the iron rings in the program wire grid remain exactly as they were?

7
  • 4
    Very stable. Sometimes too much. Real world example: The University I attended had a (1970s vintage) Nuclear Magnetic Resonance machine controlled by a (24 bit) computer with core memory. Over the yearsof sitting in the same room as a superconducting magnet had "set" the core memory containing the controlling programs effectively converting it into ROM.
    – mcottle
    Sep 6, 2017 at 4:45
  • 1
    Didn't the Apollo Guidance Computer, that went to the moon, use core memory?
    – Mike
    Sep 7, 2017 at 12:21
  • 5
    Mike, yes. They also used "rope" memory sealed in brick like modules. Pre-wired programs. Sep 7, 2017 at 19:40
  • 1
    Magnetization of ferrite (as in core memory) is the geological record of Earth's magnetic field history. There's paleomagnetic data going back millennia.
    – Whit3rd
    Sep 17, 2017 at 7:03
  • @mcottle is that a scientifically well understood effect that did something odd to the cores, or actually mechanical distortion due to the huge magnet? Sep 17, 2017 at 8:54

6 Answers 6

29

Caveat: I can only tell about mainframes. Minis might have used different protection and handling schemes (and for sure smaller memory sizes). My detailed knowledge is based on memory up to the mid-1970s. Further I was working for a manufacturer of compatible mainframes. We switched already for complete semiconductor memory at a time when IBM introduced new generations of core, but I don't remember these new core modules being any better, just smaller.

How reliable was the ferrite ring core memory system?

TL;DR: one non recoverable error per 32 KiB per month.

Flipped bits happened all the time during normal operation. Rule of thumb, for mainframes using error detection and correction, was one non correctable error per 32 KiB and month at 24/7 usage. This rate was considered acceptable. Back then mainframe programs where usually batch runs and build around checkpoints.

Checkpoints are for batch programs somewhat similar to transaction commits for database applications: a production state where the batch could be resumed if interrupted. Usually an intermediate step, where all data was on some external media (like punch cards, tapes or disks) or a collection of pointers/keys/etc. was stored to find a necessary restart position within all data, like after each processed tape block. But this required usually having some random storage like disk, drum or magnetic cards. So if a non fixable error happened, a (the) batch / program was restarted from that point.

Since only very few customer machines used more than 128-256 KiB (in fact, even 'large' models couldn't even be extended past that) during the 60s and early 70s, one or two machine halt per week was considered OK. After all, compared to previous systems this was an astonishing smooth handling.

When a parity halt occurred, depending on the jobs running, operators did check where the faulty word was (location, program) and either patched it back, reload some stuff or just purged that single program and let the machine continue. No reboot or alike. Yes, being an operator back then meant that you really knew the programs running.

Service would only be called if the error rates went up.

Now with dialog applications and huge memory sizes the picture was a bit different. The most extreme example here might have been the 1972 Olympics. It included the first integrated real time online information system for the media, where all results were available at online terminals throughout the press center less than a minute after each and every competition. Several hundred acquisition stations and terminals where spread out literally all over Germany (while the main event was in Munich, some competitions like boating happened up at the north sea coast), while again hundreds of terminals where located at the main press center in Munich. So newspaper reporters could produce reports without moving their butt past the coffee maker. But that's a different story.

At the core one mainframe handled all the data acquisition and dialog load and it's been one of the largest installations worldwide, if not the largest up to that time. 32 disk drives and a whopping two megabytes RAM in single installation. The machine had to be setup in a T-shape with memory in all crossbar cabinets to keep the wire length toward the CPU (vertical bar) as short as possible, while having equal length to all cabinets (again, a different story). In theory this machine should get about two non recoverable errors per day and it worked out that way, even careful component selection couldn't reduce this much. There were more than a dozen machine halts during the 14 days of operation. It was still a quite successful operation, as, thanks to the back then brand new data base system a start up happened in less than 90 seconds - including OS boot. So failures became more of a small glitch than a real issue.

If you can't beat it, embrace it :)

(Insert: The ability to run a large scale real time information system (even for today's standards not small) on a machine with 'just' 2 MiB RAM, less than 200 MiB Disk and 400 kOps is a great example that a mainframe MIPS are incomparable to mini/microprocessor MIPS)


When the power went off, did all the magnetic positions of the iron rings in the program wire grid remain exactly as they were?

TL;DR: yes

Of course, as with all storage systems it depends on the timing. When powered off in a safe state, it did retain its content for days or even longer. When powered off during a write cycle results are rather unpredictable. At this point it's important that reads on core are destructible, so each and every read is followed by a write. Thus just switching the machine off, most likely results in some memory damaged. Highest chance here the program locations executed at that time.

Procedure for a clean power off while retaining machine state and memory was to put the CPU on hold and then power off. Hold wasn't an interrupt or alike, but literally held the CPU, so no further operation was done. There was a separate HOLD button at the operator's console. When powered on again, just press HOLD again to have it continue - or change some registers, like PC, to have it start somewhere else.

This mechanic is why some mainframe manufacturers added special machine error state (a combination of interrupt and separate register set) which was invoked at power fail. The power supply did provide sufficient power to run a few instructions after power failure was detected. More than enough time to execute a single hold instruction, followed by some code to return from interrupt or put it into any kind of recovery mode. No UPS, large scale capacitor or motor generator needed, it just stopped and continued after power off/on. Of course, this did only affect the CPU. Half written tape blocks or disk tracks where still a pile of garbage. That's where checkpoints again played a role.

Mainframes aren't a pile of single solutions as today's small machines, but a clockwork of multiple use of inherent hardware features.

7
  • "mainframe MIPS are incomparable to mini/microprocessor MIPS" I'm not sure I'd draw the conclusion that far. It's definitely a sign of making the very most out of what resources one has available as a programmer, I'll certainly grant you that. If people wrote software the same way today as they did back then, or even the way they did back in the early minicomputer era, computers would get a lot more processing done -- but also be a whole lot more difficult to use, let alone program.
    – user
    Oct 8, 2018 at 18:02
  • @MichaelKjörling You're missing the point. This is not about how programing is done, but what a single instruction acomplishes. A /370 is a CISC machine, thus needing way less instructions to perform the same task as a micro. Just take moving astring or comparing a key. on a /370 it's a single instruction, while micros use loops to handle this. Comparing an 8 byte key is one /370 instruction, but maybe 16 or more on a micro. Thus just comparing MIPS to compare relative performance is meaningless. One can simply not do the same task in the same amount of instructions on a mini.
    – Raffzahn
    Oct 8, 2018 at 18:15
  • ( @MichaelKjörling And before extending this, Comments are to improve answers, not to argue - if you want to argue, open a chat, and I'm all with you)
    – Raffzahn
    Oct 8, 2018 at 18:16
  • 2
    @Raffzahn the usual phrasing in English is "per 32KiB per month" to express that the rate scales with both (or in a scientific context, perhaps "per 32KiB ⋅ month").
    – hobbs
    Oct 9, 2018 at 19:15
  • @Raffzahn - Except for a couple of instructions - e.g. TRT - a 360/370 is a RISC ISA. Doesn't even have addressing modes or operations for a stack. It does have concurrent sophisticated I/O processors ("channels") - but those are also RISC. But those couple of non-RISC instructions are powerful. (It does have multiple instruction formats which is not generally considered RISC - but they are easy to decode (unlike, say, x86 or VAX)). Your numbers on core memory error frequency are very interesting; I naively thought they were more stable than they apparently were.
    – davidbak
    Jun 11, 2020 at 20:05
12

The ferrite core memory system is quite reliable. When I was working on medical systems, we used pre-programmed systems in core memory. One day, we got a call from the factory in the US, saying that their shop floor computer had crashed and they could not restart it. We put an extra core memory into our system in UK, copied it and then sent it to the factory in the US by special delivery. They plugged it in, switched on and their system came to life straight away.

We used to keep different pre-programmed boards. Sometimes, they were sitting on the shelf for 6 months but when they were plugged in, the systems always worked.

6

At University I did a course on PDP-11 assembler because, as the lecturer put it "the PDP-11 will be around forever". The course was split over two terms with the summer holiday in between and when we all came back, the University had thrown away all its PDP-11's and bought a load of Sun work stations.

Anyway, the first task of any PDP-11 assembler language program was to loop through the whole of main memory and zero every unused location because the PDP-11 used core memory (at least, the older ones did) and core memory retains its contents when the power goes off.

2
  • 3
    as the lecturer put it "the PDP-11 will be around forever" -- he's not far wrong. Here I am, 40+ years later, with two operating systems on my machines, both of which can reasonably be described as direct descendants of systems written for the PDP-11.
    – Jules
    Sep 5, 2017 at 16:55
  • 1
    @Jules: One of the primary languages used for programming embedded microcomputers is designed for programming machines that use the same abstraction model as the PDP-11. While changes in silicon technology mean that model is no longer workable, it irks me that people want to weaken the language that was designed for such machines (and is still excellent for the 99%+ of microcontrollers that use that abstraction) rather than use newer languages that better fit the newer machines' abstraction models.
    – supercat
    Oct 8, 2018 at 15:57
4

The core memory is generally non-volatile (doesn't lose it contents while being powered off), which is attributed to the property of ferromagnetic materials: spontaneous magnetisation. Every small crystal of such material has its own magnetisation all the time -- generally with random direction. When enough external magnetic field is applied to the whole core, the majority of those small crystals change their magnetic moments according to the field. When the field is then de-applied, it becomes energetically unprofitable for every small crystal to change its magnetisation against the collective field made by all other previously oriented pieces of material, that now create their own magnetic field. Therefore the collective magnetisation keeps.

Returning to the core memory, we conclude that it is generally non-volatile. However, special provisions must be made to suppress transients happenning during power-on and power-off cycling, that otherwise can disturb the magnetisation of the cores.

3

A major complication with core memory is that while it can retain its contents for a long time without being accessed, it can't be read even once without being erased. The process of reading a core requires writing a known value to the bit to be read while watching a sense wire to see if a pulse is received. If a pulse was received on the sense wire, that means the act of trying to write to the bit caused its value to change (if no pulse is received, that means the bit already held the value being written). If core was being treated as non-volatile RAM, whose content would be considered meaningless when the machine was power-cycled or reset, this wouldn't be a problem. It meant, however, that if there was an area of memory that was supposed to hold its contents through such events, it would be necessary to ensure that operations that were supposed to read a storage location and write back its contents must not be interrupted under any circumstances. While many flash or EEPROM chips include a "write-protect" signal and may be safely powered on and off at any time while they are write-protected, such an approach won't work with core memory. The only way to read it is to force the cores to a known state and sense whether this causes a change in the magnetic field. Unless that change is properly recorded, the information that had been stored in the cores will be lost.

1

As long as you didn't turn the power back on, the content of memory was quite stable. It was the power-on glitches that got you.

Certainly I've used small systems (Elliot 903 for example) where you could power it down, and power it up the next day with a compiler still loaded and ready to go.

I used to work on network software on PDP-11, where when you got a powerfail interrupt, you have a few milliseconds to store volatile processor and device context, so you could carry on running when the power came back. The way I remember it, this was a hit-or-miss affair. Maybe our development lab was electrically noisy or something.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .