Very slow booting and running and braindead OS's 4543

it had lots of other issues ... very complex algorithms. when a task became runnable (say somebody doing input editing) ... the virtual pages would be read into memory from 2311 (or 2314) and written to 2301 before starting. when it finished the line-edit ... any pages on 2301 would be read into memory and written to 2311 (or 2314).

the univ. had gotten 360-67 for tss-360 ... but tss-360 only ran on weekends during test-debug sessions. then univ. got cp67 ... there were some A-B tests between tss-360 and cp67 running same fortran edit-compile-execute scripts ... tss-360 with four simulated users and cp67 with 30 simulated users.

another issue was that with the modern benefits of tss-360 one level store ... applications no longer had to worry about memory localities. compilers, applications, etc ... were laid out linearly in virtual memory. 768k real memory with a hog of tss-360 kernel taking maybe 512k ... and almost anything requiring much more than 256k to run decently.

cms remapped os-360 fortran-g ... which ran comfortably in 60k-80k.

there was a tss-360 uniprocessor (360-67, 1mbyte memory) multiprocessor (two processors, 2mbyte memory) ... where the smp test had 3.8 times the thruput of the uniprocessor on the same workload. this was written up as the tss-360 advanced algorithms being able to scale (twice) multiprocessor at better than linear (more than twice the thruput, lot of hype?). in actual fact, the uniprocessor had less than 512k memory for applications (after fixed kernel) ... while the multiprocessor had a little over 1.5mbytes for applications (after fixed kernel). since tss-360 was actually severely real-storage constrained for those environments ... having nearly four times as much real storage available for applications (between the 1mbyte uniprocessor and the 2mbyte two processor) resulted in nearly four times the thruput.

misc. past mentioning tss-360: