cliffhanger@cup.portal.com (Cliff C Heyer) (09/20/89)
Doug McDonald writes... >I tried it on my Dell 310 with 150 meg disk. > >Reading a 3 megabyte file (copying to a 8192*7 byte buffer) >and doing nothing to the results resulted in 570 kByte/second. > >Copying the file from one disk to a different part of the same disk >gave 440 kByte/second (after the divide by two). > >This is not stupendous, but then again is by no means 200kByte/second. > WOW!!!!!!!!!!!! FINALLY someone does a benchmark! Thanks DM. Over the months I've posted requests in ibm.pc.collectionland and *nobody* answers them! I can only conclude from the few letters I've received that people don't want to know the awful truth about their I/O.... A VAX6000 equipped w/DEC's disks will do only about 600KB/s *single user*, so your up there w/the big boys. From my research, the Dell does come out on top in a great number of areas so I would have to say it is a good choice. Ronald Guilmette writes... >>>I think that DG's AViiON workstations are going to make many people >>>reevaluate how they want to spend their $$$. The low >>>end diskless node is < $8k. This is probably CHEAPER than a similarly >>>equipped Compaq or whatever. They use the VME bus, I think. Onboard >>>SCSI & ethernet also. >>> >> Yes, they (IBM and DEC - and all the rest, including DG) will >>save the bandwidth and fast i/o for the *big iron* machines AND the >>high-end "workstations". >> >That is probably a fair statement with respect to IBM and DEC, and is >certainly a well known technique used for many years by IBM, but I think >that it is very unfair to lump little DG in with those other massive >monsters. > >I'm sure that DG (as an organization) does *not* feel that they have >the luxury of being able to try to play these marketing games That's why I said DEC & IBM in the first place. DG is the underdog that will put out first class stuff to save itself. But don't get your hopes up. As soon as their stockholders get a dividend they'll go back to the same old tricks like the big guys. The VME bus is a lower-volume higher-profit item. *But* you can be sure I'm now going to check out DG! DG disk-to-disk benchmark, anyone? (I'm hoping to start a trend here; the *big iron* guys use MIPS as a trojan horse to hide the *real* performance issue - "real world" I/O bandwidth. Lets blow their cover!) Cliff (hanger)
eric@snark.uu.net (Eric S. Raymond) (09/21/89)
In <22308@cup.portal.com> Cliff C Heyer wrote: > the *big iron* guys use MIPS as a trojan horse to hide the *real* > performance issue - "real world" I/O bandwidth. Lets blow their > cover!) Huh? The `big iron' crowd is happy to talk I/O bandwidth, it's about the only place general-purpose mainframes got room to shine any more. It's the *PC/workstation* crowd that's prone to yell about MIPS and whisper about I/O performance. As well they might. For most job-mixes, 16MHz+ UNIX micros are disk-limited rather than processor-limited. To see this, rip out your crufty old ST406/512 controller/drive pair and drop in a track-buffering ESDI or SCSI controller with 1:1 interleave -- and watch your real performance *double*. Part of this is low bus bandwidth (especially on AT-bus machines) but most is simply that processor technology has outrun mass-storage technology, very much as happened a decade ago when the VAX and other second-generation minis got off the ground (the parallel is reinforced by the strong similarity between present micro architectures and those minis -- go compare the 680x0 instruction set to a PDP-11's sometime). Barring a quantum leap in mass-storage technology, this gap is probably going to get wider rather than narrower. Therefore, expect the MIPS smoke-and-mirrors to get *more* intense... -- Eric S. Raymond = eric@snark.uu.net (mad mastermind of TMN-Netnews)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/22/89)
In article <1SsYy5#6pYhHg=eric@snark.uu.net>, eric@snark.uu.net (Eric S. Raymond) writes: | As well they might. For most job-mixes, 16MHz+ UNIX micros are disk-limited | rather than processor-limited. To see this, rip out your crufty old ST406/512 | controller/drive pair and drop in a track-buffering ESDI or SCSI controller | with 1:1 interleave -- and watch your real performance *double*. This holds pretty much true for track buffered RLL, too. When I went from an Adaptek to WD controller (WD has hardware buffering) I noted about 3:1 disk improvement. Then I measured the raw disk speed of a number of systems from PC's to supermicros doing a dd of a raw device to dev/null. The RLL and ESDI interfaces look pretty good on transfer, although the seek time is often slower on a micro. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
jesup@cbmvax.UUCP (Randell Jesup) (09/23/89)
In article <22308@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: >WOW!!!!!!!!!!!! FINALLY someone does a benchmark! Thanks DM. >Over the months I've posted requests in ibm.pc.collectionland >and *nobody* answers them! I can only conclude from the >few letters I've received that people don't want to know the >awful truth about their I/O.... Well, I just tried it on my machine (old, slower disk controller, medium fast SCSI disk (Quantum)). Read 3Meg file into memory: 609K/s. Copy 3 meg file (on slightly fragged partition) to another file on the same disk partition: ~550K/s. On a newer controller with a fast SCSI disk (170Meg CDC): ~900K/s and ~800K/s. These times are on Amiga 2500's with A2090 and A2091's using asynch SCSI. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
eric@snark.uu.net (Eric S. Raymond) (09/23/89)
In <1SsYy5#6pYhHg=eric@snark.uu.net> I wrote: > Part of this is low bus bandwidth (especially on AT-bus machines) but most is > simply that processor technology has outrun mass-storage technology, very much > as happened a decade ago when the VAX and other second-generation minis got > off the ground (the parallel is reinforced by the strong similarity between > present micro architectures and those minis -- go compare the 680x0 > instruction set to a PDP-11's sometime). Andrew Klossner pointed out that I used `present' badly here. I was thinking of standard technology in inexpensive supermicros (386 and 680[123]0 boxes) rather than the hot new RISC boxes that nobody I know can afford :-). Of course the 680x0 family is almost ten years old itself now. And minis broke a bit more than a decade ago. I've *got* to stop posting at 3am in the morning, dammit... :-) :-) But I must have said something useful, Andy's note came in hard on the heels of several thoughtful replies requesting me to expatiate further. Could it be (gasp) that some comp.arch readers actually feel a need to comprehend system-balancing and benchmarking issues at *behind the RISCy state of the art*? The mind reels! Yet another 3am post from my antediluvian CISC machine... -- Eric S. Raymond = eric@snark.uu.net (mad mastermind of TMN-Netnews)
barry@PRC.Unisys.COM (Barry Traylor) (09/24/89)
In article <7981@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > > Well, I just tried it on my machine (old, slower disk controller, >medium fast SCSI disk (Quantum)). Read 3Meg file into memory: 609K/s. >Copy 3 meg file (on slightly fragged partition) to another file on the >same disk partition: ~550K/s. On a newer controller with a fast SCSI disk >(170Meg CDC): ~900K/s and ~800K/s. Ok, ok, so we've now seen two pretty impressive transfer rates for MICROs. I would even go so far as to say that the rates reported beat by a little the PDP11/70 I used 10 years ago. I hope, however, that you don't think this comes even close to what is attainable SUSTAINED on a mainframe. How much of the CPU was chewed up while these transfers were underway? I have seen mainframes do 50 times that rate (on a 1 processor system) and only utilize 10% of a CPU. I have seen I/O rates at 4000-5000 i/os per second where the CPU is less than 75% utilized. How many SCSI channels do these micros support? On a strict connectivity basis, the mainframe I am associated with can support over 100! So go ahead and feed steriods to SCSI. It will help mainframes as much as everyone else. We would love to sell our mainframe customers hundreds of the things to squeeze into their pack farm acherage. These are my opinions and in no way can be construed as those of Unisys Corp. (Well, one CAN construe them any way one wants, I don't contstrue them as representing the Corp., however. ;-) ) Barry Traylor Unisys A Series Engineering barry@prc.unisys.com (when I can dial in AND the line stays up)