I'm always amazed at how long a piece of apparently obsolete equipment can remain in service, especially in government service. Bruce Schneier's blog listed a link to NSA's 1991 video catalog at governmentattic.org. The catalog grants us an interesting if spotty view into the world of crypto gear and classified data collection systems.
I was particularly astonished to see inclusion of a video about the Pluribus - a long-obsolete Arpanet-era packet switch. I worked on the beast: it was overbuilt and underpowered. And unreliable (more on that another time). In the ideal world of tech, such obsolete junk should have been recycled by 1991. I was optimistic.
The Pluribus was classic PDP-11 Unibus-style technology, except that it didn't use the PDP-11. Instead, it was built with the Lockheed Sue, a PDP-11 knockoff. The story was that Digital Equipment Corporation (DEC), developer of the innovative PDP-11, complained to Lockheed about the similarity, and possibility of patent infringement. Lockheed said, "So sue us!" and named the product line accordingly.
According to legend, DEC did sue, though Lockheed got to keep making some non-infringing variant of the Sue. When Bolt Beranek and Newman (BBN) was looking at processors to use for a multiprocessor packet switch, they chose the Sue over the -11. I don't remember why (I wasn't there) but I remember some allegations that multiprocessing was easier, or perhaps just cheaper, with the Sue.
The Pluribus, then, was a multiprocessor-based packet switch. They had 2-4 (usually 2) processors per bus, and custom-designed 'bus couplers' to connect separately powered bus chassis. The independent buses in theory allowed faster processing, though a lot of programs were run out of banks of shared RAM that resided on other buses.
The Pluribus would keep running even if you powered down a chassis. It was a favorite demo. The affected Sue processors would go dim, but the others would keep slinging packets. The remaining processors would detect that some stuff was left unfinished by the killed processors and go back and clean things up. If we discarded packets, all was fine, since neighboring packet switches would retransmit them. When you powered up the chassis, it all came back to life.
Obsolescence
So, we have this 1970s processor technology packaged in refrigerator-sized racks to provide 1970s-era packet switching. And NSA deployed it in 1980, three years before the Arpanet switched over to TCP/IP. And it was still in use in 1991. I suppose I shouldn't be surprised. It is incredibly difficult to get rid of obsolete equipment if they support a working system. The Pluribus couldn't handle very vast network speeds. It was originally designed for T-0 leased transmission lines. Those ran as fast as today's commodity dial-up modems: 56K bits/sec. In about 1979 the Pluribus was upgraded to support megabit satellite links, but it took special hacking. I suppose that made it fast enough to support early 1990s traffic. In the late 1990s, the Y2K frenzy reminded us of how many ancient business applications were written in COBOL in past years but still did essential processing for major corporations. I suspect some of those programs are still running, having survived the Y2K transition. But that's not the worst case. When I started working on defense e-mail in the early 1990s, I encountered AUTODIN, the military's teletype network. The AUTODIN replacement had been a big topic of discussion at BBN when I was there over a decade earlier, but there it was, still running in the '90s. The new vision was to replace it with secure e-mail. And soon. Earl Boebert, our technical director, was skeptical. He told me about his first day at work. He was a fresh-faced leutenant in the Air Force reporting to a communications center in the 1960s. The officer briefed him on the various comms devices spread across the room, pointedly ignoring a mass of equipment in back. Finally, Earl asked. The officer replied, dismissively, "Oh, that's just AUTODIN. Don't worry about it. We're supposed to be replacing it soon."Post category:
