0000000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes: > Circa 1980 my then employer marketed a CCD SSD product which > suffered timing incompatibilities, not because of transfer rate, but > because of inter-block latencies. It appeared that some VM paging > code paths depended on completing while the inter-block gap was > passing.
re: http://www.garlic.com/~lynn/2015f.html#86 Formal definituion of Speed Matching Buffer an issue would be if you simulated 3330 .. and formated 50byte (or 110byte) dummy records and had a simulated rotational spin rate much faster than 3330 (it wasn't vm code paths, it was speed of chained CCW channel processing). I periodically mention getting to play disk engineer in bldgs 14&15 (sometimes they demanded I play disk engineer) ... past posts http://www.garlic.com/~lynn/subtopic.html#disk vm370 formated 3330s for paging so records were aligned on each track ... three 4kbyte pages per track ... and if there were queued requests for records on same cylinder but different tracks would attempt to optimize single channel program to transfer all pages in the minimum number of revolutions. For CKD this would require seek head, search, tic, read/write ... and in order to allow the channel time to execute the CCWs while the disk was spinning, page area formating inserted dummy records between page data records. It turns out that channel specs (worst case 370) required 110byte dummy records given the 3330 rotational spin rate ... to allow channel time to process the CCWs (to do a head switch) ... but track size only had room for 50byte dummy records. I did a test program that was run on 145, 148, 4341, 158, 168, 303x with IBM disk controllers and various non-IBM disk controllers. IBM disk controller could actually process the head switch CCWs with 50-byte dummy record (w/o additional revolution), for most machines except 158 & all 303x ... and some number of non-IBM disk controllers could do the switch even with 158 & 303x (the issue is that for all models of 303x, they used external channel director ... which was actually a 158 engine with the slow integrated channel microcode and w/o the 370 microcode). 3081 channels also had problem doing CCW head-switch within the 50byte dummy record window. past posts on the subject http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2001j.html#3 YKYGOW... http://www.garlic.com/~lynn/2002b.html#17 index searching http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore http://www.garlic.com/~lynn/2004d.html#64 System/360 40 years old today http://www.garlic.com/~lynn/2004d.html#65 System/360 40 years old today http://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today http://www.garlic.com/~lynn/2005p.html#38 storage key question http://www.garlic.com/~lynn/2005s.html#22 MVCIN instruction http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2008l.html#83 old 370 info http://www.garlic.com/~lynn/2011.html#65 Speed of Old Hard Disks http://www.garlic.com/~lynn/2013e.html#61 32760? http://www.garlic.com/~lynn/2014k.html#26 1950: Northrop's Digital Differential Analyzer There was a different issue with code paths on 3880 controller. After FS death, there was mad rush to get stuff back into 370 product pipelines (during FS period, internal politics had been killing off 370 efforts) and 303x and 370-xa were kicked off in parallel. 370-xa became none as "811" for the Nov1978 date on most of the architecture documents. When I saw SSCH, I thot that it was mostly to compensate for the enormous interrupt pathlength in MVS. A big problem was that as devices became faster, and load increased, there was significant increasing device idle time while MVS went thru interrupt & redrive overhead. Earlier, the disk engineering lab had been testing using prescheduled, stand-alone mainframe dedicated test time ... at one point they had tried to use MVS ... but found it had 15min MTBF (requiring manual re-ipl) in that environment. I volunteered to rewrite I/O supervisor so it was bullet-proof and never fail so that any number of on-demand, concurrent testing could go on (vastly increasing productivity). I also setout to demonstrate the optimal interrupt processing and queued request device redrive. some bean counter had dictated that 3880 use a really slow control processor (compared to 3830) and used dedicated circuits to get 3mbyte/sec transfer rate. The slow control processor showed up in increased channel and controller busy as well as increase elapsed time for channel program processing. To pass product acceptance test (requiring 3880 appear to be within 5% of 3830 performance), they would signal channel program complete (CE+DE) early ... before having actually finished everything. The first time they put 3880 controller into use with 16 3330s (and heavy load on 3033) replacing 3830 ... throughput dropped almost in half. They had assumed that they could signal complete and actually finish while software was executing interrupt and redrive pathlength. However, my superfast redrive pathlength was hitting the 3880 while it was still busy ... and as a result it was forced to signal CC1, csw-stored with SM+BUSY to the SIOF. Then later it would signal CUE interrupt when it had actually finished. This was significantly driving up overhead and latency (compared to 3830 controller). Fortunately this was still six months before first-customer ship and there was some time to do some compensation for the slow 3880 processor. However, they still had increased channel busy ... compared to what the 3090 engineers had been assuming with something that was effectively 3830 3mbyte performance. 3090 had to compensate for the increased 3880 channel busy by doubling the number of channels in configuration ... which required an extra TCM, which increased 3090 manufacturing costs (there was joke about 3090 billing the bean counter for each additional 3090 TCM). Marketing also had to spin the vastly increased number of channels as demonstrating the significant 3090 I/O power (when it was actually a problem with really slow 3880 disk controllers). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
