Core Memory Stability

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

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

Answer 5

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.

Answer 6

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.