NLTSS
Closed source | |
---|---|
Initial release | 1979 |
Final release | Final / 1988 |
Marketing target | Supercomputers |
Available in | English |
Update method | Compile from source code |
Platforms | CDC 7600, Cray-1, Cray X-MP, Cray Y-MP |
Kernel type | Microkernel |
License | Proprietary |
The Network Livermore Timesharing System (NLTSS, also sometimes the New Livermore Time Sharing System) is an operating system that was actively developed at Lawrence Livermore Laboratory (now Lawrence Livermore National Laboratory) from 1979 until about 1988, though it continued to run production applications until 1995. An earlier system, the Livermore Time Sharing System had been developed over a decade earlier.
NLTSS ran initially on a CDC 7600 computer, but only ran production from about 1985 until 1994 on Cray computers including the Cray-1, Cray X-MP, and Cray Y-MP models.
Characteristics
The NLTSS operating system was unusual in many respects and unique in some.
Low-level architecture
NLTSS was a
Mid-level architecture
NLTSS is a
NLTSS was a true network operating system in that its resource requests could come from local processes or remote processes anywhere on the network and the servers didn't distinguish them. A server's only means to make such distinctions would be by network address and they had no reason to make such distinctions. All requests to the servers appeared as network requests.
Communication between processes in NLTSS by convention used the Livermore Interactive Network Communication System (LINCS) protocol suite, which defined a
The notion of a "user" was only rather peripherally defined in NLTSS. There was an "account server" that kept track of which users were using which resources (e.g., requests to create objects such as file or processes required such an account capability). Access control was entirely managed with capabilities (communicable authority tokens).
File server
Any process could make requests to the file server for the creation of files (returning a file capability), ask to read or write files (by presenting a file capability), etc. For example, the act of reading a file generally required three buffer tables, one to send the request to the file server, one to receive the reply from the file server, and one to receive the data from the file. These three requests were generally submitted at one time to the message system, sometimes bundled with other requests. Control bits could be set in the buffer tables to awaken (unblock) a process whenever any of the buffer tables submitted were marked "Done". A library call to read a file would typically block until the control reply was received from the file server, though asynchronous I/O would of course not block and could check or block later. Any such differences on the user side were invisible to the file server.
Process server
In NLTSS the process server was quite similar to the file server in that user processes could ask for the creation of processes, the starting or stopping of processes, reading or writing process memory or registers, and to be notified of process faults. The process server was an ordinary
Directory server
An example higher level server in NLTSS was the directory server. This server's task was to essentially turn files (invisible to the user) into directories that could be used to store and retrieve capabilities by name. Since capabilities were simply data this wasn't a particularly difficult task, consisting mostly of manipulating access permissions on the capabilities according to the conventions defined in the LINCS protocol suite. One place where this got a bit interesting was regarding an access permission named inheritance. If this bit was on (allowed), then capabilities could be fetched with their full access from the directory. If this bit was turned off (disallowed), then any permissions turned off in the directory capability were in turn turned off in the capability being fetched before it was returned to the requesting application. This mechanism allowed people to store, for example, read/write files in a directory, but to give other users only permission to fetch read-only instances of them.
Development
The bulk of the programming for NLTSS was done in a Pascal extension developed at Los Alamos National Laboratory known as "Model". Model extended Pascal to include an abstract data type (object) mechanism and some other features.
NLTSS was saddled with a compatibility legacy. NLTSS followed the development and deployment of the Livermore Time Sharing System (LTSS) in the Livermore Computer Center at LLNL (~1968–1988?). NLTSS development began about the same time LTSS was ported to the
Even the name NLTSS was something of a legacy. The "New Livermore Time Sharing System" name was initially considered a temporary name to use during development. Once the system began to run some applications in a dual system mode (sort of a virtual machine sharing drivers with LTSS) a more permanent name, LIncs Network Operating System (LINOS), was chosen by the developers. Unfortunately, the management at LLNL decided that the name couldn't be changed at that point (seemingly because the prior term had been used in budget requests) so the temporary development NLTSS name stayed with the system throughout its lifetime.
A mass storage system was also developed in parallel with NLTSS that used the LINCS protocols (same file and directory protocols as NLTSS). This system/software was later commercialized as the Unitree product. Unitree was generally superseded by the High Performance Storage System (HPSS) that could loosely be considered a legacy of LINCS and NLTSS. For example, LINCS and NLTSS introduced a form of third party transfer (to copy file to file in NLTSS a process could send two requests to file servers, one to read and one to write and direct the file servers to transfer the data between themselves) that carried through in modified form to Unitree and HPSS.
Implementation and design issues
The biggest knock against NLTSS during its production lifetime was performance. The one performance issue that affected users most was file access
A second implementation issue with NLTSS related to the security/integrity of its capability as data implementation. This implementation used a password capability model (e.g., see Control by Password).
A design issue with NLTSS that wasn't considered until years after it was removed from production was its open network architecture. In NLTSS processes were considered as virtual processors in a network with no
See also
References
- ^ "Components of a Network Operating System". webstart.com.
- ^ "Managing Domains in a Network Operating System". webstart.com.
- ^ "Managing Domains in a Network Operating System". webstart.com.
- ^ "YURL". Waterken Inc.
- ^ "Home". wideword.net.
Further reading
- J. E. Donnelley, Components of a Network Operating System, Fourth Conference on Local Networks, Minneapolis, 1979. Also in Computer Networks 3 (1979) 389–399.
- J. E. Donnelley, Managing Domains in a Network Operating System, Proceedings of Local Networks and Distributed Office Systems Conference, London, May 1981, pp. 345–361.
- S. T. Brugger, M. Gandhi, and G. Streletz, Network Livermore Time Sharing System (NLTSS), 2001
External links
- Capability Computing at LLNL A discussion of the history of the use of capabilities in computing at LLNL, including a brief mention of the RATS system and how the development lead to NLTSS
- Stories of the Development of Large Scale Scientific Computing at Lawrence Livermore National Laboratory
- The NLTSS Chronicles Cartoons from the development of NLTSS and LINCS