IBM 610 workstation computer 3423

the issue on the 370-195 in bldg. 28 was that unless you had special priority ... the normal job end backlog ... was in fact, 3 months (even if all the pending jobs executed at peak 370-195 thruput). the 370-195 service in bldg. 28 also had operational stuff to catch individuals and-or organizations having multiple instances of the same work concurrently submitted ... as an attempt to reduce their turn-around latency (frequently seen in student university environments and there usually are countermeasures developed to handle the situation).

there is a separate issue with concurrently executing jobs ... typically used in interactive environments and-or batch enviornments where no specific job was processor bound, processor was the most expensive resource in the system, and the system was optimized to maximum processor utilization.

the issue with the pasc job was that it would only run for a couple hrs ... but the workload backlog on the 370-195, was in fact, 3months (at least for the job priority given their workload). some other workload might get higher priority and more frequently turn-around. note this was effectively three months turn-around before it even started the job (much more FIFO than any round-robin). i've posted before about the air-bearing simulation job that was getting something like one week turnaround from the bldg. 28 370-195 service (instead of 3 month turn around) ... which was part of the effort that went into designing the thin-film floating heads for 3380 (and possibly considered higher priority to get out the thin-film floating disk head design).

now in the various concurrent workload scenarios ... like the 370-145 machine installed at pasc for providing interactive computing vm-cms service ... the scheduler started out basically being a combination of priority and round-robin. the original scheduler on cp67 that i saw (possibly adapted from ctss) was a ten level priority scheduler. certain type of events would reset a task (or a brand new task) and place it at the best priority with very short cpu time-slice (multiple tasks at the same level were handled fifo). once the task had executed for the very short cpu time-slice it was bumped down to the next level scheduling level (where it would get a slightly larger cpu time-slice but scheduled for end behind any processes at higher level). concurrent, time-slice workload that required any amount of cpu resources, quickly filtered thru all ten levels to the bottom level ... where most of the long-running, concurrent processor intensive tasks found themsleves ... and they would be executed in round-robin fashion with cpu time-slice on the order of a second or so. if higher priority workload showed up, it could pre-empt workload running at lower scheduling priority.

as the number of concurrent tasks and workload increased in normal cp67 service ... this ten level dispatcher maintenance overhead was starting to consume something like 10-15% of total elapsed time. it also suffered from not having any sort of page thrashing control overhead. one of the people at lincoln labs, then replace the ten-level dispatcher with a much simpler two-level dispatcher that included very rudimentary page-trashing controls. the operation between the two queues were similar to the ten-level dispatcher ... basically high-priority, short time-slice, fifo queue and then quickly drop into bottom queue and effectively round-robin.

i then rewrote all this stuff and created the original fair-share dispatcher. it basically calculated advisory deadline based on things like recent resource consumptioin and the size of the allocated time-slice.

i also rewrote the page thrashing control to estimate real storage requirements of each task (the rudimentary page-thrashing code put in by lincoln labs. just placed an arbitrary limit on the total number of concurrent tasks in the dispatch queue w-o actually tracking their real storage requirements).

note that this was in the same era that there was publication in the technical literature about working sets and working set dispatcher. as previously mentioned, 10-15 yrs later there was a conflict when somebody was publishing a stanford phd thesis on technology very similar to the work that i had done nearly 15 years earlier (and also contridicted the technical literature that had been published at the time i did my original work). there was a major effort to not allow that the phd be granted on the work (and the thesis be published). one of the contributions that help break the deadlock was that there was an implementation done on cp-67 running on identical hardware of the working set dispatcher ... and you could have direct A:B comparison between my implementation and an implementation that faithfully reproduced what was in the technical literature.

so in the morphing from cp67 to vm370, much of the code that i had done as an undergraduate got dropped. somewhat because of that, there were some lobbying via various customers (in places like SHARE and other user group organizations) to have my code put back into the product. that was finally approved and I got to ship the "resource manager" .... coming up on 30 year anniv. in a couple months. It had pretty much the same dynamic adaptive resource management, advistory deadline scheduling, real-storage and page thrashing controls, etc. One of the things that I was able to add was an additional, somewhat more, background dispatching queue that was much more FIFO than round-robin. I even did a write-up on the effects of having things like ten identical tasks-jobs that would nominally run for several minutes. The resource manager write-up was something along the line that if I had ten concurrent tasks each requiring six minutes and executed round-robin ... then it would take nearly an hour for all ten to complete. The avg. completion time then is one hour. However, if i ran the same workload FIFO, the first task could complete after six months ... and only one would take the full hour (with the avg. completion time a little over 30 minutes instead of 60 minutes).

in any case, PASC had a choice between their in-house 370-145 and the bldg. 28 370-195. the 370-145 was installed to supply interactive computing for science center members that primarily worked 1st shift. as a result, the machine was otherwise idle much of 2nd shift, nearly all of 3rd shift, and nearly all of the weekends. The 370-195 workload was effectively run FIFO and the PASC turn-around still was 3 months.

now the 370-195 had another issue. most normal codes, unless specifically optimized for 195 pipeline ... ran about 50percent peak instruction thruput. somewhere along the way, there was a project that I got pulled in that was working on effectively hyperthreading for the 195. it involved created a second PSW (instruction counter) and registers and misc. other stuff ... providing dual i-stream support ... emulating a two-process smp. The pipeline stayed the same and the number of functional units stayed the same ... but all the work in the pipeline was tagged with an one-bit instruction stream flag (indicating which instruction stream that instructions and registers were buttociated with). this effort never shipped any hardware to customers. the idea with the dual i-stream was that if most normal codes could only keep the pipeline half busy ... then having a pair of i-streams might be able to maintain peak aggregate thruput.

misc. past posts mentioning bldg. 28 370-195 service and air-bearing simulation job

misc. past posts mentioning the stanford clock phd thesis incident:

misc. past posts mentioning dual i-stream work

--