Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Newsgroups | comp.arch |
| Subject | Re: 'smttter IBMdroids |
| Date | 2011-09-02 08:48 -0400 |
| Organization | Wheeler&Wheeler |
| Message-ID | <m3bov3kt4v.fsf@garlic.com> (permalink) |
| References | <_VB7q.3677$YA4.814@newsfe14.iad> <322fbe83-3e27-45bf-be6a-6c673f4c7ec5@er4g2000vbb.googlegroups.com> <r54067hcb735luri3r06g7l5gph7ali7mj@4ax.com> <j3q3j7$us6$1@gosset.csi.cam.ac.uk> <rg9167te58lurkh5kis219fk2fpdhg28j4@4ax.com> |
Robert Wessel <robertwessel2@yahoo.com> writes: > It somewhat depends on your definition of "properly symmetric." I/O > on the pre-XA MP systems was partitioned amongst the various CPUs (a > MP 3033 might, for example, have 24 channels, 12 on each CPU, and each > set of 12 could only be driven from the appropriate CPU*). Other > than that, the CPUs in all of the S/370 and later AP and MP features > were fully symmetrical. > > With XA I/O was further abstracted, and all CPUs could drive all > channels (although they largely stopped actually referring to channels > at that point, rather the OS drove an I/O to a device, and the > hardware would find a free channel connected to that device to use). > > > *Ignoring the channel set switching feature. *Bleech* Which, > somewhat to my amazement, has made something of a comeback with > logical channel sets... re: http://www.garlic.com/~lynn/2011k.html#82 'smttter IBMdroids http://www.garlic.com/~lynn/2011k.html#84 'smttter IBMdroids as previously mentioned, 360/67 multiprocessor support had "channel director" which allowed all processors direct access to all channels. discussed in some detail in 360/67 functional characteristics http://www.bitsavers.org/pdf/ibm/360/funcChar/GA27-2719-2_360-67_funcChar.pdf by comparison 360/65MP and all 370 MPs had processor specific channels ... and "symmetric" multiprocessor I/O was simulated by having pairs of processor specifical channels connected to same "twin-tailed" device controller. as mention in previous posts all 303x channels were actually the 370/158 engine running integrated channel microcode ... it was called a "channel director" ... but totally different from 360/67 multiprocessor channel director. The 370/158 integrated channel microcode supported six channels. So a 12 channel 3033 required two 370/158 engines (channel directors). A 16 channel 3033 required three 370/158 engines (with two channel unused). A 24 channel 3033mp required four 370/158 engines ... two attached/dedicated to each processor (for 12 channels each). a big part of XA I/O was horribly long I/O path in the MVS supervisor. High-performace disk I/O was starting to hit brickwall in MVS systems because of long device I/O redrive latency. I/O queues were managed in the software ... and there was long (and increasing) synchronous latency delay between the time that a device I/O completed and the time MVS could get the next I/O started. A big part of XA I/O was to mask this synchronous delay latency that was becoming a larger & larger throughput bottleneck ... by moving the queue in the hardware ... allowing the hardware to immediately redrive the device. I mention in this post having designed something similar during 1975 for 5-way 370 SMP effort in conjunction with some POK engineers ... well before work started on XA: http://www.garlic.com/~lynn/2011k.html#79 Selectric Typewriter--50th Anniversary other past posts mentioning 370 5-way 370 (canceled before announced or shipped) http://www.garlic.com/~lynn/submain.html#bounce After transferring to san jose research ... they let me wander around disk engineering on san jose plant site and play disk engineer. bldgs. 14&15 had computer rooms for testing development devices. The processors were being scheduled "stand-alone" dedicated time, 7x24 around the clock for each individual device testing. At one point they attempted to bring the processors with MVS so that on-demand, concurrent testing could go on ... but found that MVS had 15min MTBF (between hangs and/or failures requiring reboot), even with only single device testing. I offerred to do rewrite of the I/Os subsystem so that it was bullet proof and never hanged or failed ... providing engineering development with significantly increased productivity ... on-demand, concurrent testing of any number of devices. misc. past posts getting to play disk engineer http://www.garlic.com/~lynn/subtopic.html#disk As definition of XA I/O was maturing ... one of the demo things I tried to do with the I/O subsystem rewrite was to see how close I could come to XA I/O redrive throughput with simple 370 programming (highly optimized pathlength for interrupt handling indicating the end of previous i/o and being able to redrive the device with the next queued i/o). Another thing that XA I/O tried to move into hardware was "dynamic pathing" ... for configurations where same system would have multiple channels connected to the same controller (for parallel I/O activity) ... and allowing the hardware to choose the first available channel path to get to device. Up until then most systems had implemented (software) primary and alternate channel pathing (to same set of devices). I did I/O subsystem software rewrite to do load-balancing use of multiple channel paths ... and it failed miserably. It turns out that the new generation of high-performance disk controllers 3880 ... for new generation of 3380 disks ... actually had very slow processor for handling commands (with separate hardware path for data transfer) ... especially compared to its predecessor 3830. The 3880 controller had enormous additional internal processing overhead and latency if it got two succesive I/O requests from different channel connections (especially compared to two successive I/O requests from the same channel connection) ... measured in milliseconds. It turns out that I could get better throughput with a primary w/alternate implementation ... compared to a load-balancing implementation (with the reduction in 3880 disk controller overhead by minimizing the number of different channels that 3880 had to deal with concurrently). Note, dynamic pathing also added a bunch of complexity in the (3380) disk controller ... as if it wasn't already slow enough and didn't already have enough to do. I provided them with a much more efficient alternative implementation for dynamic pathing ... but they said I was too late ... that their existing implementation had already been cast in concrete. misc. past posts methioning dynamic pathing: 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 http://www.garlic.com/~lynn/2009q.html#79 Now is time for banks to replace core system according to Accenture -- virtualization experience starting Jan1968, online at home since Mar1970
Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-08-31 22:15 -0400
Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-08-31 22:20 -0400
Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-31 22:31 -0400
Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-01 07:30 -0700
Re: 'smttter IBMdroids Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 09:48 -0700
Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-01 17:58 +0100
Re: 'smttter IBMdroids Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-01 10:58 -0700
Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-01 18:51 +0100
Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-01 15:42 -0400
Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-01 18:19 -0500
Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-01 20:57 -0400
Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 09:17 +0100
Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 09:19 +0100
Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 04:44 -0500
Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 11:39 +0100
Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 11:14 -0500
Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 04:47 -0500
Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 11:26 +0100
Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-02 08:48 -0400
Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-02 09:29 -0400
Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-01 17:15 -0500
Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-02 10:10 -0700
Re: innovation from Armonk, was 'smttter IBMdroids John Levine <johnl@iecc.com> - 2011-09-02 21:21 +0000
Re: innovation from Armonk, was 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 21:56 +0100
Re: innovation from Armonk, was 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-02 17:49 -0400
Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-02 18:04 -0500
Re: 'smttter IBMdroids Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-09-03 00:16 +0100
Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-03 14:25 -0400
Re: 'smttter IBMdroids Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-09-03 20:09 +0100
Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-03 22:02 -0400
Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-03 21:50 -0500
Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-03 23:52 -0400
Re: 'smttter IBMdroids "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-05 08:26 -0700
Re: 'smttter IBMdroids Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-05 11:14 -0700
Re: 'smttter IBMdroids Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-05 22:05 +0200
Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-05 17:27 -0400
Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-05 17:16 -0400
Re: 'smttter IBMdroids "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-05 14:40 -0700
Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-05 15:45 -0700
Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-06 21:47 -0500
csiph-web