🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #22775

Re: 64-bit addresses

#22775
From: John R. Levine
Date: Mon, 05 Mar 1990 03:25
38 lines
2700 bytes
>bzs@world.std.com (Barry Shein) writes:
>>The 3090 still provides fairly awesome I/O for the price...
>>...It probably still is a cost-effective database
>>transaction machine for very large databases
>Barry,
>
>It's folklore in the database world that things are as you say...but
>nobody ever seems to have any numbers. ...

I saw an article by someone from IBM in, as I recall, TODS that showed that
a smaller number of faster processors would give you better database
throughput than a larger number of slower processors of equivalent aggregate
mips.  The crux of the argument is that when you have a lot of transactions,
there gets to be considerable contention and the faster processors have a
shorter hold time per transaction and fewer simultaneous transactions, hence
fewer collisions.  I'll see if I can dig it up.

Also, people who aren't familiar with the current state of mainframes may not
realize how different mainframe I/O is from workstations'.  A 370's channel
probably has more CPU horsepower than a Sparcstation (there's reputed to be
an 801 RISC mini hidden inside) not to mention far more RAM.  It's quite
common to have 128MB and up of RAM buffer in the channel.  There are multiple
data paths at each stage -- disk to controller, controller to channel, and
channel to processor memory, and the channel assigns paths on the fly,
keeping aware of such things as the relative angular position of each disk
platter so it can tell when desired data are coming to the head so that it
needs to assign a path.  Having the channel wait idle while the platter comes
around, like every workstation I know still does, went out of style in
mainframes in about 1972.

Workstation I/O is probably as far behind mainframe I/O as workstation CPU
performance was behind mainframe CPU in 1975.  Of course, at the current rate
of change, that means the killer micros will catch up in about 1993.

-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."
Technical Details
Message-ID: <1990Mar5.032554.1852@esegue.segue.boston.ma.us>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!snorkelwacker!spdcc!esegue!johnl
References: <WAYNE.90Feb27094326@dsndata.uucp> <1786@gannet.cl.cam.ac.uk> <1990Mar2.232735.6071@world.std.com> <780@dgis.dtic.dla.mil> <1990Mar4.222938.20483@world.std.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!snorkelwacker!spdcc!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses
Message-ID: <1990Mar5.032554.1852@esegue.segue.boston.ma.us>
Date: 5 Mar 90 03:25:54 GMT
References: <WAYNE.90Feb27094326@dsndata.uucp> <1786@gannet.cl.cam.ac.uk> <1990Mar2.232735.6071@world.std.com> <780@dgis.dtic.dla.mil> <1990Mar4.222938.20483@world.std.com>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Organization: Segue Software, Cambridge MA
Lines: 38