z/VM 50th - part 7
z/VM 50th - part 7
IBM System/370
Melinda's virtual memory, 360/67, cp67, vm370 history
TSS/360 was "official" for 360/67, single-level store which tended to rely on 4k page faults for everything ... and the later (failed) Future System tended to use the same design ... lack of overlapped data transfers cut throughput. I continued to work on 360/370 all during the FS period and would periodically ridicule them ... which wasn't a career enhancing activity. I also would claim that when I was doing paged mapped filesystem for CP67/CMS, I had learned what not to do from TSS/360. FS was totally different from 370 and was going to completely replace it (internal politics were shutting down 370 during FS and the lack of new 370 stuff is credited with giving 370 system clone makers their market foothold). When FS implodes there is mad rush to get stuff back into the 370 product pipelines, including kicking off the quick&dirty 3033&3081 efforts in parallel, more info:
A 3031 was two 158 engines, one with just the 370 microcode and a 2nd with just the integrated channel microcode. A 3032, was 168 reworked to use the 303x channel director (158 engine with just the integrated channel microcode) for external channels. A 3033 started out 168 logic remapped to 20% faster chips.
Initially, 308x was going to be multiprocessor "only" machines. However, ACP/TPF (airline control program) didn't have multiprocessor support and there was concern that whole market would move to Amdahl (Amdahl single processor was about same MIP as aggregate of two processor 3081 ... and higher throughput because of no multiprocessor software overhead, a two processor Amdahl had higher throughput than four processor 3084, two 3081s lashed together). Eventually a 3083 is shipped, basically a 3081 with one of the processors removed.
165 had 2mic main memory, for 168 it was 400-something ms (similar for 155->158). Also high-end 15x/16x were horizontal microcode machines which measured 370 instructions in avg machine cycles/instruction (compared to low/mid range 370 which were vertical microcode ... avg. 10 native instructions/370 instruction ... sort of like implemented 370 simulator on i86 machines). 165 avg. 2.1 machine cycles/370 instruction ... for 168, besides 4-5 times faster main memory, microcode was optimized to get 1.6 machine cycles/370 instruction. 3033 which started out remapping 168 logic to 20% faster chips ... also further optimized microcode and got it down to avg of one machine cycle per 370 instruction (aka, horizontal microcode could activate several hardware units overlapped with other operations, individual instructions could take longer than one cycle, but there would be an avg. of one instruction completing every cycle)
A decade ago, I was asked to track down decision to have all 370s running with virtual memory. I found staff member reporting to exec that made the decision. Basically MVT storage management was so bad that region sizes typically had to be specified four times larger than actually used ... as result a 1mbyte 370/165 would usually only be able to run four concurrent regions ... insufficient to keep machine busy (and justified). Going to VS2/SVS (similar to running MVT in CP67 16mbyte virtual machine) allowed number of regions to be increased by four times with little or no paging. Pieces of email exchange about adding virtual memory to all 370s (and some other subjects)
165 engineers were then complaining that if they had to implement the full 370 virtual memory architecture, virtual memory announce would have to slip six months. Then features were dropped to help keep the original schedule ... and other models (and any software written for dropped features) would have to retreat to the virtual memory subset.
trivia: not long after joining IBM, the 370/195 engineers con'ed me nto helping with two thread (simulating multiprocessor) 370/195 .... see the death of ACS/360 (executives killed it because it might advance the state of the art too fast and IBM might loose control of the market), which has reference to multithreading patent (also refs to some features that show up more than 20yrs later with ES/9000):
however, the multithreaded 370/195 was killed when it was decided to make all 370s virtual memory (and it wasn't practical to try and add virtual memory to 195). Multithreaded was justified because conditional branches drained the pipeline so most conventional codes only ran at half speed (it was felt two threads running at half speed could fully utilize the machine, modulo the MVT multiprocessor software overhead) ... however 195 half speed was still faster than 3033.
It was possible to connect two /65s to one memory system to create a multi-processor system, although it was not twice as fast as a single CPU, due to memory interference. It did save some cost as you did not have to duplicate memory and peripherals. A special version of the OS/MVT system called MP65 was developed for the dual processor system, but a lot of installations used it on a single processor because it had enhanced error recovery. The /65 was rated over 600 K IPS.
bitsavers ibm 360:
领英推荐
158 & 168 multiprocessor had processor cycle slowed down by 10% to allow for cross-cache memory consistency protocol chatter, i.e. 1.8 times a single processor (2*.9). MVS/370 multiprocessor documented throughput of 1.2-1.5 a single processor (taking into account the MVS multiprocessor software overhead).
bitsavers ibm 370
and
other recent linkedin articles
Retired at Retired
1 年https://www.dhirubhai.net/pulse/john-boyd-ibm-wild-ducks-lynn-wheeler/ https://www.dhirubhai.net/pulse/boyd-ibm-wild-duck-discussion-lynn-wheeler/ https://www.dhirubhai.net/pulse/ibm-breakup-lynn-wheeler/ https://www.dhirubhai.net/pulse/ibm-downfall-lynn-wheeler/ https://www.dhirubhai.net/pulse/ibm-controlling-market-lynn-wheeler/ https://www.dhirubhai.net/pulse/zvm-50th-lynn-wheeler/ https://www.dhirubhai.net/pulse/zvm-50th-part-2-lynn-wheeler/ https://www.dhirubhai.net/pulse/zvm-50th-part-3-lynn-wheeler/ https://www.dhirubhai.net/pulse/zvm-50th-part-4-lynn-wheeler/ https://www.dhirubhai.net/pulse/zvm-50th-part-5-lynn-wheeler/ https://www.dhirubhai.net/pulse/zvm-50th-part-6-lynn-wheeler/ https://www.dhirubhai.net/pulse/mainframe-channel-io-lynn-wheeler/ https://www.dhirubhai.net/pulse/mainframe-channel-redrive-lynn-wheeler/ https://www.dhirubhai.net/pulse/ibm4341-lynn-wheeler https://www.dhirubhai.net/pulse/memories-mosaic-lynn-wheeler/ https://www.dhirubhai.net/pulse/inventing-internet-lynn-wheeler/ https://www.dhirubhai.net/pulse/multi-modal-optimization-old-post-from-6yrs-ago-lynn-wheeler