eamacn...@yahoo.ca (Ted MacNEIL) writes: > From > http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/8/649/ENUSA13-0568/index.html&lang=en&request_locale=null > > A Long Time Ago in a Data Center Far, Far Away (well, OK, just down the > road from Poughkeepsie in East Fishkill), we used to routinely run at > 100% busy during peak times on some systems and for days on end on > others. So long as there was enough discretionary work to fill up the > box, no harm, no foul.
the counter-argument is from the peak z196 i/o benchmark ... getting 2M IOPS using 104 FICON ... some past refs http://www.garlic.com/~lynn/submisc.html#ficon the documentation is that the 14 SAPs run 100% at 2.2M SSCH/sec ... but the recommendation is to keep SAPs no more than 70% busy ... aka 1.5M SSCH/sec. The SSCH was part of the original XA extensions to 370 ... with 3081. There were two issues: 1) the horrendous MVS pathlength to handle an interrupt and redrive the device with queued request (as I/O was getting faster & quicker ... the idle "redrive" latency was becoming significant factor in limitating aggregate I/O throughput) and 2) asynchronous I/O interrupt handling was having horrible effects on cache hit rations. SSCH would offload lots of MVS redrive pathlength as well as providing queued interface that helped mitigate asynchronous interrupt cache effects. I've mentioned before getting to play disk engineer in bldgs 14&15 (disk enginneering and product test) .... http://www.garlic.com/~lynn/subtopic.html#disk one of the issues was that they were running stand-alone testing on variety of mainframes pre-scheduled 7x24 (around the clock). At one point they had tried MVS for concurrent testing ... but found MVS had 15min MTBF in that environment ... even with only a single test device. I then rewrote I/O supervisor to make it bullet proof and never fail ... so they could do on-demand, concurrent testing with any number of devices (and not have to have lag time with pre-schedule). This was about the same time that all the work was first going on with SSCH ... in large part trying to compensate for the horrendous MVS pathlength for device redrive latency ... and so for the fun of it, in addition to I/O supervisor never fail and bullet proof, I also worked on trying to make standard 370 pathlength for device redrive latency as close to zero as possible. Now with SSCH ... some amount of the MVS queueing problems when running 100% busy have been offloaded to dedicated processors ... but still haven't been done away with altogether. -- 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
