The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[email protected] (Ivan Warren) writes: > Hmphhh.. > > In the dept of "other possible ways by the hardware to damage > performance when preventing I/O queue processing" - in the line of the > 3380 presenting early CE... > > That's probably what drove the 4381 folks (or maybe it was you !) to > do this SIOFQ (Start I/O Fast Queuing) thingy (dunno if any other > model had it - but I know I had it on my 4381 back then). > > All in all, not a bad idea. When the channel encounters a CU or > Channel Busy condition - by a SIOF issued Op - either because the CU > isn't ready to accept the request just yet or the channel is > performing some burst operation - (but not a Device Busy or CC=2 which > doesn't even go to the channel anyway) - The channel hardware would > queue the I/O request - > thus freeing the CPU from going into a dequeue/SIOF frenzy (remember > also that because it's a SIOF, you (may) get an extra interrupt to > present you with a deferred CC) > > Nice.. Unless if you had a 2-channel-switch on a 3880 with 2 Storage > Directors. Because then, the supervisor would never attempt to start > the I/O on the other side (since a SIOF with SIOFQ enabled would never > make the CPU aware of the situation). Thus, I/O would almost always be > queued on the 1st path - and almost never presented on the 2nd path. > > On my installation, where I was running VM/SP5 with HPO, disabling > SIOFQ led to a *significant* increase in I/O throughput (with no > significant CPU overhead.. processing an I/O interrupt, dequeuing and > re-starting an I/O in CP has quite a short path length.. maybe 200 or > 300 instructions overall - at least for an I/O for which the > hypervisor has complete responsibility (paging, mdisk, spool)). > > Of course, XA made all this go away since the Channel Subsystem is > then made responsible for initiating the I/O on an available CHPID - > if more than 1 path is available and the initial path is found to be > unavailable to perform the requested operation. > > OTOH, this makes me dreamy about all the "multipathing" enhancements > available on today's "distributed" systems - like - Ohhh ! Shiny ! > (with Jazz Hands) - when this is something that has been available > probably since the mid 70's (program controlled) and since the early > 80's (hardware controlled) on mainframes. re: http://www.garlic.com/~lynn/2009q.html#74 Now is time for banks to replace core system according to Accenture sio was synchronous all the way out to the device and back ... as the processors got faster ... the round-trip latency was starting to represent large number of processor instructions. so (370) siof didn't wait ... just continued on ... and various conditions that might have shown as SIO condition code ... then had to be persented as deferred interrupt. when i redid the i/o supervisor for the disk engineering lab ... to make it bullet proof and never fail ... i simplified a lot of spegetti code that had evolved over a number of years. one of the things was the gorp that purported to be multi-path operation. I could do the original primary with alternates ... but could also do load balancing (cleaning up the code resulted in much less code, much shorter pathlengths, and perform more function) the 3830 to 3880 went from a fast horizontal microcode engine to special data transfer hardware path and a slow vertical microcode engine (jib-prime). the described problem with with presenting early termination with ongoing completion (attempting to mask slowness of processing) ... another problem was it was really, really slow if the 3880 ever had to switch channel paths (i mean, really, really slow involving all sorts of extra 3880 computation; couldn't do much about this if multipath for loosely-couple operation); the net was that it was almost never beneficial to use an alternate path to a 3880 if the primary was busy (and stuff like dynamic path load balancing was an especially bad idea). related past posts mentioning various dynamic pathing stuff: http://www.garlic.com/~lynn/2006d.html#3 Hercules 3.04 announcement http://www.garlic.com/~lynn/2006d.html#15 Hercules 3.04 announcement http://www.garlic.com/~lynn/2007h.html#9 21st Century ISA goals? http://www.garlic.com/~lynn/2007i.html#33 Internal DASD Pathing http://www.garlic.com/~lynn/2008d.html#52 Throwaway cores there was joke about the slowness of 3880 operations significantly increasing channel busy ... to the point that 3090 had to up the standard number of channels in configurations ... and the processor division then wanted to bill the 3880 group for the manufacturing costs for the extra channels. circa 1980 there was start of program to replace the large number of different internal microprocessors with common 801/risc processors; the s/38 followon, as/400 was going to use 801, the 4341 followon was going to use 801 ... bunch of other microprocessor efforts around the company was going to converge to 801. The various 801 "Iliad" processors ran into some issues ... so as/400 had crash program to do custom CISC instead. Note that a decade later, as/400 did go with 801/risc (or a flavor of 801/risc descendant, power/pc). I helped with position paper that 4341 followon (4381) should be custom CISC ... i.e. chip technology was getting to point where it was becomming possible to do much of 370 in circuits ... instead of microcode on top of some other processor architecture ... but i didn't have a whole lot else to do with 4381. bits of that paper reproduced here: http://www.garlic.com/~lynn/2006r.html#27 A Day For Surprises (Astounding Itanium Tricks) misc. old email related to 801/risc http://www.garlic.com/~lynn/lhwemail.html#801 misc. past posts mentioning risc, rios, iliad, 801, romp, fort knox, power, power/pc, somerset, etc http://www.garlic.com/~lynn/subtopic.html#801 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
