jwgli...@gmail.com (John Gilmore) writes:
> The answer to this question is yes. z/Architecture channel-based I/O
> is very different from that used by, for example, Intel servers. In
> particular it uses many fewer cp[u] cycles, and its permits many
> independent I/O operations to be executed concurrently and
> asynchronously.
I've claimed this became a marketing myth when 3090 was forced to add a
lot more channels when they discovered how bad the 3880 disk controller
was. 3090 planned number channels assuming 3880 would have similar
channel busy overhead as 3830 controller ("feature a bug"). However, in
the move from 3830 to 3880, they went from a fast horizontal microcode
microprocessor to a slow vertical microcode microprocessor (with
separate hardware path for data transfer). The slow 3880 microprocessor
signicantly increased channel busy for disk operations ... exhacerbated
by the half-duplex bus&tag operations ... need end-to-end synchronous
turn-around for operations and the CKD dasd channel program
characteristics.
The net was 3090 had to significant increase the number of channels (to
offset the per operation 3880 channel busy overhead ... attempting to
obtain target aggregate input/output operations per second, IOPS), which
required additional TCM, which increased 3090 manufacturing costs. There
were jokes about 3090 group billing the 3880 group for the additional
3090 manufacturing costs.
for non-mainframe world, the late 80s saw a big effort to improve
thruput by moving to serial, asynchronous technology. This shows also up
with IBM Harrier (9333 which becomes SSA) in the early 90s. Basically
the equivalent of the channel program is shipped as data to the
controller. the serial dedicated write&read data paths operate
asynchronously with large number of concurrent operation (thruput tied
to media transfer rate) and none of the half-duplex end-to-end latency
overhead characteristic of ibm channels (which then necessitated the
large number of channels to compensate for the heavy operational
overhead). This includes 9333/SSA, FCS (which IBM layers FICON on top),
SCI, SATA and various other serial, asynchronous technologies. recent
posts discussing SSA (and other serial technologies)
http://www.garlic.com/~lynn/2012k.html#69 ESCON
http://www.garlic.com/~lynn/2012k.html#77 ESCON
http://www.garlic.com/~lynn/2012l.html#30 X86 server
mentioned in above SSA wiki
http://en.wikipedia.org/wiki/Serial_Storage_Architecture
and in this old post, I tried to get 9333 evolution to be
interoperable with fibre-channel
http://www.garlic.com/~lynn/95.html#13
mentions that SSA "lost out" to fiber channel ... shouldn't have been a
win/loose ... should have been interoperable
http://en.wikipedia.org/wiki/Fibre_Channel
IBM channel mythology was various technology trade-offs from the 60s,
channels had more logic so there needed to be less in controllers and
devices ... real storage was scarce ... so rather than local storage in
controllers and devices ... channels provided ability for
controllers/devices to utilize main/processor memory for control
operation information, etc. The other savings trade-off across most of
the 360 & 370 line was integrated channels ... i.e. the function was
actually provided by the same processor that executed mainframe
instructions. The serial, asyncrhonous technology allowed the paradigm
to be changed, take advantage of change in resource technology
trade-offs and efficiently ship the I/O program out to the
controller/device for local execution.
60s, also had channel programs built in application space and data
transfer moving direct to/from application address space. Other systems
tended to have lots of data movement between application space and the
supervisor/kernel before doing I/O.
The application built channel programs introduced extra overhead when
moving to virtual memory ... for initial VS2 implementation ... the
CCWTRANS channel program translator from (virtual machine) cp67 was
wired into the side of EXCP processing ... the application channel
program scanned, a duplicate created ... substituting real address in
channel program for the application virtual addresses. some historic
discussion on this
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory
Also, in the late 80s (concurrent with the appearance of serial,
asynchronous I/O, in-place of half-duplex buses/channels) was open
systems support for application space direct i/o transfers (similar to
os/360 60s paradgim). This was driven by the large RDBMS vendors going
to significant increase in thruput (initially done as "raw" devices,
RDBMS had direct control of the disks bypass operating system
facilities, but eventually major operating system RDBMS platforms
started providing direct transfers support).
The network non-disk transfers was another major area. In the late 80s,
I was involved on reducing pathlength to 5k instructions and five buffer
copies ... for 8k-block transfers. This compared to equivalent VTAM
function requiring 160k instruction pathlength and 15 buffer copies,
Since that time, in large part driven by the enormous cluster
supercomputer operations ... the other platforms are providing further
pathlength reduction and elimination of buffer copies ... being able to
do direct application transfers.
--
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
