CSE 221 Paper Evaluations

Greg Johnson (johnson@SDSC.EDU)
Wed, 3 May 2000 21:35:09 -0700 (PDT)

D. Cheriton and W. Zwaenepoel, 1983.

This paper describes the design and performance of the V kernel. V
provides a simple and efficient message-oriented approach to network
transparent interprocess communication. The focus of this messaging
facility is support of remote file access (the V implementation runs
on a collection of diskless workstations).

The V messaging scheme distinguishes between small messages of fixed
length (primarily for control information) and larger data transfers.
The former simplifies problems associated with message buffers and
supports relatively efficient explicit synchronization (matched send
/ receive pairs). The latter allows data to be moved from memory on
one machine directly to that of another (again, efficiency).

Unlike LOCUS, message passing facilities in V are intended to be
general purpose and accessible to all processes. Further, unlike
Accent, the V messaging system achieves efficiency by minimizing
overhead associated with layered transport protocols (though at the
expense of a rich feature set).

Much of the discussion on the performance of V (and justification of
several V design elements) relies on the relative speeds of the CPU,
disk, and network hardware of the early 80's. In one example the
authors state that minimizing communication between machines may not
be necessary since the difference between a local and remote exchange
of messages is merely 2 milliseconds. Today however, the difference
if the relative performance of CPU vs. disk vs. network is much more
extreme. Processor speeds have increased by one to two orders of
magnitude since 1983, yet the speed of the average network is similar
to that described in the paper. Given a ratio of speeds similar to
that found in today's hardware components, I suspect V would feature
different design elements (data transfer operations integrated fully
with the Send / Receive primitives for example).


J. Ousterhout, A. Cherenson, F. Douglis, et al., 1988.

This paper describes the Sprite OS in detail, placing specific emphasis
on the file system, kernel, virtual memory, and process migration. The
authors also show the performance resulting from several of their design

Sprite endeavors to provide full transparency in terms of naming, resource
access, and process migration. Like LOCUS, Sprite separates names from
physical locations, and any data on any storage medium is accessible to
any process on any machine. Sprite even goes so far as to hide the fact
that a process (started locally) may be running elsewhere, from the user.
The remote process shows up in process listings on the local machine and
may be manipulated from the local host.

One feature of the Sprite kernel is that it (unlike the UNIX of its day)
is multithreaded, allowing multiple processes to execute in the kernel
simultaneously, and avoid contention for a single kernel lock. A second
feature of the kernel is its use of remote procedure calls in place of
messaging between machines to invoke remote operations. Both of these
design elements were chosen to help Sprite take full advantage of multi-
processor systems and efficient communication between such boxes.

The Sprite filesystem provides several interesting features. One of these
is its handling of the file name space. Like UNIX, the Sprite approach is
distributed (different servers own distinct regions of the file hierarchy),
yet Sprite prefix tables (similar to UNIX mount tables) can be dynamically
updated. Also, Sprite caches file data on clients and servers, minimizing
file IO and associated network transactions, improving overall performance.

One nifty feature of Sprite's virtual memory design is a natural result of
the use of ordinary files for backing storage, and the file caching scheme
mentioned previously. This combination enables servers to cache memory
segments from clients, essentially extending client main memories.

The Sprite design seems sufficiently neat that it begs the question "why
with the existence of mature distributed operating system designs, don't
we see more of them in use today."

Greg Johnson office: (858) 534-8367
Senior Programmer Analyst fax: (858) 534-5152
San Diego Supercomputer Center email: johnson@sdsc.edu
University of California San Diego