The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Winalski <paul.winalski@gmail.com>
To: "Greg 'groggy' Lehey" <grog@lemis.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] Old mainframe I/O speed (was: core)
Date: Wed, 20 Jun 2018 12:33:05 -0400	[thread overview]
Message-ID: <CABH=_VReMmH1Smkb8aZnuFZh2Dct7E-d0X_KxwdHWicWaz42vg@mail.gmail.com> (raw)
In-Reply-To: <20180620081032.GF28267@eureka.lemis.com>

On 6/20/18, Greg 'groggy' Lehey <grog@lemis.com> wrote:
>
> Looking at something like the IBM 370 series (mid-1970s), I/O was
> performed by the channels, effectively separate processors with a very
> limited instruction set.  Others, like the UNIVAC 1100 series, could
> perform I/O directly or via separate processors.  This was similar on
> the /360, but very different on the 1401.

All of the System/360 series except the model 25 used separate channel
processors to perform I/O.  Once the I/O was initiated, the channel
performed data transfer to and from main storage (IBM didn't use the
term "memory") completely independently from the CPU.  The S/360 model
25 was the last of the 360 series and was really a 16-bit minicomputer
microprogrammed to execute the S/360 instruction set.  It had what
they called "integrated channels", meaning that I/O was handled by CPU
microcode.

IBM used the model 25 I/O design in the S/370 models 135 and 145.  The
models 115 and 125 were actually four 16-bit processors on a bus along
with main memory.  One of them, the service processor, handled system
power-on, power-off, microcode load, diagnostics, and the system
console (a modified 3277 transaction terminal).  One was the CPU and
executed the S/370 instruction set in microcode.  The remaining two
processors acted as a byte and block multiplexer channel.  This meant
that I/O proceeded independently from the CPU, as with the old 360s.
It also meant that if the system was reading cards, punching cards,
and printing all at the same time (often the case when spooling), a
model 125 outperformed a 145 in compute speed, because the 145 had to
execute a microcode loop for every byte of I/O.

The 158 and 168 appear to have had independent channels, but housed in
the same boxes as the CPU as opposed to stand-alone units as with
S/360.

-Paul W.

  reply	other threads:[~2018-06-20 16:33 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15 15:25 [TUHS] core Noel Chiappa
2018-06-15 23:05 ` Dave Horsfall
2018-06-15 23:22   ` Lyndon Nerenberg
2018-06-16  6:36     ` Dave Horsfall
2018-06-16 19:07       ` Clem Cole
2018-06-18  9:25         ` Tim Bradshaw
2018-06-19 20:45           ` Peter Jeremy
2018-06-19 22:55             ` David Arnold
2018-06-20  5:04               ` Peter Jeremy
2018-06-20  5:41                 ` Warner Losh
2018-06-20  8:10                   ` [TUHS] Old mainframe I/O speed (was: core) Greg 'groggy' Lehey
2018-06-20 16:33                     ` Paul Winalski [this message]
2018-06-21  3:05                       ` Peter Jeremy
2018-06-21 14:00                         ` Paul Winalski
2018-06-21 14:49                           ` Arrigo Triulzi
2018-06-21 20:39                             ` Paul Winalski
2018-06-22  5:32                               ` Erik E. Fair
2018-06-22 13:32                                 ` Clem Cole
2018-06-23  6:08                             ` Dave Horsfall
2018-06-23 17:02                               ` ron minnich
2018-06-22 13:11 Noel Chiappa
2018-06-22 17:49 ` Erik E. Fair
     [not found] <mailman.1.1529690481.3725.tuhs@minnie.tuhs.org>
2018-06-23 10:32 ` Johnny Billquist
2018-06-23 11:39   ` Clem cole
2018-06-24  7:50   ` Mutiny
2018-06-27 13:59     ` Clem Cole
2018-06-24  3:14 Norman Wilson
2018-06-24 13:03 ` Paul Winalski
2018-06-24 14:41   ` Lawrence Stewart
2018-06-24 15:47     ` Arthur Krewat
2018-06-24 18:49 Norman Wilson
2018-06-24 18:49 Norman Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABH=_VReMmH1Smkb8aZnuFZh2Dct7E-d0X_KxwdHWicWaz42vg@mail.gmail.com' \
    --to=paul.winalski@gmail.com \
    --cc=grog@lemis.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).