William R. Crowther

Pluribus: a reliable multiprocessor

As computer technology has evolved, system architects have continually sought new ways to exploit the decreasing costs of system components. One approach has been to pull together collections of units into multiprocessor systems. Usually the objectives have been to gain increased operating power through parallelism and/or to gain increased system reliability through redundancy.

Flow Control in a Resource-Sharing Computer Network

In this paper, we discuss flow control in a resourcesharing computer network. The resources consist of a set of inhomogeneous computers called hosts that are geographically distributed and are interconnected by a store-and-forward communications subnet. In the communication process, messages pass between hosts via the subnet. A protocol is used to control the flow of messages in such a way as to efficiently utilize the subnet and the host resources. In this paper, we examine in some detail the nature of the flow control required in the subnet and its relation to the host flow control and subnet performance.

The Monarch parallel processor hardware design

The Monarch architecture team took advantage of custom VLSI in the design of a shared-memory parallel processor. The simple structure eases the task of programming a massively parallel machine.<<ETX>>

The terminal IMP for the ARPA computer network

A little over three years ago the Advanced Research Projects Agency of the Department of Defense (ARPA) began implementation of an entirely new venture in computer communications: a network that would allow for the interconnection, via common-carrier circuits, of dissimilar computers at widely separated, ARPA-sponsored research centers. This network, which has come to be known as the ARPA Network, presently includes approximately 20 nodes and is steadily growing. Major goals of the network are (1) to permit resource sharing, whereby persons and programs at one research center may access data and interactively use programs that exist and run in other computers of the network, (2) to develop highly reliable and economic digital communications, and (3) to permit broad access to unique and powerful facilities which may be economically feasible only when widely shared.

Issues in packet switching network design

The goals of this paper are to identify several of the key design choices that must be made in specifying a packetswitching network and to provide some insight in each area. Through our involvement in the design, evolution, and operation of the ARPA Network over the last five years (and our consulting in the design of several other networks), we have learned to appreciate both the opportunities and the hazards of this new technical domain.

Flow control in a resource-sharing computer network

In this paper we discuss flow control in a resource-sharing computer network (1). The network resources consist of a set of inhomogeneous computers called Hosts that are geographically distributed and are interconnected by a store-and-forward communications subnet. Each Host is connected to a store-and-forward switching node called an Interface Message Processor or an IMP, which is located on or nearby its premises (2). IMPs are then interconnected by leased synchronous communication circuits to form the subnet.

Reliability issues in the ARPA network

Since the inception of the ARPA Network1 in 1969, we have been part of the group responsible for the development of that networks communications subnet. This role has provided us with a unique opportunity for study of the problems of network reliability and the effects of attempted improvements, particularly in the context of rapid network growth. Our overall philosophy for this effort has been that the network should be fault-tolerant with respect to individual component errors, and that the IMPs themselves should be fault-tolerant with respect to local failures. Along with this concern, we feel that the program should provide as much diagnostic information as possible. Component failures are of several kinds: hardware or software; solid, intermittent, or one-time. As we will discuss in the following sections, our attention has shifted in the last few years from handling circuit errors and failures to handling more difficult problems in the IMPs themselves: first intermittent problems, and recently even solid failures of major components.