Re: what's a mainframe, was is Vax addressing sane today

John Levine <johnl@taugh.com> writes:

I suppose.  A review from the USDOE said:
>
 The IBM 3090 with Vector Facility is an extremely interesting machine
 because it combines very good scaler performance with enhanced vector
 and multitasking performance. For many IBM installations with a large
 scientific workload, the 3090/vector/MTF combination may be an ideal
 means of increasing throughput at minimum cost. However, neither the
 vector nor multitasking capabilities are sufficiently developed to
 make the 3090 competitive with our current worker machines for our
 large-scale scientific codes.

1st part of 70s, IBM had FS effort, was totally different than 370
and was to completely replace 370 (internal politics was killing
off 370 efforts).
http://www.jfsowa.com/computer/memo125.htm

when FS finally implodes, there is a mad rush to get stuff back into the
370 product pipelines, including kicking off 3033&3081 efforts in
parallel.

I got sucked into work on 16-processor 370 SMP and we con the 3033
processor engineers into working on it in their spare time (lot more
interesting that remapping 168 logic for 20% faster chips). Everybody
thot it was great until somebody tells the head of POK lab that it could
be decades before the POK favorite son operating system (batch MVS) has
(effective) 16-processor support (at the time MVS documentation claimed
that its 2-processor throughput had 1.2-1.5 times the throughput of
single process). The head of POK then invites some of us to never visit
POK again and the 3033 processor engineers, heads down and no
distractions (although I was invited to sneak back into POK to work with
them). POK doesn't ship a 16-processor machine until after the turn of
the century, more than two decades later.

Once the 3033 was out the door, the processor engineers start on
trout/3090. When vector was announced they complained about it being
purely marketing stunt ... that they had so speeded up 3090 scalar that
it ran at memory bus saturation (and vector would unlikely make
throughput much better).

I had also started pontificating the relative disk throughput had gotten
an order of magnitude slower (disks got 3-5 times faster while systems
got 40-50 times faster) since 360 announce. Disk division executive took
exception and directed division performance group to refute the claims,
after a couple weeks they came back and said I had slightly understated
the problem. They respun the analysis on how to configure disks to
improve system throughput for a user group presentation (16Aug1984,
SHARE 63, B874).

I was doing some work with disk engineers and that they had been
directed to use a very slow processor for the 3880 disk controller
follow-on to the 3830 ... while it handled 3mbyte/sec 3380 disks, it
otherwise seriously drove up channel busy. 3090 originally assumed that
3880 would be like previous 3830 but with 3mbyte/sec transfer ... when
they found out how bad things actually was, they realized they would
have to seriously increase the number of (3mbyte/sec) channels (to
achieve target throughput). Marketing then respins the significant
increase in channels as being wonderful I/O machine. Trivia: the
increase in channels required an extra TCM and the 3090 group
semi-facetiously claimed they would bill the 3880 group for increase in
3090 manufacturing cost.

I was also doing some work with Clementi
https://en.wikipedia.org/wiki/Enrico_Clementi
E&S lab in IBM Kingston ... had boatload of Floating Point Systems boxes
https://en.wikipedia.org/wiki/Floating_Point_Systems
that had 40mbyte/sec disk arrays for keeping the FPS boxes fed.

In 1980, I had been con'ed into doing channel-extender implementation
for IBM STL (since renamed SVL), they were moving 300 people and 3270
terminal to offsite bldg with dataprocessing back to STL datacenter.
They had tried "remote 3270" but found human factors unacceptable.
Channel-extender allowed "channel-attached" 3270 controllers to be place
at offsite bldg with no human factors difference between offsite and in
STL. Side-effect was that it increased system throughput by 10-15%. They
had previously spread 3270 controllers across all the same channels with
disks, the channel-extender work significantly reduced 3270 terminal I/O
channel busy, increasing disk I/O and system throughput (they were
considering moving all 3270 controllers to channel-extender, even those
physically inside STL. Then there was attempt to my support released to
customers, but there was group in POK playing with some serial stuff
that get it vetoed, they were afraid if it was in the market, it would
make it harder to release their stuff.

In 1988, the IBM branch office asks if I could help LLNL get some serial
stuff they were playing with, standardized ... which quickly becomes
fibre-channel standard ("FCS", initially 1gibt/sec, full-duplex,
aggregate 200mbyte/sec). The POK serial stuff finally gets released in
the 90s with ES/9000 as ESCON (when it is already obsolete,
17mbytes/sec). Then some POK engineers become involved with FCS and
define a heavy-weight protocol that significantly reduces throughput,
eventually released as FICON. The latest, public benchmark I've found is
z196 "Peak I/O", getting 2M IOPS using 104 FICON. About the same time, a
FCS is announced for E5-2600 blade claiming over million IOPS (two such
FCS has higher throughput than 104 FICON). Also IBM docs had SAPs
(system assist processors that do actual I/O) kept to 70% cpu (more like
1.5M IOPS), also no IBM CKD DASD have been made for decades all being
simulated on industry standard fixed-block disks.

--
virtualization experience starting Jan1968, online at home since Mar1970