> ## Content Index
> Fetch the complete content index at: https://huizhou92.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How Seymour Cray's CDC 6600 Outran IBM
- URL: https://huizhou92.com/seymour-cray-cdc6600-supercomputer-en/
- Published: 2026-11-14T11:56:35.000Z
- Updated: 2026-11-14T11:56:35.000Z
- Description: The CDC 6600 gained speed through short signal paths, peripheral processors, and a hardware scoreboard, while its operating system lagged behind.
- Author: huizhou92
- Tags: #lang-en, Technology, Computing, Software Engineering, Computer History, Supercomputing

*Conceptual illustration of the CDC 6600's compact hardware layout. AI-generated illustration.*

### Watson's memo

On August 28, 1963, IBM chairman and chief executive Thomas J. Watson Jr. signed an [internal memo](https://www.computerhistory.org/revolution/supercomputers/10/33/62?ref=huizhou92.com).

CDC had just announced the 6600\. By Watson's account, the development laboratory had only 34 people, including a janitor: 14 engineers and four programmers. Against the scale of IBM's research effort, he could not understand how CDC had announced what he called the world's most powerful computer first. He wanted the question of where IBM had gone wrong, and what it should change at once, at the top of the agenda for the Jenny Lake meeting.

IBM had recently suffered a setback of its own. Two years earlier, its 7030 supercomputer, known as *Stretch*, had fallen short of its performance target. IBM had set out to make it at least 100 times faster than the earlier 704\. By 1961, measurements put it at roughly 30 to 40 times the 704's speed.

In May 1961, IBM removed Stretch from future sales. According to [IBM's history of the machine](https://www.ibm.com/history/stretch?ref=huizhou92.com), its price fell from $13.5 million to about $7.8 million, below cost. Only nine systems went into service.

![IBM Model 7030 Stretch console](https://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/IBM_Model_7030_%22Stretch%22_console%2C_1961%2C_Computer_History_Museum.jpg/1280px-IBM_Model_7030_%22Stretch%22_console%2C_1961%2C_Computer_History_Museum.jpg)

*IBM Model 7030 Stretch console. The model was delivered in 1961; this console is held by the Computer History Museum. Photo by The wub, CC BY-SA 4.0, via* [*Wikimedia Commons*](https://commons.wikimedia.org/wiki/File:IBM%5FModel%5F7030%5F%22Stretch%22%5Fconsole,%5F1961,%5FComputer%5FHistory%5FMuseum.jpg?ref=huizhou92.com)*.*

Two years later, Minnesota-based Control Data Corporation (CDC) announced the 6600, with roughly three times Stretch's performance. The [Computer History Museum's timeline](https://www.computerhistory.org/timeline/1964/?ref=huizhou92.com) puts the 6600 at about three million instructions per second, or 3 MIPS.

Computer engineer [Gordon Bell recalled in 1989](https://gordonbell.azurewebsites.net/CGB%20Files/Fewer%20Engineers%20The%20Better%20IEEE%208902%20bw%20c.pdf?ref=huizhou92.com) how the 6600's chief designer, Seymour Cray, thought Watson had answered his own question in the memo. The size of the laboratory showed how differently the two companies had organized this particular effort.

### Ten-foot cables and a 100-nanosecond clock

IBM had the larger research organization, but CDC had the faster machine. The 6600's base clock ran at 10 MHz, giving it a 100-nanosecond cycle. At that speed, signal propagation became a design constraint.

Light travels about 30 centimeters in one nanosecond in a vacuum. On [page 31 of his book](https://archive.computerhistory.org/resources/text/CDC/cdc.6600.thornton.design%5Fof%5Fa%5Fcomputer%5Fthe%5Fcontrol%5Fdata%5F6600.1970.102630394.pdf?ref=huizhou92.com), Jim Thornton reported a propagation delay of about 1.5 nanoseconds per foot in the 6600's interchassis coaxial cable, or about 20 centimeters per nanosecond.

Within a 100-nanosecond clock period, gates had to switch, signals had to settle, and registers needed enough setup time to capture their values. A ten-foot cable between chassis, together with its driver circuitry, took about 25 nanoseconds from input to output: a quarter of the cycle.

Longer connections consumed more of that time budget. In his [account of the design](https://archive.computerhistory.org/resources/text/CDC/cdc.6600.thornton.design%5Fof%5Fa%5Fcomputer%5Fthe%5Fcontrol%5Fdata%5F6600.1970.102630394.pdf?ref=huizhou92.com), Thornton identified shorter interchassis wiring as a reason for the compact layout. Cray and hardware architect Thornton arranged the cabinets to keep those connections short.

![Seymour Cray](https://upload.wikimedia.org/wikipedia/commons/thumb/2/29/Seymour_Cray.jpg/1280px-Seymour_Cray.jpg)

*Seymour Cray, with the later Cray-1 behind him. Photo by Michael Hicks, CC BY 2.0, via* [*Wikimedia Commons*](https://commons.wikimedia.org/wiki/File:Seymour%5FCray.jpg?ref=huizhou92.com)*.*

The 6600's cabinets formed a cross, or *plus sign*. Four wings stood close to a central base, with the logic modules folded toward the center. According to the [CDC module manual](https://www.bitsavers.org/pdf/cdc/modules/60042700BB%5FCordwood%5FModules%5FA-J%5FVol%5F1%5FNov76.pdf?ref=huizhou92.com), coaxial cables between chassis were made to a uniform ten-foot length so the chassis could use synchronized timing signals.

![CDC 6600 cabinet layout](https://upload.wikimedia.org/wikipedia/commons/thumb/b/be/CDC_6600_Overview.png/1280px-CDC_6600_Overview.png)

*Rendering of the CDC 6600's cross-shaped cabinet layout, with modules folded toward the center to shorten wiring. 3D rendering by FlyAkwa, CC BY-SA 4.0, via* [*Wikimedia Commons*](https://commons.wikimedia.org/wiki/File:CDC%5F6600%5FOverview.png?ref=huizhou92.com)*.*

### Chippewa Falls and the heat problem

The 6600's hardware was not designed at CDC's Minnesota headquarters. In 1962, CDC established a laboratory near Cray's hometown of Chippewa Falls, Wisconsin, where work on the machine continued. Cray had previously worked at headquarters.

In an [oral history interview with the Smithsonian](https://americanhistory.si.edu/comphist/cray.htm?ref=huizhou92.com)Cray said the distance from headquarters reduced interruptions from customer visits and other nontechnical demands, letting him continue hands-on technical work. This was the laboratory Watson described as having 34 people: 14 engineers, four programmers, and the remaining technical and support staff.

Packing the hardware tightly created a heat problem. The 6600 used high-speed silicon transistors developed by Fairchild Semiconductor. It contained about 400,000 transistors, and its logic modules used *cordwood* construction: components packed between two circuit boards.

![CDC cordwood module](https://upload.wikimedia.org/wikipedia/commons/thumb/b/b9/CDC_cordwood_module.jpg/1280px-CDC_cordwood_module.jpg)

*CDC cordwood module. The original description identifies it only as possibly belonging to the 6000 series; the exact model is unconfirmed. Photo by Bubba73, CC BY-SA 4.0, via* [*Wikimedia Commons*](https://commons.wikimedia.org/wiki/File:CDC%5Fcordwood%5Fmodule.jpg?ref=huizhou92.com)*.*

The heat from those dense modules had to go somewhere. The team used conductive plates and a refrigeration system rather than relying on room air alone. As the [Computer History Museum describes it](https://www.computerhistory.org/revolution/story/33?ref=huizhou92.com)heat passed from the modules through metal cold plates into a Freon loop, then through a heat exchanger to external chilled water. The cooling system also had to keep equipment surfaces warm enough to avoid condensation.

### Giving I/O to the peripheral processors

The 6600 addressed another constraint by dividing the work between processors. Peripheral processors handled device I/O and some system-management tasks, leaving the central processor to concentrate on scientific computation. In his [paper on the architecture](https://people.eecs.berkeley.edu/~culler/courses/cs252-s05/papers/cdc6600.pdf?ref=huizhou92.com), Thornton identified this separation as a key design step.

The central processor had no instructions for direct device I/O and did not respond directly to device interrupts. It still executed branches, memory operations, and arithmetic instructions. A peripheral processor could initiate an *exchange jump* to switch the central processor's job state.

There were ten peripheral processing units, or PPUs. According to [Thornton's book](https://archive.computerhistory.org/resources/text/CDC/cdc.6600.thornton.design%5Fof%5Fa%5Fcomputer%5Fthe%5Fcontrol%5Fdata%5F6600.1970.102630394.pdf?ref=huizhou92.com), each had its own core memory of 4,096 12-bit words and an 18-bit accumulator. PPUs handled devices such as card readers and tape drives. An exchange jump switched the central processor's job state using a 16-word *exchange package*.

Rather than duplicate the full arithmetic and control hardware ten times, CDC used a barrel processor. The ten PPUs shared one set of arithmetic, logic, and data-distribution circuits. Every 100 nanoseconds, hardware advanced to the next PPU's register set. Each PPU received a computing slot once per microsecond.

![CDC 6600 mainframe system](https://upload.wikimedia.org/wikipedia/commons/thumb/c/c4/CDC_6600.jc.jpg/1280px-CDC_6600.jc.jpg)

*A complete CDC 6600 system, with a dual-screen console in front of the cross-shaped main cabinet. Photo by Jitze Couperus, CC BY 2.0, via* [*Wikimedia Commons*](https://commons.wikimedia.org/wiki/File:CDC%5F6600.jc.jpg?ref=huizhou92.com)*.*

The central processor used 60-bit words and instructions of either 15 or 30 bits. Its control logic was hardwired rather than microcoded. Floating-point and Boolean operations used registers as operands, while some address-increment instructions could also use constants encoded in the instruction. Writing an address to certain A registers triggered a transfer between memory and the corresponding X register, as [Thornton documented](https://archive.computerhistory.org/resources/text/CDC/cdc.6600.thornton.design%5Fof%5Fa%5Fcomputer%5Fthe%5Fcontrol%5Fdata%5F6600.1970.102630394.pdf?ref=huizhou92.com).

In its [retrospective on the 6600](https://www.cisl.ucar.edu/ncar-supercomputing-history/cdc6600?ref=huizhou92.com), the National Center for Atmospheric Research (NCAR), which used the machine, noted its 65 instructions and described it as a RISC computer before the term existed.

### Scoreboard scheduling across ten units

Thornton also designed a way for the central processor's functional units to work in parallel. Their operations took very different amounts of time. The [instruction timing in his book](https://archive.computerhistory.org/resources/text/CDC/cdc.6600.thornton.design%5Fof%5Fa%5Fcomputer%5Fthe%5Fcontrol%5Fdata%5F6600.1970.102630394.pdf?ref=huizhou92.com) gives three cycles for increment and Boolean operations, four for floating-point addition, ten for multiplication, and 29 for floating-point division.

In a strictly serial design with one arithmetic unit, a slow division would hold up later operations even if they did not depend on its result. The 6600 instead had ten independent functional units: branch, Boolean, shift, fixed-point addition, one floating-point adder, two floating-point multipliers, one floating-point divider, and two address-increment units.

Thornton coordinated them with a hardware *scoreboard*. It tracked which units were available and whether register dependencies would make an instruction unsafe to issue.

As [Thornton explains on pages 125–127](https://archive.computerhistory.org/resources/text/CDC/cdc.6600.thornton.design%5Fof%5Fa%5Fcomputer%5Fthe%5Fcontrol%5Fdata%5F6600.1970.102630394.pdf?ref=huizhou92.com), instructions issued in program order. Suppose the divider was busy with a 29-cycle operation. An unrelated shift or Boolean instruction could issue to an available unit and finish without waiting for division. If the required unit was busy, or the destination register was already reserved, issue paused.

The 6600 was among the earliest commercially deployed machines to schedule work across multiple functional units in hardware. For independent instructions, the scoreboard reduced waiting caused by slower operations. It became an early example in the history of out-of-order execution.

![CDC 6600 console](https://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/CDC_6600_console%2C_1964%2C_Computer_History_Museum.jpg/1280px-CDC_6600_console%2C_1964%2C_Computer_History_Museum.jpg)

*Detail of the CDC 6600's two round CRT console displays, now held by the Computer History Museum. Photo by The wub, CC BY-SA 4.0, via* [*Wikimedia Commons*](https://commons.wikimedia.org/wiki/File:CDC%5F6600%5Fconsole,%5F1964,%5FComputer%5FHistory%5FMuseum.jpg?ref=huizhou92.com)*.*

### A fast machine still needed an operating system

The 34 people in Watson's memo counted Cray's laboratory, not everyone needed to deliver a working computer system. According to [Thornton's paper](https://people.eecs.berkeley.edu/~culler/courses/cs252-s05/papers/cdc6600.pdf?ref=huizhou92.com), the first 6600 was delivered in October 1964\. An operating system still had to make its hardware usable for customers.

That software had more to do than load programs into the central processor. Since the PPUs handled device I/O, the operating system had to schedule jobs, allocate devices, coordinate data transfers, and switch the central processor between jobs.

A [CERN paper on the system](https://cds.cern.ch/record/275732/files/CERN-68-04.pdf?ref=huizhou92.com) gives a concrete example: when a job requested output, the supervisor had to find an available PPU for the I/O work and might use an exchange jump to let the central processor run another job. In a [1964 paper introducing SIPROS](https://ftpmirror.your.org/pub/misc/bitsavers/pdf/afips/1964-10%5F%2326%5FPart%5F2.pdf?ref=huizhou92.com), CDC engineers noted the hardware imposed few restrictions on how those processors were coordinated. Much of the system's behavior depended on the operating system.

SIPROS, the *Simultaneous Processing Operating System*, was meant to keep multiple jobs moving. It did not arrive on schedule. CERN's 6600 reached the laboratory in January 1965, and from May it provided service with a temporary system that did not support time sharing. [CERN's report for that year](https://cds.cern.ch/record/20326/files/CM-P00078005-f.pdf?ref=huizhou92.com) recorded longer job turnaround and a growing queue. The initial SIPROS version CDC later supplied was incomplete and not fully debugged.

[CERN's 1966 report](https://cds.cern.ch/record/20583/files/CM-P00078022-f.pdf?ref=huizhou92.com) describes what followed. CERN staff and local CDC support personnel reworked or completed the executive, job loader, tape handling, and I/O components before CERN's SIPROS version gradually displaced the temporary system. Early hardware reliability problems also reduced the machine time available for software development, while programmers helped diagnose failures, as [CERN had reported the previous year](https://cds.cern.ch/record/20326/files/CM-P00078005-f.pdf?ref=huizhou92.com).

[NCAR's account of its own 6600](https://www.cisl.ucar.edu/ncar-supercomputing-history/cdc6600?ref=huizhou92.com) records a similar difficulty: neither of the two systems then offered by CDC could run most of NCAR's test programs, so NCAR began developing its own operating system.

### Model 92 and the destroyed index

An [IBM model chronology included in antitrust litigation records](https://bitsavers.computerhistory.org/pdf/charlesRiverAssoc/US%5Fvs%5FIBM%5FExhibit%5F14971%5Fpart%5F2%5FJul80.pdf?ref=huizhou92.com) says IBM announced the high-end System/360 Model 92 in 1964 without a delivery date. According to a [1968 report in *Computers and Automation*](https://bitsavers.trailing-edge.com/magazines/Computers%5FAnd%5FAutomation/196801.pdf?ref=huizhou92.com), CDC chairman William Norris said some customers considering a 6600 delayed orders while they waited to learn more about IBM's proposed machine. IBM denied announcing its products unusually early.

[IBM's model chronology](https://archive.computerhistory.org/resources/access/text/2011/09/102743210-05-01-acc.pdf?ref=huizhou92.com) shows Model 92 was never delivered under that designation. The revised Model 91 was first delivered in 1967\. CDC sued IBM in 1968; a [1969 court document](https://law.justia.com/cases/federal/district-courts/FSupp/306/839/1794359/?ref=huizhou92.com) shows the early product announcement was one of several practices CDC alleged had restrained competition. The parties settled in 1973\. IBM sold its data-processing service subsidiary, Service Bureau Corporation (SBC), to CDC, an arrangement also recorded in a [U.S. Department of Justice retrospective](https://www.justice.gov/atr/case-document/file/499651/dl?ref=huizhou92.com).

The settlement affected another IBM antitrust case. A [Justice Department account of the index's destruction](https://www.justice.gov/sites/default/files/usao/legacy/2010/10/12/usab2108.pdf?ref=huizhou92.com) explains how CDC's lawyers had built an annotated, computer-searchable index of documents collected during years of discovery. The department had used it to prepare its own case. The settlement called for the destruction of litigation work product, and the index was destroyed.

In a [1973 federal court ruling](https://openjurist.org/58/frd/556/united-states-v-international-business-machines-corp?ref=huizhou92.com), IBM argued the index was attorney work product and therefore fell outside a preservation order in the other case. The court rejected that argument and found IBM had caused the index's destruction in violation of the order. The ruling concerned the preservation of evidence. It did not decide whether CDC's antitrust claims against IBM were true.

### Beyond the hardware delivery

The familiar story of a small laboratory outpacing IBM leaves out part of the engineering record. Cray and Thornton controlled signal delay with a compact layout and standard cable lengths. Freon cooling made dense packaging workable, while the scoreboard kept multiple functional units busy.

Once the hardware handed device I/O to the PPUs, customers still needed an operating system that could coordinate the whole machine. CERN's experience shows how much work remained between installing the hardware and delivering a stable, usable system.

The 6600's achievement depended on engineers working within physical limits. Its delivery also exposed the software work required to turn a fast processor into a functioning computer system.