Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!lll-winken!uunet!portal!cup.portal.com!cliffhanger
From: cliffhanger@cup.portal.com (Cliff C Heyer)
Newsgroups: comp.arch
Subject: PC vs. mainframe I/O (Re: SCSI on steroids)
Message-ID: <21962@cup.portal.com>
Date: 8 Sep 89 01:14:09 GMT
Organization: The Portal System (TM)
Lines: 261

Feel free to ax the following. I'm not pretending 
to be an IBM expert! I've tried to summarize what 
I've learned over the years....using non-IBM 
terminology. Also don't think I'm biased for only 
mentioning DEC. I'm too lazy to research other 
hardware just for this article!


Lawrence Butcher initially stated:
>The biggest, fastest business computers seem to 
>run 1960's operating systems without protection, 
>and allow user programs to do I/O without OS 
>assistance.

First of all, lets understand what we are 
comparing: "server/IPCF" vs. "timesharing" 
architecture. "1960's operating systems" were 
optimized for a specific need. A UNIX-type OS is 
optimized for a different need.

Yes, "1960's operating systems" do "manage" their 
own DMA I/O in a sense. Users "share" one copy of 
the screen control program in "core" and declare 
chunks of memory ("queue", global section w/AST in 
VMS terms.) for communication with a "server"  A 
server process "sleeps" until a request comes in 
it's queue("interrupt") for data (eg. airline 
ticket key). The server collects up to 100 keys 
from terminals, organizes them by disk drive and 
disk address, and retrieves them in sequence (just 
like the ladder algorithms in hard disk 
controllers). Large segments of the database are 
kept in memory on post-3033 hardware.

Remember 1960s computers had a *blazing* 1/2 MIPS 
and about 500KB core. The timesharing architecture 
where you set up a separate process for each user 
("ticket clerk") simply wouldn't cut it. The 
overhead was too high then, and it still is today. 
Here's why:

1. Setting up a "user process" for each user 
creates a vast amount of OS overhead compared with 
using a simple control program which services TTY 
queues in round-robin fashion. The "login" to the 
OS which prompts & checks your password is off 
loaded to communications processors OR is not used 
due to direct leased-line connections. With 
timesharing too many unnecessary resources are 
needlessly duplicated for each user. Core & MIPS 
used up too fast.

2. Timesharing OS "file channels" for each user 
creates a vast amount of overhead compared with 
communicating through memory with interrupts 
(IPCF) with a server. With timesharing too many 
resources are needlessly duplicated for each user.

3. Simultaneous update lock overhead vast compared 
to server lock management. With timesharing too 
many resources are needlessly duplicated for each 
user.

4. Security. Maintaining user directories, file 
protections, etc. overhead is vast compared to a 
server architecture. With timesharing too many 
unnecessary resources are needlessly duplicated 
for each user. Also with the control program 
approach there are no "directories" or "commands" 
that can be abused by hackers to break the system.

5. No data independence. If you modify the 
database you have to tinker with the applications. 
With a server, the communication is through memory 
so anything can be changed so long as you maintain 
the communications protocol.

It's really funny, but now 20 years later "the 
rest of us" can now take part in this type of 
technology (now IBM's patents have expired?). The 
emergence of PC LANs has created a need for 
"server" nodes that operate with much the same 
principle. Products such as SYBASE are an example. 
I hope DEC will take the plunge into this type of 
architecture with it's new VAX 9000 line (if they 
ever hope to compete with IBM). This "airline 
system" architecture, however, will never become 
as popular as timesharing systems because it's 
basically a vertical market product.

The conclusion of this section is that specialized 
OS contributes to massive I/O rates. (IBM keeps 
with this trend via ESA)

Lawrence Butcher writes:
>My new question. Is fast I/O all that micros need 
>to bury mainframes?  Or is user level I/O needed?  
>If needed, how can simple hardware be built which 
>allows direct user level DMA I/O?

Yes & Yes, except watch out for apples vs. oranges 
comparison. What you're referring to as "user 
level I/O" is NOT the same as what most people 
might think. "User level I/O" in terms of the 
"1960s operating systems" referres to a vertical 
market control program that replaces a typical 
UNIX-type timesharing system. That VAST user level 
I/O was & is achieved by sacrificing ALL the 
capability that a UNIX user has come to love. 
VAX ACMS systems can't compete with IBM because 
they attempt to layer the "control program" on top 
of VMS. VMS sucks up all the CPU cycles with 
overhead not needed for the job being done.

"Mainframe I/O" where you have 100+ channels 
cooking at 3MB/sec does not mesh with a 
timesharing-type OS. That's why IBM LAYERS all 
it's timesharing environments(CMS, TSO) ON TOP of 
MVS or VM (and they run slow as death). You can't 
always have your cake and eat it too. The OS has 
to be created for the application. DEC only gives 
us ONE type of OS. DEC's software is the reverse 
of IBMs - ACMS (control program) sits on top of 
VMS(timesharing system), but with IBM 
TSO(timesharing system) sits on top of MVS(control 
program). What DEC needs is a specialized OS for 
use to run the ACMS environment once it's been 
created on VMS.

