The Pluribus had its beginnings in 1972 when the need for a second-generation interface message processor (IMP) became apparent. At that time, the BBN had already installed IMPs at more than thirty-five ARPANET sites. These IMPs were Honeywell 316 and 516 minicomputers. The network was growing rapidly in several dimensions: number of nodes, hosts, and terminals; volume of traffic; and geographic coverage (including plans, now realized, for satellite extensions to Europe and Hawaii).
A goal was established to design a modular machine which, at its lower end, would be smaller and less expensive than the 316's and 516's while being expandable in capacity to provide ten times the bandwidth of, and capable of servicing five times as many input-output (I/O) devices as, the 516. Related goals included greater memory addressing capability and increased reliability.
The designers decided on a multiprocessor approach because of its promising potential for modularity, for cost per performance advantages, for reliability, and because the IMP packet switch algorithms were clearly suitable for parallel processing by independent processors.
A Pluribus consisted of two or more standard 19" electronic equipment racks, each divided into four bays. Each bay contained a backplane bus and an independent power supply. A bay might contain a processor bus, a shared memory bus, or an I/O bus. Custom-built bus couplers connected the bays to one another so that the processors could reach the shared memory and the I/O devices.
A 6-processor Pluribus was used as a network switch to interconnect BBN's five Tenex/"Twenex" timesharing systems along with 378 terminals on direct serial and dial-in modem lines. The Pluribus used the Lockheed SUE as its processor. The SUE was similar to DEC's PDP-11.
The Pluribus software implemented MIMD symmetric multiprocessing. Software processes were implemented using non-preemptive multiprogramming. Process scheduling used a hardware device, called the pseudo-interrupt device or PID, that was accessible to both programs and to I/O devices. Each processor ran its own copy of the process scheduler, which would read an integer value from the PID. The value was used to select the process to run. If a program or device needed to signal another process to run, it would write that process' number into the PID. The PID would emit the highest priority process that anyone had requested, and served them out to all processors.
An important aspect of the Pluribus software was the "STAGE" system, which detected system errors and took steps to recover from them. The processor clocks had interrupt handlers which implemented watchdog timers on all processors. If a processor stopped running, another processor would detect it and initiate a recovery. The recovery process would unlock any locks placed on shared resources, release allocated storage, and restart all processing on all processors. This was acceptable on an ARPANET routing node, since any lost packets would eventually be retransmitted.
- S. M. Ornstein, William R. Crowther, M. F. Kraley. R. D. Bressler, A. Michel, Frank E. Heart (1975). "Pluribus - A reliable multiprocessor". Proc. AFIPS 44: 551–559.
- C. R. Morgan, M. F. Kraley, et al. (April 1977). Pluribus Document 2: System Handbook. BBN Report 2930. Bolt, Beranek, and Newman, Inc.
- D. Katsuki, E. S. Elsam, W. F. Mann, E. S. Roberts, J. G. Robinson, F. S. Skowronski, E. W. Wolf (1978). "Pluribus-An Operational Fault-Tolerant Multiprocessor". Proceedings of the IEEE 66 (10): 1146–1159. doi:10.1109/PROC.1978.11109.