Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!tektronix!sequent!mntgfx!franka From: franka@mntgfx.UUCP Newsgroups: comp.arch Subject: Re: Processing Message-ID: <674@franka.mntgfx.MENTOR.COM> Date: Wed, 20-May-87 00:46:19 EDT Article-I.D.: franka.674 Posted: Wed May 20 00:46:19 1987 Date-Received: Sat, 23-May-87 01:08:38 EDT References: <505@sw1e.UUCP> <110@hippo.UUCP> <6123@bu-cs.BU.EDU> Reply-To: franka@mntgfx.UUCP (Frank A. Adrian) Organization: Mentor Graphics, Beaverton, OR Lines: 46 >In article franka@mntgfx.UUCP (Frank A. Adrian) writes: >>Let's see how long I have to wait to send this data at different baud rates: >>baud time >>---- ---- >>9600 17Gs (this is GIGA, folks) >>50K 320Ms (getting better, but still have to wait a while) >>50M 320Ks (down to about 9 hours) >>50G 320s. (right ballpark) > >In article <1263@ogcvax.UUCP> pase@ogcvax.UUCP (Douglas M. Pase) writes: >>Don't forget the box of optical disks sent via some neighbor kid on a bicycle >>(or Federal Express, etc.). > In article <673@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >Yes, even today, for large amounts of data, the speed and cost of moving a >physical medium can be much better than that obtained by transmitting pure >information. It's instructive to compute the baud rate of a mundane 1600 BPI >tape flown from NY to SF in 6 hours. And of course, you can easily increase >the effective rate by an order of magnitude by simply sending 10 tapes at once. >For Doug's case, assume an optical disk means a CD, holding 600 MB. > >For micro users, the cost of downloading a "free" program from, say, >Compuserve may exceed the cost of buying a disk with that program on it! In all of this discussion I think my original point got lost (or maybe it was lost between my brain and the keyboard), which was that we have all of these companies wanking on about how many MIPs their processor has when in most cases, their I/O systems were the bottleneck in their last generation of machines. Actually, I don't see very much need for an even higher MIPs rate unless we can get he info in and out of memory in a timely fashion (and you'd have to have a preety small kid on a bicycle to cart the data out of memory). I know that it is tempting to keep adding more MIPs becuase it is a simple number for the average dweeb in the street to think he understands when the ol' marketing department comes around wanking (even though it is meaningless), but those of us who work with systems already know how little bang for the buck adding more MIPs seems to be getting these days. The question I'm throwing out to all of the great system architects out there is "What can be done to solve the problem of the apalling lack of I/O bandwidth found on every micro based uniprocessor system out there today?". Just wondering... Frank "Mr. Sensitivity" Adrian Mentor Graphics, Inc. These views in no way, shape, or form reflect those of my employer.