Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch > #3371

Re: 'smttter IBMdroids

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>

Show all headers | View raw


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


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