LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAICN no. 2I2-220 Digitized by the Internet Archive in 2013 http://archive.org/details/timesharingatill217gear Report No. 217 /yut^oii 000-1469-0046 n TIME SHARING AT ILLINOIS: EXPERIENCE AND PLANS by C. W. Gear December 5> 19&6 THE LIBRARY Of \\\\ AUG 15 jorj UNIVERSITY 0f ILUwois The person charging this material is re- sponsible for its return on or before the Latest Date stamped below. Theft, mutilation, and underlining of books are reasons for disciplinary action and may result in dismissal from the University. UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN i-tii l 8 f £B 2 8 f L161— O-1096 Report No. 217 TIME SHARING AT ILLINOIS: EXPERIENCE AND PLANS by C. W. Gear December 5j 1966 Department of Computer Science University of Illinois Urbana, Illinois 6l801 1. Introduction This report will discuss the status of the experimental time-sharing system implemented on the ILLIAC II at Urbana and attempt to pass on to the reader the lessons that have been learned as a result of this work. The second part of the report will discuss the plans for the next system. This new system will be a part of the computer system providing general service for the Urbana campus. This future system will consist of IBM 3^0-50/75 main processors with links to other campus computers. This report is not intended for the expert in the time-sharing field but rather for the system man who is about to consider a large system and who would like to learn of some of the problems. 2. Present Hardware The processing capabilities of the present system are provided by the ILLIAC II with a 52 bit, 8K 1.7 micro second main memory 65K, 7 micro second/ word drum, and 10M words of disk file (two IBM 1301's at 100 micro seconds/ word) plus 10 magnetic tapes. A Digital Equipment Corporation PDP-7 and 63O is connected as an 1/0 channel with communication facilities for up to 6U serial low-speed I/O devices (in the range 100 to 2,000 bits per second). These serial I/O lines are used to connect the main terminals which are Teletype Model 33 or 35 devices via the Bell System 103A1 data phones. The phone input is such that a single telephone number accesses all available inputs. The hardware is indicated in Figure 1. 3. Present Software The software available is a hodge-podge of experimental programs each of which has been modified many times in order to test various ideas. The essential components of a time-sharing system are a general supervisory program, a file manipulation program, compilation and assembly programs, and ability to interact with an executing program. Perhaps the simplest form of a time-sharing system is one which provides only a minimum supervisory system as a skeleton to allow the user to interact with any program he chooses to -1- -2- to load. These programs can then include the file manipulation, translation, and other service programs. It is our feeling that in general this leads to high overhead of a system program; therefore, in the Illinois System, much of the user's work is done by common programs which we then consider to be part of the general supervisory system, In our particular case the supervisory system includes a file manipulation subsection which allows the inputting of files from the console or via the off-line card reader, the out putting of files at the console or via the off --line printer-punch combination and the updating of files. The files are maintained symbolically on the disk file. The general supervisor also allows these symbolic files to be processed by the Fortran com- piler or system assembler in order to obtain executeable programs. It allows programs to be loaded into core from these binary object programs. It provides ability to start, stop, examine, or change programs in "core" and provides ability to save a complete core load and reload it for use at a later time. The core load referred to is, of course, not kept permanently in core but switched in and out according to a scheduling algorithm. The program in core has access fco system programs which communicate with the console so that direct input/output can be performed (this is, of course, buffered so that CPU time is not lost while waiting on the user's response). Finally, a simple interpreter is provided which enables low level calculations to be performed rapidly without all the messing around that would be needed if the regular system compiler were to be used. A major lack in the present software is a conversational compiler suf- Lently similar to the standard system compiler such that programs can be de- bugged rapidly, Such a program is under construction at this time. h. Experience In the process of preparing the system we have thrown far more code away than we are using. Some of this waste could have been saved by prior simu- lation studies, but the majority could only have been found to be less than adequate by actually using it. This section will discuss a number of isolated points concerning hardware and software that have caused us problems and in some cases have been corrected. -3- A. Terminals We initially used IBM 10 50 terminals experimentally "but ran into a number of problems. In the first place they were unreliable in our environment and in the second place they had many features built into the logic that were undesirable for our purposes. If they had been used exactly as intended by the original designer, they would have probably been OK; but we found that a lot of code was used to overcome some of the problems Introduced by logic that one would rather not have been paying for. For example., the terminal can communicate in one direction at a time only and the turnaround can only be initiated by a designated controller. This means that in order to continue to accept informa- tion from a user terminal while retaining the ability to accept output from the computer should the need arise, it is necessary to continuously cycle the con- trollers from a transmit to a receive status and back. It is also necessary to relay a specific end-of -message character from both the user and the computer in order to effect a turnaround. Because of the problems, we switched to Teletype terminals. They are mechanically simple, require negligible electronics to Interface to a data phone, or to interface to a DC loop. They can be operated in either the half-duplex or full-duplex so our 63O communication box was constructed for such terminals. In half-duplex both the transmit and receive portions of the terminal and the computer are permanently connected to a single communication channel. Anything that is typed at the console appears on the printer and is transmitted to the computer. This enables "echo checking" to be done. The computer reads the character that is transmitted and checks it against the original. This guards against transmission errors, and also allows the terminal user to "break" trans- mission at any time by typing during output by the computer. The computer can be programmed to accept multiple echo checks as a user interrupt. In full-duplex there are two separate channels, one from the computer to the printing mechanism and one from the keyboard input to the computer. They are logically separate although both can be transmitted over one standard phone line. When the user types at a full-duplex terminal, nothing is printed unless the computer responds by transmitting the character back to the terminal. This introduces a delay of two character times (l/5 of a second) which some people find unnerving, but we think that a user would very quickly adjust. With hindsight we would have used full-duplex, since it can be programmed to do any- -4- thing that half -duplex can exept for echo checking and it has one further im- portant advantage: the competent user does not require that his keyboard input he printed; he will use the computer response as a check on his typing accuracy so he can continue to input ahead of the computer response, thus achieving over- lap of his typing with the unavoidable waiting for computer service. Be Use of Auxiliary Storage Whenever there is more than one level of storage, there is an assign- ment problem. Two levels are not so bad since the main level of storage can only be used for the monitor, incoming, executing, and outgoing program plus some buffer space. Three levels poses an additional problem since the drum is an order of magnitude faster than the disk (.13 times the word rate, l6 times the average access rate). We planned and we schemed over wnat should go where (one buffer per console on the drum, last use system processor on the drum, etc.). Unfortunately, any decision is only effective for a particular combi- nation of user demands, The change that would be expected from, say, a high console use period in the middle of the afternoon to a high background use period rate at night will make any absolute assignment less than efficient. Our solution—which was certainly not new—was to essentially forget that we had a drum and use the disk for everything- -except that the disk pro- grams were modified so that they used the drum as an intermediate buffer device. Unfortunately, it is not possible to transmit directly from the drum to the disk or visa versa, but by allocating a buffer area in the monitor, the trans- mission can be overlapped with processing. In the proposed scheme all disk writes are converted to drum writes which are an average of l6 times faster (in the case that a multiple block transfer is to be performed they are, in fact, about 20 times faster). The contents of drum are indexed by a table kept in core so that reads from the disk can be converted to reads from the drum if the information is already on the drum. If a read requires access to the disk then a copy is also kept on the drum in case it is needed again. As the drum starts to fill up, information not recently used is copied back to the disk. In order to improve the efficiency a little more, additional requests to the disk sub- routine were added. These requests included the "pre-need read" which told the system that a block from the disk file would be needed later on. Its purpose -5- was to encourage the system to move it to the disk file so that a disk access would not cause a wait at the time the information is needed, and a "write for good" request which indicated to the system that the block concerned need not be maintained on the drum since it would not be used in the foreseeable future. The advantages of this type of system approach to the use of multiple level auxiliary storage are that it saves program everywhere but in the disk file package, it saves making wrong decisions about the assignment of drum space (it is now done dynamically), and it is easier to reduce disk head travel by using algorithms to determine which of the blocks on drum to copy back to the disk. This sort of algorithm can be done on a machine with a large main memory but is impractical in a machine with a memory the size of ILLIAC II. C. Telephone Lines The use of a public switched network has its advantages and disadvan- tages. The main points to be made in its favor are the almost immediate avail- ability of a line to the majority of places in which a console is to be located, and the possibility of using the switching capability of the phone system to in- terface more potential consoles than there are inputs to the computer. If the terminal device is sufficiently cheap, then many consoles can be placed as close as possible to potential users (in their offices if necessary). Because not all of these users will be active at one time, it is not necessary to provide inputs for every one of them. The attendant disadvantages are the additional cost of phone lines, and of providing protection against unauthorized use. The cost of a hard-wired D.C. loop connection over a short distance (2,000 feet) is almost negligible compared with the cost of two dataphones and two phone lines (.about $70/month). Because anybody with a phone has access to the computer input, the system is faced with protection against accidental and deliberate misuse. It must be possible to detect (in order): (i) Non-data calls (from a voice phone), (ii) Unauthorized consoles (they may not use the same code), (iii) Unauthorized users. It must also be possible to disconnect the caller who does not meet the -6- restrictions, otherwise an input to the computer will be tied up unnecessarily. A hard-wired console is known to pass the first two tests, and if an unauthorized user insists on remaining at a console although the computer refuses to acknow- ledge him, one can rely on another user who needs that console displacing him. If, in addition, a console is dedicated to a specific user, then it is not necessary to provide elaborate file protection since access to certain files can be limited to a given console input. Another difficulty that should not be overlooked is the difficulty of using equipment being maintained by engineers from more than one other organi- zation. If your computer is maintained by its manufacturer, then the problem of allocating the responsibility for an error between the computer equipment and the telephone equipment is yours. This can become especially difficult when dealing with a large monolithic organization such as the telephone company. An example of a problem that we encountered in this respect was that the telephone company was at first unwilling to tell us what equipment was available, but rather, wanted to know what our needs were, then they would tell us what we should use. We found this unacceptable for a research investigation. D. Line Numbering Two types of character consoles are available currently, the type- writer-like console and the character display C.R.T. The former is less costly, and does not have to be placed close to an expensive controller which services order of 8 displays. We are using the former, so the remarks will apply only to those consoles. The problem to be tackled is one of modifying information in a file, stored, say, on the disk. In order to change any section, it is necessary to have some way of referring to it. To discuss the problem in concrete terms, let us assume that the file is divided into lines which are in a given order. There are three common ways that we could reference a particular line in the file — by its position (e.g. the 1^3rd), by content (e.g. the line that starts ABC ) , or by means of an additional ordered identifier, which we will call a "line number". Line numbers do not correspond to positions directly since the numbers need not be in an arithmetic progression. (e.g. 3, 10, 20, 25, 30 is a perfectly good ordered sequence of line numbers for referring to the (physically) -7- lst, 2nd, 3rd, Uth, and 5th lines In a file.) A combination of physical position and content addressing could pro- bably be used if a C.R.T. display with a fast enough display change were avail- able since it would be possible to "drive through" the file, visually scanning for the desired line. A typewriter is extremely limited in output capability, so it can only be used for checking. We attempted to use a content and physical addressing scheme for file maintenance, but it proved to be unacceptable in use. Operations were provided to move a 'pointer' through the file, either by a given number of lines or until a given content was located (e.g. the word 'ABCDEF' in character positions 8 through 13). Lines could be deleted, printed, or inserted at the position of the pointer. The idea behind this was that most files are programs in some language, and that programs can be indexed by location symbols or statement numbers etc. Although, from a user point of view this could be as good as a line numbering scheme; there were a number of practical drawbacks, all to do with speed. We have switched to line numbering, so, in order to make a comparison, we will describe the line numbering scheme. Each line has an associated number (in our case 3 digits, point, 3 digits). As lines of file are generated originally they are numbered, either by the user, or automatically by the system. It is usual to number them so that there are gaps between successive numbers, for example, ±.000, 2.000, etc. A line is inserted in a file by typing a number followed by the line. Lines are sorted in order of line number. Thus 1.500 is between 1 and 2. A line is de- leted by typing its number and a blank line. In the implementation^ the actual file is not changed each time that a change is typed, rather, an associated file of ' changes' is generated. Changing a file is costly because parts of it must be sorted and copied, usually involving time-consuming disk-head movement.. Therefore, we only merge the changes into a file when it is to be used in an operation that requires it to be sorted (e.g. translation and listing). By comparison, a content and physical location method requires that the file always be kept in order. If this is done by chaining, some disk mani- pulation is saved. On the other hand, searching, slow if the file is in order, is even slower if chaining is used. In a nutshell, our experiment with a non- line numbering scheme gave a negative result. Even if we were to improve it, we do not believe that it would be as useful as a line numbered scheme, so we have switched rather than fight. -8- E. Debugging Programs One of the virtues of time-sharing schemes is that you are supposed to be able to debug programs more quickly at a console. For purposes of dis- cussion, let us assume that the program is to be used for computations of a non-trivial nature at a later date, so that it must be written in an acceptable language such as Fortran, assembly language, Lisp, Algol, etc. Anyone can see that it is better to work at a console in such a language by trying the G.E./ Dartmouth system, for example. Indeed, for programs up to a few hundred lines, fairly straightforward systems are very good. But what happens when a few thou- sand lines of code are being debugged? If the source program is modified and retranslated, the amount of time is excessive (remember that compile time must be multiplied by the number of active users to estimate the delay). Because of a lack of facilities in our temporary system, we have found one of the best techniques for debugging using our temporary system to be octal patching. If a large program is being developed, we would modify it in octal from a console and check the changes, and then, when a sufficient number have been added, leave an updated source program for retranslation as a background program. What is needed in order to provide a way around this out-of-date debugging technique? The problem in the temporary system was that it was not convenient to partition a job into many subroutine segments and then only modify those of interest. (This is missing in the G.E. /Dartmouth system which allows no segmentation.) The new system will encourage the user to keep his job broken down into many small subroutines. It will only be necessary for him to specify the name of the main program that he wishes to execute; the system will search his files for all subroutines that he calls. If a segment is to be changed, then the user types the file name of the segment and the changes. He must then ask for it to be translated. The relocatable binary object is kept with the source file until any further changes are made to that file. When the subroutine is to be loaded and executed, the loader fetches the binary version. It is planned that if there is no binary version, the source will be automatically translated. This organization ensures that a file is never translated more than once between changes. When an interactive compiler compatible with Fortran is available, the user will be in a position to write and do most of the debugging of indivi- dual subroutines interactively, and then to store the programs as files in order -9- to test them as a group. Final changes can be made in source language to any one of the subroutines. F. Special Purpose Software The biggest single criticism of time sharing is that the overhead of system time is enormous . The usual answer to this is that the total cost of a job is reduced because less computer and man time is needed. This may be true, but it doesn't absolve us from the responsibility of finding more efficient methods. Much of the overhead is due to the necessity of either having enough main memory and hardware to provide the flexible relocation so that many pro- cesses can be waiting to be executed, or having to frequently swap large amounts of information with disk file. Shared programs can reduce this considerably, but in order to make shared program effective, it is necessary to arrange that more than one user will be needing the same program nearly simultaneously. This means that the prospect of every user with his personally customized version of a compiler is not going to be efficient, What must be done is to attempt to group users with like interests onto the same system and to provide a few flexible compilers or problem-oriented languages for their area. In other words, special-purpose programs are going to be more efficient, and, for that matter, better appreciated by users with those special needs. One large use of time-sharing systems is for programs that are barely beyond the desk calculator stage. The Joss system was based on such problems^ most other systems provide some equivalent. It has been rather sobering to note that the majority of users of the ILLIAC system use only the desk calcu- lator program (not because of the absence of desk calculators) --in fact, the system is generally known by the name of that special-purpose program. -10- 5. The Future System-Hardware An IBM 360/5O is due for delivery 2Q 67 with a model 75 to follow shortly. The purpose of this system, in which the 50 will "be a support pro- cessor for the 75, is to serve the campus computing needs , both in batch pro- cessing, low-speed terminals and special on-line processing for other depart- mental computers. Low-speed terminals will be connected via the PDP-7, so that it must be interfaced to the 50. In addition, service will almost certainly have to be provided to the Physics S.M.P. (Scanning and Measuring Projectors) via the CSX-1, to Civil Engineering who plan to implement a special purpose con- sole system on a 3^0/40, to ILLIAC III, to ILLIAC IV, and to Chemistry who have an IBM 1.800 on order for experimental instrumentation and control (see Figure 2) Therefore, these computers will he interfaced to the 50 in the future. A few additional small computers can be expected to require service in the lifetime of the system, In particular, a graphics terminal, the D.E.C.-338, will be connected via the P.D.P.-7. 6. Program Requirements Regular batch processing should be allowed from any of several read stations, some of which may eventually be remote. Low-speed terminals should provide one or more languages of an interactive compiler type which will pro- vide a capability extending from a simple desk calculator to a major subset of a standard language in the batch system so that smaller programs can be de- bugged on line, and simpler calculations can be completed. Interfaced computers must have the capability of having short bursts of calculation (5-10 sees.) completed without too long a delay, No provision is planned for interactive execution with a large program from a standard low-speed terminal. That would only be partially possible from a larger terminal such as the D.E.C.-338 which can request a burst of calculation. Because of the size and complexity of OS/360, it is desirable that it be modified as little as possible. Hence it is necessary that we work with whatever is available and fast enough for our use. The A.S.P. (Attended Support Processor) system is planned for use on the coupled 50/75. This allows the 50 to route jobs to the 75. The 75 functions under the control of OS except that syst' a I > is routed to the 50. The 50 software allows several devices to build -11- files, can schedule these files for processing on the 75, and allows programs to be "brought into the memory of the 50 from disk in order to process input files. Since one use, the high energy physics S.M.P. work, accounts for up to 25$> of the total computer load, it is worth investigating the characteristics of this use. 20$ is of the batch processing type in which several reels of tape or their equivalent must be scanned. It is probably tape limited on the 75. The remaining 5$ is on-line work direct from the CSX-1. If the required program (probably 150 K bytes or more) can be loaded rapidly, then about 3 to 5 seconds of compute will be needed about every 1.5 minutes. 7. A Proposal The following proposal is based on the requirements and the restric- tions discussed in the previous section. The need for frequent service to on- line computers by the model 75 dictates some form of time sharing, whereas pre- vious experience suggests that the overhead will be high if arbitrary numbers of programs are allowed to execute in a time slotted manner, assuming that some of these programs approach the full core size (256 K bytes for the model 50, 512 K bytes for the 75). In order to avoid the overhead of swapping, the number of programs in execution on the model 75 should not exceed the space available in core. Initial indications are that 3^0 object code is virtually unrelocatable after load time, so it will not be possible to dynamically relocate as require- ments change. Therefore, code will have to be loaded for a predetermined area of memory. Since the on-line physics requirements and similar requirements demand that the code be already in an absolute form on a high-speed device such as the drum of the model 75, a known area of memory must be allocated to such jobs. The proposal is to partition the 75 core into two equal regions. Both would be connected to the 50 for i/O (this requires a modification to A.S.P.). The 50 would schedule work for both partitions so that one will only receive short jobs of < N sees. (N about 5 to 15 seconds, it could change during the day). The bursts of calculation required by remote computers would be scheduled in this partition. They would, in general, get most of their code in absolute from the drum or disk. The second partition would receive all other -12- jobs for the 75. This organization would mean that high priority short jobs such as arise from S.M.P. could be serviced within 2N seconds, and that very short batch jobs could jump the queue of longer jobs. Long jobs, such as the physics batch work, could be scheduled in order of arrival without overly delay- ing these short jobs, and there is some possibility for overlap of I/O and pro- cess between I/O limited jobs such as the physics work and short process jobs from remote computers. Remote teletypes would be serviced interactively entirely at the PDP-7 and model 50 level to avoid interference with the process load. The facilities provided at the keyboard should include file handling, simple calculation, program testing, and submission of files to the 75 for processing on longer runs. This can be done largely within the ASP system by using its facility to load programs from the file for processing input files. The PDP-7 will buffer lines of characters and transmit them, with console numbers, to the 50. It will periodically analyse these and transmit any output back to the PDP-7. Within the file handling system it should provide facilities to update files equivalent to the facilities in the present ILLIAC II system, (See the Time Sharers' Manual.) An additional way of building a file should be provided by an interactive compiler. As lines with numbers are typed to it, they should be saved as a file. If the interactive compiler is a subset of the IBM Fortran IV or PL/l, the file can also be used within the batch processor at a subsequent time. The desk calculator and the interactive compiler can conveniently be combined by using the approach of Iverson's APL (Arithmetic Programming Language) If an expression is typed, it is evaluated and printed. Thus if the user wants to know ")/3.1 , he types SOJRT (3.1) and immediately gets the answer. If he types A = SQRT (3.1) the effect is to define a variable A (if it does not already exist) and set it to Y3.1. On the other hand, if a line of code is required, it is given a line number, for example 3.12 A = SQRT (3.1) inputs a line of code for compilation but not execution. -13- 80 Comments The proposal is based partly on the assumption that dynamic relocation will not be practical. if it is, then additional partitions could be used, al- though the cost of moving programs and scheduling will increase. The important areas that need investigation are: a. Is there sufficient file storage on the model 50 for the needs of remote uses and ASP? b. Is there enough drum space for the 75 system and some of the high use processors for remote computers? c. If not, can a dynamic use of the drum as in ILLIAC II be imple- mented? do Can sufficient overlap of I/O be achieved with only two partitions? (This perhaps should be simulated. ) e. What trade off between speed and size of an interactive compiler is best? -ll+- fTTY Bell 6~b- Telephone DEC 63O PDP-T 10M Words ) 65K Words 90 KC Tape Figure 1 Remote Batch Remote Computers Remote Low Speed Consoles 50M Words (231U) 1M Words 180 KC Tape 90 KC Tape ( i +)23H Loca Batch Figure 2 AUG ! 6 19S8