CDEV-NT: Porting the Control Device Interface to Windows NT

In recent years the rapid increase in processing power of the personal computer has made it a significant competitor to high-end workstations for accelerator control and experimental physics applications. When the decreasing price of the PC and the availability of inexpensive commercial software is also considered, NT becomes a very attractive alternative to traditional UNIX systems. In order to simplify the integration of Personal Computers into our operating environment, we have ported the Control Device (CDEV) Interface to Windows NT. By supporting CDEV on this platform, we can provide routine access to our existing control system. Additionally, CDEV allows us to create an interface from our UNIX workstations to Windows NT applications (such as databases) that are significantly less expensive on the PC. This paper details the pitfalls we encountered during the software migration and will provide a direct comparison between the performance of CDEV applications on UNIX and NT. P articular attention is paid to network performance, which represents most of the overhead of this transition

Construction of a WorkBench using Free PC - UNIX

Recently，the performance of personal computers is getting close to that of workstations a few years ago，and the cost of them has become much cheaper. As a result，some UNIX-like operating systems on personal computers， so-called PC-UNIX，have been developed rapidly. Under these circumstances，we try to construct a workbench system in our laboratory computer network，using one of free PC-UNIXs(Linux)，their free applications software and an IBM -PC/AT clone machine. In this report，we show the performance of our constructed workbench in comparison with that of other workstations

Functional requirements document for the Earth Observing System Data and Information System (EOSDIS) Scientific Computing Facilities (SCF) of the NASA/MSFC Earth Science and Applications Division, 1992

Five scientists at MSFC/ESAD have EOS SCF investigator status. Each SCF has unique tasks which require the establishment of a computing facility dedicated to accomplishing those tasks. A SCF Working Group was established at ESAD with the charter of defining the computing requirements of the individual SCFs and recommending options for meeting these requirements. The primary goal of the working group was to determine which computing needs can be satisfied using either shared resources or separate but compatible resources, and which needs require unique individual resources. The requirements investigated included CPU-intensive vector and scalar processing, visualization, data storage, connectivity, and I/O peripherals. A review of computer industry directions and a market survey of computing hardware provided information regarding important industry standards and candidate computing platforms. It was determined that the total SCF computing requirements might be most effectively met using a hierarchy consisting of shared and individual resources. This hierarchy is composed of five major system types: (1) a supercomputer class vector processor; (2) a high-end scalar multiprocessor workstation; (3) a file server; (4) a few medium- to high-end visualization workstations; and (5) several low- to medium-range personal graphics workstations. Specific recommendations for meeting the needs of each of these types are presented

Functional requirements document for NASA/MSFC Earth Science and Applications Division: Data and information system (ESAD-DIS). Interoperability, 1992

These Earth Science and Applications Division-Data and Information System (ESAD-DIS) interoperability requirements are designed to quantify the Earth Science and Application Division's hardware and software requirements in terms of communications between personal and visualization workstation, and mainframe computers. The electronic mail requirements and local area network (LAN) requirements are addressed. These interoperability requirements are top-level requirements framed around defining the existing ESAD-DIS interoperability and projecting known near-term requirements for both operational support and for management planning. Detailed requirements will be submitted on a case-by-case basis. This document is also intended as an overview of ESAD-DIs interoperability for new-comers and management not familiar with these activities. It is intended as background documentation to support requests for resources and support requirements

Workshop on NASA workstation technology

RIACS hosted a workshop which was designed to foster communication among those people within NASA working on workstation related technology, to share technology, and to learn about new developments and futures in the larger university and industrial workstation communities. Herein, the workshop is documented along with its conclusions. It was learned that there is both a large amount of commonality of requirements and a wide variation in the modernness of in-use technology among the represented NASA centers

You and I are Past Our Dancing Days

Operating systems have grown in size and functionality. Today's many flavours of Unix provide a multi-user environment with protection, address spaces, and attempts to allocate resources fairly to users competing for them, They provide processes and threads, mechanisms for synchronization and memory sharing, blocking and nonblocking system calls, and a complex file system. Since it was first introduced, Unix has grown more then a factor twenty in size. Several operating systems now consist of a microkernel, surrounded by user-space services [Accetta et al., 1986; Mullender et al., 1990; Rozier et al., 1988]. Together they provide the functionality of the operating system. This operating system structure provides an opportunity to make operating systems even larger. The trend for operating systems to grow more and more baroque was signalled more than a decade ago [Feldman, 1980], but has continued unabated until, today, we have OSF/1, the most baroque Unix system ever. And we have Windows/NT as a demonstration that MS-DOS also needed to be replaced by something much bigger and a little better.\ud In this position paper, I am asking what community we serve with our operating systems research. Should we continue doing this, or can we make ourselves more useful to society and industry by using our experience in operating systems in new environments.\ud I argue that there is very little need for bigger and better operating systems; that, in fact, most cPus will never run an operating system at all; and that our experience in operating systems will be better applied to designing new generations of distributed and ubiquitous applications

Status and projections of the NAS program

NASA's Numerical Aerodynamic Simulation (NAS) Program has completed development of the initial operating configuration of the NAS Processing System Network (NPSN). This is the first milestone in the continuing and pathfinding effort to provide state-of-the-art supercomputing for aeronautics research and development. The NPSN, available to a nation-wide community of remote users, provides a uniform UNIX environment over a network of host computers ranging from the Cray-2 supercomputer to advanced scientific workstations. This system, coupled with a vendor-independent base of common user interface and network software, presents a new paradigm for supercomputing environments. Background leading to the NAS program, its programmatic goals and strategies, technical goals and objectives, and the development activities leading to the current NPSN configuration are presented. Program status, near-term plans, and plans for the next major milestone, the extended operating configuration, are also discussed

Process Management in Distributed Operating Systems

As part of designing and building the Amoeba distributed operating system, we have come up with a simple set of mechanisms for process management that allows downloading process migration, checkpointing, remote debugging and emulation of alien operating system interfaces.\ud The basic process management facilities are realized by the Amoeba Kernel and can be augmented by user-space services: Debug Service, Load-Balancing Service, Unix-Emulation Service, Checkpoint Service, etc.\ud The Amoeba Kernel can produce a representation of the state of a process which can be given to another Kernel where it is accepted for continued execution. This state consists of the memory contents in the form of a collection of segments, and a Process Descriptor which contains the additional state, program counters, stack pointers, system call state, etc.\ud Careful separation of mechanism and policy has resulted in a compact set of Kernel operations for process creation and management. A collection of user-space services provides process management policies and a simple interface for application programs.\ud In this paper we shall describe the mechanisms as they are being implemented in the Amoeba Distributed System at the Centre for Mathematics and Computer Science in Amsterdam. We believe that the mechanisms described here can also apply to other distributed systems