ALSO keep on mind the the alleged "100+ MIPS" 
processors are actually multiprocessors. The IBM 
3090-600 has 6 15 MIPS processors. The *fastest* 
single user processing is 15 MIPS - NOT 100 MIPS! 
IBM's max uniprocessor MIPS is about the same as 
others in the industry.  

Channel CPUs to offload main CPU interrupts help 
big time, as does multi-ported memory. But DEC has 
added intelligent processors long ago also. In 
1974 when the KL10 came out they started using a 
PDP-11 front end to offload terminal interrupts 
from the main processor. I think IBM is stronger 
with the channel CPU & multi-ported memory, 
though. VAX CPUs are still managing DMA and 
character I/O transfers. I think IBM has some 
*broad* patents in the multi-ported memory area 
that will expire soon. Enter the VAX 9000. Also, 
IBM does not use DEC's "single bus" subsystem 
connection scheme but rather connects subsystems 
via "channel architecture" and multi-ported 
memory. This gives >100MB/sec throughput.

You might wonder how IBM keeps it's memory 
subsystem fast enough to keep up with it's 15 MIPS 
processors. They do it the brute force way. Use 
expensive 3ns ECL cache and 512MB of 50ns SRAM 
main memory to run at a cool 10ns cycle time or 
100MHz. (Compare to the *fastest* 80386 PC at 
33MHz.) No wonder they cost $10 million (quoted 
from Sam Fuller/Amdahl)

The conclusion of this section is that massive I/O 
BW (again) comes from a specialized OS, but ALSO 
*expensive*fast* memory subsystems AND channel 
architecture w/multi-ported memory.

Now, on the subject of PCs and disk I/O...

Yes, the only thing that distinguishes an 8-MIPS 
PC board from an 8-MIPS VAX 6000 board is the I/O 
bandwidth. This comes primarily from the memory 
cycle time.

The PC industry is suffering from the "low margin 
& compatibility blues" In other words, because the 
PC is now a commodity the profit margins are too 
slim to allow for *high speed* SRAM and ECL 
memory, and too slim to finance R & D - which is 
what is required to engineer new bus technology. 
New bus technology is risky to introduce and make 
a profit because *everyone* has standardized on 
the AT bus and *most* are happy enough not to yell 
loud.

If you were to buy a PC with minicomputer or 
mainframe I/O - it would cost you as much as a 
minicomputer or mainframe. Because the 
*engineering* costs & material costs will be the 
same as the big guys. You'd have to have a *fast* 
memory subsystem which would cost *bug bucks*.

You don't get something for nothing. These PC 
makers have to compete with 50 other companies 
that have cut-throat margins. They can't fuss 
around trying to make a high bandwidth bus(w/ 
associated fast memory) and expect to get to 
market on time to keep up with the others. If you 
snooze you loose. You have to keep the product 
flowing to keep the cash flowing.

What *will* change this though is the emergence of 
new low cost chips such as the NCR53C700 SCSI 
chip, and the fall in price of SRAM or faster DRAM 
(actually *vastly* faster DRAM) When the PC makers 
can use low cost chips for high bandwidth rather 
than engineer their own bus design, they will do 
it. They will be able to put ESDI/SCSI interfaces 
ON the motherboard and BYPASS the AT bus.

The thing about "mainframes" is that these guys 
ALWAYS thought BIG. Did you know the first hard 
disk in the late 50s contained 5MB? NOT 50KB like 
early floppies. These guys new how much data they 
had to store and weren't going to fuss around with 
a 50KB hard drive. Sure, the 5MB drive was as big 
as a refrigerator, but so what? You're charging 
$100K for it.

The same is true for I/O bandwidth. They knew how 
much data they had to process and what the time 
limits were (eg. get 100,000 pay checks of 64 
bytes each out by Friday). If you ran the system 
24 hours, that came out to say 10MB/sec I/O. This 
increased to 16MB/sec in the early 70s, and to 
70MB/sec in the early 80s. Did they ever fuss 
around with a 500KB/sec AT bus? Yea right.

Mainframe disk I/O exceeded the AT bus around 
1959. These guys KNOW how to do it fast. But these 
companies are also publicly owned and must make 
money for their stockholders. If they start 
blowing out 80386 PCs with 2MB/sec sustained disk
I/O on multiple simultaneous drives, who will buy 
their mainframes? (eg. how many American Airlines 
Sabre systems are there?) Also, they can't do that 
and stay competitive with the clones at the 
moment..

So they market "incremental improvements" which 
are say 10% faster than the last desktop model, 
but still use "off the shelf" chips and boards. So 
you are continually forced to buy new hardware to 
keep up with the best. It *does* cost more to 
engineer a fast bus than to use off-the-shelf 
components and slap together another clone.

And since the market is NOT demanding a fast PC 
bus, why go to all the trouble? Maybe you'll loose 
money. If you do put a fast bus together, you'll 
point it towards the workstation market where the 
profit margins will support the engineering costs.

But as I said above, when fast cheap I/O chips can 
be used by board makers to bypass the AT bus, 
that's when the sparks will fly and the mainframe 
folks will be running for the hills. Ask yourself 
why DEC is planning to lay off 25,000 people over 
the next few years? The writing is on the wall. 
Soon CISC computers will be "all invented."

Please POST your comments...