Keith A. Lantz

Finding idle machines in a workstation-based distributed system

The design and performance of scheduling facilities for finding idle hosts in a workstation-based distributed system are described. The focus is on the tradeoffs between centralized and decentralized architectures with respect to scalability, fault tolerance, and simplicity of design, as well as several implementation issues of interest when using multicast communication. It is concluded that the principal tradeoff between the two approaches is that a centralized architecture can be scaled to a significantly greater degree and can more easily monitor global system statistics, while a decentralized architecture is simpler to implement.<<ETX>>

Structured Graphics for Distributed Systems

One of the most important functions of an intelligent workstation is to provide a state-of-the-art user interface to distributed resources. One aspect of such an interface is virtual terminal support for both local and remote applications with a range of requirements, including graphics. To ensure good response for remote applications, in particular, the bulk of user interaction must be handled local to the workstation. Therefore, the terminal management software on the workstation must provide object modeling as well as viewing facilities, in contrast to most contemporary graphics systems. One way of doing this is to support structured display files. It is equally important to support simultaneous access to multiple applications; thus the terminal management software must provide window system Lscilities. Lastly, since the terminal management software should present a common interface to both local and remote applications, the workstation itself should be regarded as a multifunction component of the distributed system and not strictly as a terminal or a personal computer. This paper presents the system architecture and protocols necessary to achieve these goals and evaluates an existing implementation.

An Empirical Study of Distributed Application Performance

A major reason for the rarity of distributed applications, despite the proliferation of networks, is the sensitivity of their performance to various aspects of the network environment. We demonstrate that distributed applications can run faster than local ones, using common hardware. We also show that the primary factors affecting performance are, in approximate order of importance: speed of the users workstation, speed of the remote host (if any), and the high-level (above the transport level) protocols used. In particular, the use of batching, pipelining, and structure in high-level protocols reduces the degradation often experienced between different bandwidth networks. Less significant, but still noticeable improvements result from proper design and implementation of the underlying transport protocols. Ultimately, with proper application of these techniques, network bandwidth is rendered virtually insignificant.

Factors affecting the performance of distributed applications

A major reason for the rarity of distributed applications, despite the proliferation of networks, is the sensitivity of their performance to various aspects of the network environment. Contrary to much popular opinion, we demonstrate that CPU speed remains the predominant factor. With respect to network issues, we focus on two approaches to performance enhancement: (1) Improving the performance of reliable, byte-stream protocols such as TCP; (2) the use of high-level protocols that reduce the frequency and volume of communication.

Perseus: retrospective on a portable operating system

We describe the operating system Perseus, developed as part of a study into the issues of computer communications and their impact on operating system and programming language design. Perseus was designed to be portable by virtue of its kernel‐based structure and its implementation in Pascal. In particular, machine‐dependent code is limited to the kernel and most operating systems functions are provided by server processes, running in user mode. Perseus was designed to evolve into a distributed operating system by virtue of its interprocess communication facilities, based on message‐passing. This paper presents an overview of the system and gives an assessment of how far it satisfied its original goals. Specifically, we evaluate its interprocess communication facilities and kernel‐based structure, and discuss its portability. We close with a brief history of the project, pointing out major milestones and stumbling blocks.

Whiter (or wither) UIMS

The subject of User Interface Management Systems (UIMS) has been a topic of research and debate for the last several years. The goal of such systems has been to automate the production of user interface software. The problem of building quality user interfaces within available resources is a very important one as the demand for new interactive programs grows. Prototype UIMSs have been built and some software packages are presently being marketed as such. Many papers have been published on the topic. There still, however, remain a number of unanswered questions. Is a UIMS an effective tool for building high quality user interfaces or is the run-time cost of abstracting out the user interface too high? Why are there not more UIMSs available and why are they not more frequently used? Is simple programmer productivity alone sufficient motivation for learning and adopting yet another programming tool? What is the difference, if any, between a “user interface toolbox”, a windowing system and a UIMS? What are the differences between a UIMS and the screen and editor generators found in fourth generation languages? In fact, exactly what is a UIMS? In order to discuss these questions and to reassess the state of the UIMS art, SIGGRAPH sponsored a workshop on these issues (proceedings will be published in Computer Graphics in 1987). The panelists represent four subgroups who have each addressed these problems from different points of view.