by Katie Hafner
One interesting advantage of core memory is its nonvolatile nature. If you turned the machine off in the middle of working on something, it wouldn’t lose its place; it would pick right back up again where it had left off. Heart’s team had also designed an automatic restart feature: If the power failed, the machine was supposed to come to a clean stop and then restart automatically when power returned. With the core memory, the machine would restart at the beginning of the program as soon as power was restored. The only time a program had to be reloaded was when a new release was issued or when some hardware or software glitch caused the memory to be over-written. In these cases, the IMP program would be reloaded from a paper tape reader, a kludgy electromechanical device which shone light from an incandescent bulb through a paper tape that was pulled across a line of photocells. The IMP had other self-sufficiency measures, one of which was called a “watchdog” timer. “If the program went wild,” Heart explained, a small timer in the machine would run down to zero (but a healthy program would continually reset it). If the timer reached zero and went off, the IMP was assumed to have a trashed program. It would then throw a relay to turn on the paper tape reader, give it a while to warm up, and then reload the program. BBN would ship each machine with a copy of a tape that had three copies of the entire IMP operating program in sequence, giving each IMP the chance to do three auto-reloads before someone had to go and rewind the tape. Later, an even more ingenious scheme would be invented by BBN to reload crashed IMPs from the nearest neighbor IMPs, and start fresh. These were all unusual features at the time.
The IMP Guys set to work on writing the code, and by the time they finished, it would turn out to be about six thousand words. “A tiny program,” said Heart. They did all their programming in Honeywell 516 “assembly” language.
Computers are instruction-following mechanisms. Assembly-language programming requires thinking through a vast number of minute steps, then writing the instructions to carry them out. For instance, let’s say you want to find the elevator. An equivalent set of instructions in a high-level language might go something like this: “Go out the door, turn right, go past the water fountain, and it’s on your left.”
The equivalent in assembly language would begin more like this: “Find your left foot; find your right foot. Place your left foot in front of your right foot. Now place your right foot in front of your left foot. Repeat this ten times. Stop. Turn ninety degrees to the right.” Etcetera.
To program in assembly language was to dwell maniacally on the mechanism. It was easy for programmers to lose sight of the larger goal and difficult to write short, economical programs. Unskilled programmers often ended up writing assembly-language programs that wandered aimlessly, like some hapless Arctic expedition in a blizzard.
Crowther managed to keep the detailed steps of assembly-language programming straight in his head without getting lost. But he was forever drawing big flowcharts so he could picture everything at once. One colleague likened the process to designing a whole city while keeping track of the wiring to each lamp and the plumbing to every toilet. Sometimes, though, Crowther eschewed the flow diagrams and did them in his head. Where others struggled to apply the rudimentary programming tools of the time, Crowther was out there operating on a higher plane.
Writing the IMP software began in the offices of the programming team members, where each would type code on a Model 33 Teletype into a PDP-1 “editor.” After the code was created on the PDP-1, it was transferred on paper tape to the Honeywell computer, where it was converted into the Honeywell’s machine language, a chore handled by a program known as an assembler, which converted the code into the 1s and 0s the 516 could understand. The assembled code was then punched onto paper tape. For a while the programmers tried using the assembler that came with the Honeywell 516, but it was so inefficient they soon abandoned it: Walden and Cosell spent fourteen hours one weekend on an assembly of the IMP system code, using almost an entire box, nearly half a mile, of tape.
Not long after that, Cosell wrote some code to modify the much better assembler on BBN’s time-shared PDP-1 computer down the hall. This made it possible for the PDP-1 to produce machine-language tapes for the Honeywell 516. From then on the team wrote pieces of IMP code, edited them, and assembled them under the PDP-1 time-sharing system. Once he was satisfied with an assembly process, the programmer would instruct the PDP-1 to punch out the assembled code on a paper tape, then carry the tape back to the lab where the 516 sat. He would load the tape into the 516, run it, and wait to see what happened. Usually there would be some bugs, and so the process would be repeated. Naturally, when one of the programmers saw something interesting or quirky happening as a new piece of code ran on the 516, the team members would gravitate to the event and stand around the Honeywell talking it over.
Most of the IMP Guys lived close to Cambridge, and it was easy for them to check in and out of the lab at any hour. Chef Joyce Chen’s original Chinese restaurant was next door to BBN, and that helped when they worked late, as they often did. Cosell and Walden drank a lot of Coke to keep themselves going; Crowther never touched the stuff. He was a notoriously finicky eater (anything beyond the culinary level of a plain bologna sandwich was a risk), making him an impossible dinner guest or dining companion.
Early in the project, BBN was asked to brief a group of high-level ARPA and military personnel at the Pentagon. Crowther was among those planning to make the trip on behalf of the IMP Guys. Heart grew nervous just thinking about what Crowther might wear to the briefing. People were sure to notice his feet, thought Heart. The only time that anyone could remember Crowther wearing shoes you could shine was the day he got married. Heart went to Ornstein and asked him to tell Crowther not to wear sneakers to the Pentagon. Ornstein did.
“Willy, Frank says you shouldn’t wear your sneakers to this meeting.” There was a long silence at the other end of the line. And then Crowther’s calm voice. “Tell Frank they’ve seen my sneakers in JSAC [Joint Services Advisory Committee] meetings before and it’ll be okay.” It was.
Crowther and Ornstein were among Heart’s most devoted staffers. But they loved to kid the boss when the chance arose. “Frank took things very, very seriously,” Ornstein observed.
Ornstein was an outspoken opponent of the Vietnam War. By 1969 a lot of people who had never questioned their own involvement in Pentagon-sponsored research projects began having second thoughts. Ornstein had taken to wearing a lapel pin that saidRESIST. The pin also bore the ? sign, for electrical resistance, a popular antiwar symbol for electrical engineers. One day, before a Pentagon briefing, Ornstein conceived a new use for his pin. In meetings at the Pentagon, it wasn’t unusual for the men around the table to remove their jackets and roll up their shirt sleeves. Ornstein told Heart that he was going to pin hisRESISTbutton onto a general’s jacket when no one was looking. “I think Frank actually worried that I would,” said Ornstein. (Ornstein didn’t, but he did wear his pin to the meeting.)
As the IMP Guys laid out their plans in Washington, it became apparent that the ARPA network would be a hybrid of the original ideas of Baran and Davies. The ARPA network would use an adaptive routing scheme that the IMP Guys had developed on their own, but which was similar to the basic idea that Baran had sketched. However, unlike Baran’s theoretical network, the ARPA network would not have nearly the same redundancy level or number of links to each node. Nodes in the BBN scheme were normally linked to two neighboring nodes, occasionally to one or three. As it was now conceived, just two failed links could divide, or partition, the network into isolated segments. Paul Baran had said that a network with a multitude of redundant links could be built of inexpensive parts; if a part malfunctioned, there would be others to back it up. The low level of redundancy in the ARPA network was closer to Davies’ plan. Heart’s approach was to make every part of the network as robust and reliable as possible.
During the proposal period, Crowther and Walden had already done some very crucial work,
with amazing results. First, they had found a way to make adaptive routing work efficiently. They had also discovered that they could make the system run much faster than anyone imagined. Observers said their code wouldn’t work; Crowther and Walden knew it would. In writing the “kernel” of their program (“the very small part that is the only thing that matters,” as Crowther put it), they had discovered how few commands would actually be needed in a software program to pull packets into the IMP, figure out where to send them, and push them out on the next line.
Crowther and Walden quickly worked out the critical algorithms—the basic rules for solving the packet-processing and routing problems. That had lead them to the determination that it would take only one hundred fifty lines of code to process a packet through one of the IMPs. But without a real machine to test it on, running the code would have to wait. Nonetheless, they had a good feeling the IMP would work.
A key task that Heart worried about, but didn’t have to handle, was the subcontract with AT&T. It was Larry Roberts’s responsibility to arrange for the 50-kilobit lines (able to transmit about two pages of text per second) into each host site by the date the IMPs were ready. Roberts turned the job over to another Pentagon agency, now working with AT&T on the terms for the installation and leasing of the proper lines, modems, and other communications gear necessary to form links in the network. The physical connection from the IMPs to the local telephone office was to be made by normal telephone wire— two twisted pairs of copper wires wrapped in a cable containing about a thousand other twisted pairs—with special terminating equipment at each end to support the high data rates. The dedicated lines and other equipment were to be in place at the California sites by the time the first IMPs arrived in the fall. Heart knew the telephone company was going to have to scramble to meet its obligations, and he was glad that securing AT&T’s cooperation wasn’t his problem.
Roberts was a distant but persistent force, vital to the project. His style was to stay out of the way of principal investigators most of the time. Whenever he did inject himself into a project, he never wasted anyone’s time. He always made his point and moved on. People in the growing computer community came to regard Roberts highly.
These were great days to be running the Information Processing Techniques Office at ARPA. With Taylor and Roberts there, the budget for computing research kept growing even as the rest of ARPA’s funds were being slashed because of the escalating cost of the Vietnam War. IPTO’s managers could spend money on priorities of their own choosing. And they could just as easily rescind funding if they didn’t receive the kind of cooperation they wanted from contractors.
Giving ample authority to people like Roberts was typical of ARPA’s management style, which stretched back to its earliest days. It was rooted in a deep trust of frontline scientists and engineers. On his deathbed in 1969, Dwight Eisenhower asked a friend about “my scientists” and said they were “one of the few groups that I encountered in Washington who seemed to be there to help the country and not help themselves.” Indeed, many of the best scientists in the country, Roberts among them, came to view working for the agency as an important responsibility, a way of serving.
But ARPA administrators were not well paid. Ornstein once hooked up with Roberts at an out-of-town meeting and saw Roberts driving a banged-up little rental car. Ornstein asked him why on earth he would rent such a heap. Roberts muttered something about how Ornstein didn’t understand government rules and expenses. “I always thought of him as passing out these millions of dollars,” said Ornstein. “It hadn’t occurred to me that he was in fact living, personally, on quite a limited budget. People like Larry sacrificed themselves for a while in order to get their hands on a big throttle.”
Roberts was treated in most respects as if he were a member of the BBN team, even though he was in Washington. He didn’t travel to Cambridge often, yet his presence was constantly felt. Since only a few people were working on the project at BBN, Roberts sat down with everyone together when he visited. These were informal talks about their progress, lengthy high-level rump sessions. As principal investigator and group manager, Frank Heart was Roberts’s main point of contact at BBN—but Roberts also stayed in close touch with Kahn.
Each site was responsible for building a custom interface between host and IMP. Since computers of various makes were involved, no single interface would do for all the sites. This entailed a separate hardware-and software-development project at each site and was not something the host teams could throw together overnight.
The IMP Guys had to write the host-to-IMP specification before the hosts could start building anything. Heart’s most urgent order of business was to complete BBN’s design of the host-to-IMP specification, so people at UCLA could begin working in time to meet Roberts’s schedule. Heart was already predicting difficulty in getting the host sites to complete their work on time. He knew how heavily the principal investigators relied on graduate students, and Heart worried that the project could be derailed because of a graduate student’s failure to treat the schedule seriously enough.
Days spent discussing the host-to-IMP specification turned into weeks. It became obvious that unless someone on Heart’s team seized the task of just writing the specification, there would be more talk and little writing. Kahn took it upon himself to draft the specification, and his colleagues were happy to let him. Heart thought Kahn was the best writer the group had, so he stood back and let Kahn produce the specification that became known as BBN Report 1822.
Some people thought Heart worried excessively about potential engineering failures. He was a most defensive driver when it came to engineering. Heart had learned cautious engineering early on from his mentor at Lincoln Lab, Jay Forrester, the inventor of core memory. Forrester had drummed reliability into the heads of a whole generation of MIT engineers. Above cost, performance, or anything else, reliability was their top priority— design for it, build for it, prepare for the worst, and above all, don’t put your machine in a position to fail. Heart’s mantra built reliability into the IMP in a thousand ways right from the start.
Computer manufacturers were known to cut corners in order to compete on price and build new machines on time. They almost always paid some price in terms of higher failure rates—bugs and computer crashes—but usually it didn’t ruin reputations. From Roberts to Heart, on down the line, all of the IMP Guys expected a higher standard in this project. A network running twenty-four hours a day would demand solid performance from the BBN-built IMPs. The accepted imperative was that the IMPs would do their best to deliver each and every message accurately. A line might fail, even a host machine might fail, but the IMPs should not. Reliability was, in a sense, the founding principle of the network. The ARPA network would always reflect Frank Heart’s own steady character.
Ornstein had a reputation as a hard taskmaster, and he was very effective as a technical examiner. His trademark line was, “I’m just a dumb hardware guy, convince me!” He wouldn’t let go until the explanation made sense to him. Often he uncovered some hidden soft spot.
Many of the planning sessions at BBN took place in the Weiner Room, a high-ceilinged conference room with a big square table and plenty of chalkboards. It was conveniently located at an intersection of corridors in the middle of BBN’s systems division, a crossroads between the 516 computer room, the lunchroom, and Heart’s office. The Weiner Room served as a regular gathering place for the IMP Guys. The IMP team was small enough, their offices close enough, and contact among team members frequent enough that formal design reviews were unnecessary. They talked in the hallways, sat in one another’s offices, debated, and shared ideas constantly. In the Weiner Room, chalk was applied liberally and often to explain, diagram, outline, argue, and teach. Ornstein used the room to hold an informal lecture series, in which software and hardware were explained in detail, and occasionally visitors would come in to talk about technical subjects. The whole team shared information. “Everybody knew everything,” a
s Crowther put it.
The team members also wrote a numbered series of informal technical notes that they circulated among themselves. The notes didn’t have a strict format but always began “The IMP Guys’Notes.” They wrote down their ideas, exchanged them, and then usually got together to discuss them. The notes also gave Heart a way of monitoring their progress.
Heart’s reviews of the work as it matured were nothing like traditional design reviews. A design review is usually a major event in the course of an engineering project. An engineering team may work for weeks preparing a design for review, then come together to submit, elaborate on, and debate it under the scrutiny of colleagues and senior engineers. Heart’s reviews tended to be ad hoc and ongoing, which isn’t to say that they were easy. “It was like your worst nightmare for an oral exam by someone with psychic abilities,” recalled Bernie Cosell, the team’s ace software troubleshooter. “He could intuit the parts of the design you were least sure of, the places you understood least well, the areas where you were just song-and-dancing, trying to get by, and cast an uncomfortable spotlight on parts you least wanted to work on, meanwhile virtually ignoring the parts you were so proud of for having gotten really nailed down and done right.”
Like the less-frequent meetings with Roberts, Heart’s design reviews were meant “to help thrash through the hard parts,” Cosell said. Heart had implicit respect for the things his engineers did that worked well. But he was sparing with his praise. His attitude seemed to be, Why waste time with that? Younger and less experienced engineers might have been devastated by the lack of positive feedback from Heart, but the IMP Guys were a seasoned, closely knit, self-assured bunch well accustomed to Heart’s ways.
Because of Heart’s insistence on reliability, and Kahn’s early analysis of this area, a large number of error-control mechanisms were designed into the system. Every communications system is prone to errors in transmission caused by noise in the communication circuits. Voices passing through telephones, an analog transmission, can be garbled or ambiguous—as when the sounds of “s” and “f” are confused. Digital transmissions can also be distorted: a “1” can come through as a “0” and vice versa. Errors occur in bursts. If a given bit is in error, the probability of surrounding bits being in error is much higher than normal. Despite these problems, there are good techniques for detecting and even correcting digital errors, and the IMPs would have to rely on them.