Mainframe Channel Redrive
Mainframe Channel Redrive
some follow-on?to my 1jan2023 11:23 comment to (usenet) comp.arch post
As disks got faster, (operating system) "I/O redrive" latency increasingly became larger part (idle from end of I/O operation interrupt to starting the next queued I/O). The 3880 disk controller was replacing 3830 disk controller. While 3880 increased data transfer support to 3mbyte/sec, the controller CPU was significantly slower (than 3830) ... the controller I/O command processing startup and ending took much longer (older 3330 disk with 3830 had higher throughput than with 3880 controller). They tried a gimmick where then would reflect end-of-IO interrupt when data transfer ended but before command processing was actually finished (assuming that the controller could finish command termination processing overlapped with system interrupt and device driver redrive handling).
I've mentioned several times that in the morph from CP67->VM370, they dropped and/or simplified a lot of features (including my dynamic adaptive resource management from undergraduate days and SMP, tightly-coupled multiprocessor support). One of my hobbies after joining IBM was enhanced production operating systems for internal datacenters and I spent much of 1974 and 1975 adding CP67 stuff back into VM370 (for "CSC/VM"). One of the things I didn't get around to adding back in was CP67 "CHFREE" which was located in I/O interrupt handling path ... that as soon as necessary interrupt handling stuff was finished (like was there a unit check error), invoke I/O redrive (a couple hundred instructions to redrive instead of a couple thousand). For the disk engineering input/output supervisor rewrite (making it bullet proof and never fail), so they could do development/prototype ondemand, concurrent testing (instead of scheduled, stand-alone testing), I put CHFREE back in (not so much for disk engineering, but for production operation systems, had transferred to SJR and CSC/VM became SJR/VM for internal distribution). I've claimed that major motivation for adding SSCH in 370/XA ... was the enormous MVS redrive latency ... and they could put pending queued requests (for asynchronous redrive) down into the "hardware".
old archived email:
领英推荐
I've told the story that trout/3090 had initially configured number of channels to achieve target aggregate system throughput (based on assumption 3830->3880 just improved transfer rate to 3mbyte/sec). While 3880 tweaks somewhat masked the significantly slower 3880 processor ... the total channel busy was significantly worse than a their assumption about 3880 being a 3830 with support for (3380) 3mbyte/sec transfer rate. When they realized how bad the 3880 channel busy was going to be, they realized they would have to significantly increase the number of channels (to achieve desired system throughput). The increase in number of channels then required an additional TCM, there was joke that 3090 was going to bill the 3880 group for the increase in 3090 manufacturing cost. IBM marketing eventually respun the increase in number of 3090 channels to the 3090 being a wonderful I/O machine (rather than counter to the significant increase for 3880 controller channel busy overhead).
Something analogous also shows up later in (IBM mainframe) z196 "peak I/O" benchmark requiring 104 "FICON" (running over 104 FCS) to get 2M IOPS (where single native FCS claiming over million IOPS each)
This is analogous to the early 70s decision to make all 370s virtual memory. Basically MVT storage management was so bad that region execution sizes had to be specified four times larger than actually used. As a result a typical 1mbyte, 370/165 would only run four concurrently executing regions ... insufficient to keep machine busy and justified. Remapping MVT into 16mbyte virtual memory would allow increasing the number of concurrently executing regions by factor of four times with little or no paging.
z/VM 50th ... virtual memory and some ref. to concurrent activity to keep processor sufficiently utilized
Retired at Retired
2 年other 60s processor/disk trivia, as undergraduate in the 60s, I had done dynamic adaptive resource management and what I called "scheduling to the bottleneck" (dynamically identifying resource throughput bottlenecks). I've commented that original 360 CKD ... and "multi-track search", traded off abundant I/O capacity for relatively constrained processor and real memory ... however by the mid-70s that trade-off was beginning to invert. In the early 80s, I had written a tome that disk "relative system throughput" had declined by an order of magnitude (factor of ten times) since the 60s ... aka disk throughput had increased 3-5 times while processor speed and real storage size had increased by 40-50 times. A GPD (disk division) took exception and assigned the division performance group to refute my claim. After a couple weeks, they basically said that I had slightly understated the problem. They then respun the analysis for a (mainframe user group) SHARE presentation on configuring disks for improved system throughput (SHARE 63, B874, 16Aug1984).