Hans van Staveren

Experiences with the Amoeba distributed operating system

The Amoeba project is a research effort aimed at understanding how to connect multiple computers in a seamless way [16, 17, 26, 27, 31]. The basic idea is to provide the users with the illusion of a single powerful timesharing system, when, in fact, the system is implemented on a collection of machines, potentially distributed among several countries. This research has led to the design and implementation of the Amoeba distributed operating system, which is being used as a prototype and vehicle for further research. In this article we will describe the current state of the system (Amoeba 4.0), and show some of the lessons we have learned designing and using it over the past eight years. We will also discuss how this experience has influenced our plans for the next version, Amoeba 5.0. Amoeba was originally designed and implemented at the Vrije Universiteit in Amsterdam, and is now being jointly developed there and at the Centrum voor Wiskunde en Informatica, also in Amsterdam. The chief goal of this work is to build a distributed system that is transparent to the users. This concept can best be illustrated by contrasting it with a network operating system, in which each machine retains its own identity. With a network operating system, each user logs into one specific machine—his home machine. When a program is started, it executes on the home machine, unless the user gives an explicit command to run it elsewhere. Similarly, files are local unless a remote file system is explicitly mounted or files are explicitly copied. In short, the user is clearly aware that multiple independent computers exist, and must deal with them explicitly. In contrast, users effectively log into a transparent distributed system as a whole, rather than to any specific machine. When a program is run, the system—not the user—decides upon the best place to run it. The user is not even aware of this choice. Finally, there is a single, system-wide file system. The files in a single directory may be located on different machines, possibly in different countries. There is no concept of file transfer, uploading or downloading from servers, or mounting remote file systems. A files position in the directory hierarchy has no relation to its location. The remainder of this article will describe Amoeba and the lessons we have learned from building it. In the next section, we will give a technical overview of Amoeba as it currently stands. Since Amoeba uses the client-server model, we will then describe some of the more important servers that have been implemented so far. This is followed by a description of how wide-area networks are handled. Then we will discuss a number of applications that run on Amoeba. Measurements have shown Amoeba to be fast, so we will present some of our data. After that, we will discuss the successes and failures we have encountered, so that others may profit from those ideas that have worked out well and avoid those that have not. Finally we conclude with a very brief comparison between Amoeba and other systems. Before describing the software, however, it is worth saying something about the system architecture on which Amoeba runs.

A practical tool kit for making portable compilers

The Amsterdam Compiler Kit is an integrated collection of programs designed to simplify the task of producing portable (cross) compilers and interpreters. For each language to be compiled, a program (called a front end) must be written to translate the source program into a common intermediate code. This intermediate code can be optimized and then either directly interpreted or translated to the assembly language of the desired target machine. The paper describes the various pieces of the tool kit in some detail, as well as discussing the overall strategy.

Performance of the world's fastest distributed operating system

Distributed operating systems have been in the experimental stage for a number of years now, but few have progressed to the point of actually being used in a production environment. It is our belief that the reason lies primarily with the performance of these systems---they tend to be fairly slow compared to traditional single computer systems. The Amoeba system has been designed with high performance in mind. In this paper some performance measurements of Amoeba are presented and comparisons are made with UNIX on the SUN, as well as with some other interesting systems. In particular, short remote procedure calls take 1.4 msec and long data transfers achieve a user-to-user bandwidth of 677 kbytes/sec. Furthermore, the file server is so fast that it is limited by the communication bandwidth to 677 kbytes/sec. The real speed of the file server is too high to measure. To the best of our knowledge, these are the best figures yet reported in the literature for the class of hardware used.

Using Peephole Optimization on Intermediate Code

Many portable compilers generate an intermediate code that is subsequently translated into the target machines assembly language. In this paper a stack-machine-based intermediate code suitable for algebraic languages (e.g., PASCAL, C, FORTRAN) and most byte-addressed mini- and microcomputers is described. A table-driven peephole optimizer that improves this intermediate code is then discussed in detail and compared with other local optimization methods. Measurements show an improvement of about 15 percent, depending on the precise metric used.

FLIP: an internetwork protocol for supporting distributed systems

Most modern network protocols give adequate support for traditional applications such as file transfer and remote login. Distributed applications, however, have different requirements (e.g., efficient at-most-once remote procedure call even in the face of processor failures). Instead of using ad hoc protocols to meet each of the new requirements, we have designed a new protocol, called the Fast Local Internet Protocol (FLIP), that provides a clean and simple integrated approach to these new requirements. FLIP is an unreliable message protocol that provides both point-to-point communication and multicast communication, and requires almost no network management. Furthermore, by using FLIP we have simplified higher-level protocols such as remote procedure call and group communication, and enhanced support for process migration and security. A prototype implementation of FLIP has been built as part of the new kernel for the Amoeba distributed operating system, and is in daily use. Measurements of its performance are presented.

FLIP; an Internetwork Protocol for Supporting Distributed Systems

Most modern network protocols give adequate support for traditional applications such as file transfer andremote login. Distributed applications, however, have different requirements (e.g., efficient at-most-once remote procedure call even in the face of processor failures). Instead of using ad hoc protocols to meet each of the new reqmrements, we have designed a new protocol, called the Fast Local Internet Protocol (FLIP), that provides a clean and simple integrated arwmmchto these new requirements. FLIP is an unreliable message protocol that provides both point-to-point communication and multicast communication, and requires almost no network management. Furthermore, by using FLIP we have simplified higher-level protocols such as remote procedure call and group communication, and enhanced support for process migration and security. A prototype implementation of FLIP has been built as part of the new kernel for the Amoeba distributed operating system, and isin daily use. Measurements of its performance are presented,

Does anybody out there want to write HALF of a compiler

University researchers love nothing better than to invent a new programmin g language . The trouble is, unless the language is only intended for mental exercise , the next step is writing a compiler for the new language, which is a lot of work . Typically one makes a prototype compiler that runs slowly and produces awful cod e for one particular CPU that happens to be available . Once the project succeeds , there is often a need for a better quality compiler or compilers for other machines . This step is even more work and even less fun . Over the past few years we hav e developed a set of tools that greatly eases the job of producing good quality port able compilers quickly . The purpose of this paper is to discuss the system, tel l what its current status is, and encourage other university researchers to tak e advantage of it .