CPU time and system load
breastle screen for HLA Adventure Need help designing one
Those would usually be the "Shift Out" 1 and "Shift In" 2 codes. If implemented on a terminal, they will exchange the glyphs in code positions 33...126 for another set of glyphs...
in the pr-sm, lpar, etc ... it tends to be the ratio of instructions that involve overhead ... to all instructions. in low utilization environment, a large part of the end tends to be in the kernel, which has a higher ratio of instructions w-overhead. A BR15 loop could be considered notorious for instruction that has no hypervisor overhead.
the univ. that i was at ... got cp67 installed the last week in jan. 68 ... and i got to attend the march '68 share meeting in houston for the cp67 announcement. then at the aug. '68 share meeting in boston ... i got to present a talk on mft14 enhancements as well as cp67 enhancements.
the workload at the univ. was lots of short jobs (before watfor) and was primarily job scheduler. i had done a lot of i-o tuning on mft14 to make thruput of this job mix nearly three times faster (12.7secs per 3-step job vis-a-vis over 30 seconds elapsed time for out-of-the-box mft14) essentially the same number of instructions executing in close to 1-3rd time ... because of drastically optimized disk and i-o performance).
I had also rewritten a lot of the cp67 kernel between jan. and the boston share meeting to drastically reduce hypervisor overhead for high overhead instructions-operations.
In the boston talk, i have the ratio of elapsed time w-hypervisor to elasped w-o hypervisor for mft14 job stream. Using these statistics, a normal, out-of-the-box mft14 looked much better running in a hypervisor environment. improving basic elapsed time by a factor of nearly 3 times by optimizing i-o made the hypervisor ratio much worse. Basically there was no increase in hypervisor overhead time for i-o wait. Drastically cutting i-o wait made the hypervisor overhead time ratio much worse (amount of overhead stayed the same but occured in much shorter elapsed time).
The obtimized MFT14 jobstream ran in 322sec elapsed time on bare machine and in 856sec elapsed time under unmodified cp67 (534secs of cp67 hypervisor cpu overhead). With a little bit of work part time (I was still undergraduate and also responsible for the MFT14 production system), I got this reduced to 435secs elapsed time (113secs of cp67 hypervisor cpu overhead vis-a-vis the original 534 seconds of cp67 cpu overhead).
part of talk from boston '68 share presentation http:-www.garlic.com-~lynn-94.html#18 CP-67 & OS MFT14
a couple overheadsfrom above:
OS Performance Studies With CP-67
OS MFT 14, OS nucleus with 100 entry trace table, 105 record in-core job queue, default IBM in-core modules, nucleus total size 82k, job scheduler 100k.
HASP 118k Hasp with 1-3 2314 track buffering
Job Stream 25 FORTG compiles
Another Another One Bites the Dust
long ago and far away .... the dasd engineering lab (bldg 14) and dasd product test lab (bldg 15) had these "testcells" where tested stuff under development. that had some number of processes that...
Bare machine Time to run: 322 sec. (12.9 sec-job) times Time to run just JCL for above: 292 sec. (11.7 sec-job)
Orig. CP-67 Time to run: 856 sec. (34.2 sec-job) times Time to run just JCL for above: 787 sec. (31.5 sec-job)
Ratio CP-67 to bare machine
2.65 Run FORTG compiles 2.7 to run just JCL 2.2 Total time less JCL time
.... footnote for above overhead
1 user, OS on with all of core available less CP-67 program.
breastle screen for HLA Adventure Need help designing one 849
Jukka Aho UNICODE is completely identical to ASCII for the first 127 character positions...which, yes, means that it's all "control codes" up to 20h (space...
Note: No jobs run with the original CP-67 had ratio times higher than the job scheduler. For example, the same 25 jobs were run under WATFOR, where they were compiled and executed. Bare machine time was 20 secs., CP-67 time was 44 sec. or a ratio of 2.2. Subtracting 11.7 sec. for bare machine time and 31.5 for CP-67 time, a ratio for WATFOR less job scheduler time was 1.5.
I hand built the OS MFT system with careful ordering of cards in the stage-two sysgen to optimize placement of data sets, and members in SYS1.LINKLIB and SYS1.SVCLIB.
.... summary of some of the CP-67 optimization work during the spring and summer of '68
OS run with one other user. The other user was not active, was just available to control amount of core used by OS. The following table gives core available to OS, end time and end time ratio for the 25 FORTG compiles.
CORE (pages) OS with Hasp OS w-o HASP
104 1.35 (435 sec) 94 1.37 (445 sec) 74 1.38 (450 sec) 1.49 (480 sec) 64 1.89 (610 sec) 1.49 (480 sec) 54 2.32 (750 sec) 1.81 (585 sec) 44 4.53 (1450 sec) 1.96 (630 sec)