Slow

A user perceived the system as slow in at least two ways. The first was during the execution of a moderate size program. For example, a typical 50 page assembly on CAL TSS, using the CDC assembler running under the SCOPE simulator, required about two and one half times as much CPU time as under the real SCOPE system. The second was the time required to start a program. For example, with no other users on the system it required about 15 seconds of real time to start the SCOPE simulator, assemble a null program with the assembler and return. The major contribution to the system CPU cost for running a program was from disk file I-O, either explicit file reads and writes, or implicit via placement in map entries. Shortly before the termination of the project, a small test program was written to investigate the disk file I-O speed problems. This program read data from one file, did a small amount of computation, and then wrote data onto an output file. It wrote as many words as it read, and computed for about 50 microseconds per word. This test program was able to maintain a transfer rate, to and from the disk, of about 6K words per second. (A similar program, running alone on the real SCOPE system, could transfer about 10K words per second. Due to disk conflicts on the real SCOPE system, two such programs running simultaneously could maintain a combined rate of less than 5K words per second.) This test program was run only a few times, and gave results varying by almost a factor of 2. Due to the termination of the project, no improvements on these numbers were obtained. Hence, the figures in the following discussion are very approximate. The system CPU costs for the test program run under CAL TSS were over 70 microseconds per word. (Hence, the high CPU costs for running under CAL TSS.) These CPU costs were caused by the computation necessary to move each data block to or from the disk. (This corresponds to the computation to move a page in other systems.) This amounted to approximately 15 to 25 milliseconds per block, divided about as follows:

1/4 millisecond ECS system time on behalf of user (ECS system time spent moving data between ECS and CM, in response to user program requests)

2 milliseconds ECS to CM swap time (ECS system time spent swapping process memory between ECS and CM. Principally during disk system calls from user code, and when the process blocked waiting for disk I-O to complete.)

4 milliseconds non ECS system, system time (Time consumed by the disk system, viewed as a user program running on the ECS system.)

12 milliseconds ECS system time, on behalf of disk system (Time consumed by the ECS system in response to requests from the disk system: principally general ``book-keeping'' by the disk system, and sending disk I-O requests to the ECS system disk driver.)

The total ECS system time required to communicate with the ECS system disk I-O driver adds up to about 3 milliseconds. The rest of the ECS system time occurring on behalf of the disk system (about 9 milliseconds), must be bookkeeping overhead within the disk system itself. Other information indicates that about half of the disk system ECS system time was spent on event channel sends and receives and half on ECS file reads and writes. (We eventually expected to reduce this cost by giving the disk system direct machine instruction access to a portion of ECS, which would have reduced the ECS system time to about 6 milliseconds. See Chapter 18.) One final remark on this test: the test program called on the disk system only once per 16 blocks of data. If it had called once per block, the overheads would have probably been substantially higher. (Unfortunately, more exhaustive tests were never made, and this conclusion was never verified.) A second point where the system was slow was during user subprocess construction. This would generally occur in response to a command typed to the command processor by the user. This would result in a flurry of activity at the command processor level. First the name of the subsystem had to be looked up in a directory, rather, in a succession of directories. Then several names of files needed by the subsystem itself had to be looked up. Each of these directory references resulted in disk file actions to read the necessary information. Finally some scratch files had to be constructed for the subsystem. In sum, on a system with only one user, it generally required between 5 and 15 seconds of real time before the subsystem itself was ready to begin. (We considered installing an associative window for the directory references, but never began a serious design. It is not clear how much this would have helped.)