thad@cup.portal.com (Thad Thad Floryan) (10/18/88)
Following are some most-interesting disk performance results.
Comments are invited. I can relay messages to/from the original poster.
The following was posted verbatim to BBS-JC on 18-Oct-1988 in response to
my original statement of disbelief at the claim posted to BBS-JC by a marketing
person from C-Ltd last week of "500K per second." I'm still incredulous, since
these figures indicate performance surpassing Sun 3/50, Sun 4/260, Compaq, etc.
which use SMD and ESDI interfaces. Well, life is full of surprises! :-)
For those who may not be aware, Ronin Research and Development are the
designers and manufacturers of the Hurricane family of 68020 and 68030 cards
for the Amiga computers.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
`` Comparison Shopping with Diskperfa....
/---------------------------------------------------------------------------/
Posted: BBS-JC
TO: Thad Floryan and anyone else interested
Subject: Hard disk Performance
From: Brick Eksten ( Ronin Research and Development )
/---------------------------------------------------------------------------/
The object of the comparisons are to show that "True DMA" controllers
are not always the best. In fact, the fastest times were obtained using
boards that use no DMA, instead using polled I/O to read/write data.
These were early tests and are not the fastest times obtained.
These tests show the difference between the non DMA boards and DMA boards,
and how DMA boards are affected by the addition of memory that cannot
be accessed by the DMA process ( 32 bit memory). DMA boards cannot
access any 32bit memory, so they must write/read to/from chip ram,
or 16bit ram, were it can then be copied by the operating system into
32bit ram. This is only a sample document. The complete tests will
be posted when I have the time to make them legible.
/---------------------------------------------------------------------------/
Quantum Pro40 SCSI ( 40meg ), CPU=68020, 16bit memory, FFS , C-LTD controller
C-LTD is a "Non DMA controller" ( Polled I/O )
File create/delete: create 15 files/sec, delete 27 files/sec
Directory scan: 113 entries/sec
Seek/read test: 115 seek/reads per second
r/w speed: buf 512 bytes, rd 70849 byte/sec, wr 62415 byte/sec
r/w speed: buf 4096 bytes, rd 174762 byte/sec, wr 100824 byte/sec
r/w speed: buf 8192 bytes, rd 218453 byte/sec, wr 154202 byte/sec
r/w speed: buf 32768 bytes, rd 262144 byte/sec, wr 187245 byte/sec
/---------------------------------------------------------------------------/
Quantum Pro40 SCSI ( 40meg ), CPU=68000, 16bit memory, FFS , GVP controller
w/buffers =32
GVP uses Pseudo DMA ( DMA into onboard static ram, polled I/O to bus)
* ( see below )
File create/delete: create 13 files/sec, delete 28 files/sec
Directory scan: 94 entries/sec
Seek/read test: 121 seek/reads per second
r/w speed: buf 512 bytes, rd 84562 byte/sec, wr 59578 byte/sec
r/w speed: buf 4096 bytes, rd 201649 byte/sec, wr 100824 byte/sec
r/w speed: buf 8192 bytes, rd 291271 byte/sec, wr 124830 byte/sec
r/w speed: buf 32768 bytes, rd 374491 byte/sec, wr 145635 byte/sec
/---------------------------------------------------------------------------/
Quantum Pro40 SCSI ( 40meg ), CPU=68030, 32bit memory, FFS , C-LTD controller
32bit memory and remap of ROMS before installing and mounting drives
"noblockread" Flag set in C-LTD software
File create/delete: create 18 files/sec, delete 35 files/sec
Directory scan: 227 entries/sec
Seek/read test: 156 seek/reads per second
r/w speed: buf 512 bytes, rd 97090 byte/sec, wr 84562 byte/sec
r/w speed: buf 4096 bytes, rd 187245 byte/sec, wr 145635 byte/sec
r/w speed: buf 8192 bytes, rd 238312 byte/sec, wr 174762 byte/sec
r/w speed: buf 32768 bytes, rd 327680 byte/sec, wr 238312 byte/sec
/---------------------------------------------------------------------------/
Quantum Pro40 SCSI ( 40meg ), CPU=68030, 32bit memory, FFS , C-LTD controller
32bit memory and remap of ROMS before installing and mounting drives
"blockread" Flag set in C-LTD software, 0 buffers in C-LTD software,
buffers = 10 in mountlist
File create/delete: create 15 files/sec, delete 45 files/sec
Directory scan: 238 entries/sec
Seek/read test: 162 seek/reads per second
r/w speed: buf 512 bytes, rd 97090 byte/sec, wr 29127 byte/sec
r/w speed: buf 4096 bytes, rd 291271 byte/sec, wr 145635 byte/sec
r/w speed: buf 8192 bytes, rd 291271 byte/sec, wr 174762 byte/sec
r/w speed: buf 32768 bytes, rd 524288 byte/sec, wr 238312 byte/sec
/---------------------------------------------------------------------------/
Quantum Pro40 SCSI ( 40meg ), CPU=68030, 32bit memory, FFS , C-LTD controller
32bit memory and remap of ROMS before installing and mounting drives
"blockread" Flag set in C-LTD software,buffers=5 in C-LTD software,
buffers = 10 in mountlist
File create/delete: create 16 files/sec, delete 45 files/sec
Directory scan: 238 entries/sec
Seek/read test: 151 seek/reads per second
r/w speed: buf 512 bytes, rd 97090 byte/sec, wr 28807 byte/sec
r/w speed: buf 4096 bytes, rd 291271 byte/sec, wr 145635 byte/sec
r/w speed: buf 8192 bytes, rd 291271 byte/sec, wr 174762 byte/sec
r/w speed: buf 32768 bytes, rd 524288 byte/sec, wr 238312 byte/sec
/---------------------------------------------------------------------------/
Miniscribe 3053 5.25" 40meg, CPU=68030, 32bit memory, FFS , Commodore 2090
Commodore A2090 is a DMA controller (ST-506)
File create/delete: create 14 files/sec, delete 45 files/sec
Directory scan: 139 entries/sec
Seek/read test: 131 seek/reads per second
r/w speed: buf 512 bytes, rd 70849 byte/sec, wr 34044 byte/sec
r/w speed: buf 4096 bytes, rd 81920 byte/sec, wr 34492 byte/sec
r/w speed: buf 8192 bytes, rd 81920 byte/sec, wr 34044 byte/sec
r/w speed: buf 32768 bytes, rd 84562 byte/sec, wr 34492 byte/sec
/---------------------------------------------------------------------------/
Miniscribe 3053 5.25" 40meg, CPU=68030, 16bit memory, FFS , Commodore 2090
Commodore A2090 is a DMA controller (ST-506)
File create/delete: create 16 files/sec, delete 41 files/sec
Directory scan: 113 entries/sec
Seek/read test: 112 seek/reads per second
r/w speed: buf 512 bytes, rd 84562 byte/sec, wr 28187 byte/sec
r/w speed: buf 4096 bytes, rd 131072 byte/sec, wr 109226 byte/sec
r/w speed: buf 8192 bytes, rd 174762 byte/sec, wr 137970 byte/sec
r/w speed: buf 32768 bytes, rd 238312 byte/sec, wr 154202 byte/sec
/---------------------------------------------------------------------------/
CDC 5.25" 40meg, CPU=68020, 16bit memory, FFS , Commodore 2090
File create/delete: create 15 files/sec, delete 47 files/sec
Directory scan: 119 entries/sec
Seek/read test: 94 seek/reads per second
r/w speed: buf 512 bytes, rd 60963 byte/sec, wr 28187 byte/sec
r/w speed: buf 4096 bytes, rd 124830 byte/sec, wr 109226 byte/sec
r/w speed: buf 8192 bytes, rd 163840 byte/sec, wr 137970 byte/sec
r/w speed: buf 32768 bytes, rd 201649 byte/sec, wr 154202 byte/sec
/---------------------------------------------------------------------------/
Seagate ST251-1 5.25" 40meg, CPU=68020, 16bit memory, FFS , Commodore 2090
File create/delete: create 14 files/sec, delete 52 files/sec
Directory scan: 100 entries/sec
Seek/read test: 118 seek/reads per second
r/w speed: buf 512 bytes, rd 84562 byte/sec, wr 28187 byte/sec
r/w speed: buf 4096 bytes, rd 124830 byte/sec, wr 113975 byte/sec
r/w speed: buf 8192 bytes, rd 174762 byte/sec, wr 137970 byte/sec
r/w speed: buf 32768 bytes, rd 201649 byte/sec, wr 145635 byte/sec
/---------------------------------------------------------------------------/
All performance tests using 68020,68030,and 32bit memory, were done
using the Ronin Research and Development "Hurricane" accelerator boards.
* GVP tests are very incomplete, latest tests show 500+Kbytes/sec,
with very little difference between read and write times.
As a side note, A program that uses "Amiga" specific function
calls ( as opposed to using "C" function calls ) was able to achieve
800+kbytes/sec using the C-LTD or GVP controllers, both controllers
were very similar in performance. The C-LTD controller did much better
when reading/writing small files ( 10-30k ), the GVP controller did
its best reading/writing large files ( 300k-1meg ). Both controllers
were very close in midrange file size performance, but peak performance
was reached when reading/writing files that take advantage of each boards'
type of hardware engineering.
''jesup@cbmvax.UUCP (Randell Jesup) (10/19/88)
In article <10150@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes: >The following was posted verbatim to BBS-JC on 18-Oct-1988 in response to >my original statement of disbelief at the claim posted to BBS-JC by a marketing >person from C-Ltd last week of "500K per second." I'm still incredulous, since >these figures indicate performance surpassing Sun 3/50, Sun 4/260, Compaq, etc. >which use SMD and ESDI interfaces. Well, life is full of surprises! :-) Suns? Ha! Slow as worms! :-) And anything with an _INTEL_ processor? Evil, kill it before it infects something, slower than molasses! :-) >`` Comparison Shopping with Diskperfa.... Diskperfa is rather dependant on stdio/library implementation. Most of the calls used are C library calls meant to emulate Unix calls, and may therefor have some amount of overhead. For the read/write speeds, I'd think that the speed of Read() and Write() would be better benchmarks (and less dependant on compiler library implementation). >From: Brick Eksten ( Ronin Research and Development ) > > The object of the comparisons are to show that "True DMA" controllers > are not always the best. In fact, the fastest times were obtained using > boards that use no DMA, instead using polled I/O to read/write data. > These were early tests and are not the fastest times obtained. > These tests show the difference between the non DMA boards and DMA boards, > and how DMA boards are affected by the addition of memory that cannot > be accessed by the DMA process ( 32 bit memory). DMA boards cannot > access any 32bit memory, so they must write/read to/from chip ram, > or 16bit ram, were it can then be copied by the operating system into > 32bit ram. This is only a sample document. The complete tests will > be posted when I have the time to make them legible. Disclaimer: As far as I know, Ronin boards are fine products. That said, note that not all 68020 boards have 32-bit ram that cannot be DMAed into. The A2620 has up to 4Meg of 32-bit ram that can be DMAed into, for example. It may well be that with 32-bit non-DMA memory, CPU-driven I/O is faster. However, with FFS and DMA-able 32-bit memory, I suspect a DMA controller would be faster (and tie up the bus less, due to less interrupts/polling). >Miniscribe 3053 5.25" 40meg, CPU=68030, 32bit memory, FFS , Commodore 2090 >Commodore A2090 is a DMA controller (ST-506) >r/w speed: buf 32768 bytes, rd 84562 byte/sec, wr 34492 byte/sec Please note that the Minscribe is, I believe, a 40 ms or maybe slower drive, unlike the Quantum 40S's you were using above. Also note that the speed of a 2090 may well be faster using SCSI than St506. >Miniscribe 3053 5.25" 40meg, CPU=68030, 16bit memory, FFS , Commodore 2090 >r/w speed: buf 32768 bytes, rd 238312 byte/sec, wr 154202 byte/sec With 32-bit DMA-able memory, the numbers would have been signifigantly higher than the 16-bit figures. Inability to do direct transfers to the destination buffer GREATLY reduce the speed of FFS (everything must be copied twice, plus it probably does I/O 1 block at a time, instead of just transfering the entire amount in one transfer.) > As a side note, A program that uses "Amiga" specific function > calls ( as opposed to using "C" function calls ) was able to achieve > 800+kbytes/sec using the C-LTD or GVP controllers, both controllers > were very similar in performance. The C-LTD controller did much better > when reading/writing small files ( 10-30k ), the GVP controller did > its best reading/writing large files ( 300k-1meg ). Both controllers > were very close in midrange file size performance, but peak performance > was reached when reading/writing files that take advantage of each boards' > type of hardware engineering. 800K/sec is also achievable with the 2090/2090a, with a good SCSI disk (like the Quantums mentioned above - the 64K cache does wonders). I have seen a controller load a 2-meg file into 32-bit memory in less than 4 seconds. 600K/sec can be easily achieved with a 2090 and a semi-reasonable disk (and a 68000 processor). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
root@sbcs.sunysb.edu (root) (10/19/88)
In article <5030@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > In article <10150@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes: > Suns? Ha! Slow as worms! :-) And anything with an _INTEL_ processor? > Evil, kill it before it infects something, slower than molasses! :-) Wouldn't be too quick to downside Sun disk performance, even in jest :-). The Sun may not deliver the absolute transfer speed of FFS, but it will continue to deliver the same transfer speed on day 1 after the initial format and on day N. Unless FFS has some reasonable fragmentation control algorithms you're going to suffer the same slow downs that the "old" Unix filesystem did, ie freshly formatted you got ~150 kBytes/sec, after a few weeks you had only ~30 kBytes/sec performance. The Sun filesystem also delivers more file information, eg creation/modification/access dates, ownership and symbolic/hard links. So let's not just key on who fast we can do 1 mByte reads. The Sun filesystem also has tools for crash recovery; too often I've heard the only tool available for Amiga FS recovery is diskdoctor followed by a format. ** Note: I am not bashing FFS; Steve has done a really fine job on it. I am merely pointing out that we've a ways to go on Amiga before we even reach the current state of the art in Unix systems. > Diskperfa is rather dependant on stdio/library implementation. Most > of the calls used are C library calls meant to emulate Unix calls, and may > therefor have some amount of overhead. For the read/write speeds, I'd think > that the speed of Read() and Write() would be better benchmarks (and less > dependant on compiler library implementation). It is pretty trivial to mung diskperfa to use Read/Write - I did this when I wrote it and found that the overhead that Manx adds is fairly neglible. Rick Spanbauer SUNY/Stony Brook
daveh@cbmvax.UUCP (Dave Haynie) (10/20/88)
in article <10150@cup.portal.com>, thad@cup.portal.com (Thad Thad Floryan) says: > Xref: cbmvax comp.sys.amiga:26234 comp.sys.amiga.tech:2750 > Comments are invited. I can relay messages to/from the original poster. OK, here are some... > DMA boards cannot access any 32bit memory, so they must write/read > to/from chip ram, or 16bit ram, were it can then be copied by the > operating system into 32bit ram. This is implementation dependent. With Ronin's 32 bit memory, no DMA to 32 bit memory is possible. With the 32 bit memory on a Commodore A2620, DMA from 16 bit devices works just fine. The 16->32 bit copy mentioned is because you're using FFS, and have 32 bit memory in front of 16 bit memory. Certainly, in this specific case, a well designed CPU driven hard disk would be expected to run faster. For example the GVP board requires the CPU to copy from it's static RAM into some 32 bit RAM, and that's the only slowdown on the system. With any DMA driven device and the Ronin boards, you'd have real DMA into some 16 bit memory, and then a CPU copy into 32 bit RAM. That's essentially the GVP time, PLUS the DMA time. You loose. Now consider the same setup using DMAable 32 bit memory on the A2620. The GVP still has 16 bit memory. The most efficient transfer loop would use a long to long copy (no tricks are really needed, since the 68020 or 68030 will cache all the instructions in the copy loop). It'll take two 16 bit/7.16 MHz memory cycles (8 - 7.16MHz clocks) to transfer a longword to the 68020, one 32 bit/14.3 MHz memory cycle (2 - 7.16MHz clocks, the Ronin board appears to have one wait state, so the 68020 will run a 4 clock cycle). With DMA directly to 32 bit RAM, you need two 16 bit/7.16 MHz cycles (8 - 7.16MHz clocks) to transfer the longword. Period. So you go faster than non-DMA would. However, the difference between the DMA and non-DMA device is much less than in a complete 16 bit system, since the access to 32 bit memory is fast. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
tlm@pur-phy (Timothy Lee Meisenheimer) (10/20/88)
> lots of nice juicy info.......
My big question is: If I have 800K+ bytes/sec raw speed (great!!!), but
this is done with I/O polling what happens with my over all system
perfomance. If this was a single tasking PC I would be mildly extatic, but
I don't want all my other processes to freeze while I suck in a 100K file!
Any one have experience with what happens to other processes and the
windowing system when you do this?
I'd really like to see 600K+ transfer rate and not have it kill system
performance! Shoot, I've just got a single floppy, I'd be happy with 200K
and good system performance!
tlm@newton.physics.purdue.eduperley@rocky.steinmetz (Donald P Perley) (10/21/88)
In article <10150@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes: >Following are some most-interesting disk performance results. > The object of the comparisons are to show that "True DMA" controllers > are not always the best. In fact, the fastest times were obtained using > boards that use no DMA, instead using polled I/O to read/write data. > These were early tests and are not the fastest times obtained. > These tests show the difference between the non DMA boards and DMA boards, > ............ a bunch of benchmarks ............... These show good data rates... GREAT! As comparisons between DMA and non-DMA, they show that: non-DMA is faster than DMA OR Quantum pro-drives are faster than Seagate ST251-1 or Miniscribe 3053. OR SCSI is faster than ST506 OR The 2090 design is lacking in some other respect. Somehow, with all those variables involved, dma/non-dma doesn't jump out as the clear explanation. If this is suposed to compare DMA to non-DMA, it would make sense to use the same disk drive for both cases. Apparently they thought it was worthwhile to move the Quantum around to all the non-dma boards... why not put it on the 2090? Another consideration: Even if a non-dma controller has a higher mazimum speed, what is the impact on CPU load? Thad's point in posting this was that FFS can give transfer rates in the 500k/sec range, which is still valid, and I'm not trying to flame him..... just the part about the object of the comparisons, written by the hurricane people. -don perley
jesup@cbmvax.UUCP (Randell Jesup) (10/22/88)
In article <1728@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: >In article <5030@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: >> Suns? Ha! Slow as worms! :-) And anything with an _INTEL_ processor? >> Evil, kill it before it infects something, slower than molasses! :-) > > Wouldn't be too quick to downside Sun disk performance, even > in jest :-). The Sun may not deliver the absolute transfer > speed of FFS, but it will continue to deliver the same > transfer speed on day 1 after the initial format and on > day N. Unless FFS has some reasonable fragmentation control > algorithms you're going to suffer the same slow downs that > the "old" Unix filesystem did, ie freshly formatted you got > ~150 kBytes/sec, after a few weeks you had only ~30 kBytes/sec > performance. I was just joking... :-) FFS was built with knowlege of the Berkeley Fast Fast System. It does attempt to avoid excessive fragmentation, though it is somewhat less important in a single-user machine. Good partitioning decisions help reduce fragmentation problems a lot. > The Sun filesystem also has tools > for crash recovery; too often I've heard the only tool available > for Amiga FS recovery is diskdoctor followed by a format. There's also DiskSalv. -- You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software. Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
dca@kesmai.COM (David C. Albrecht) (10/22/88)
In article <5030@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > > >Miniscribe 3053 5.25" 40meg, CPU=68030, 32bit memory, FFS , Commodore 2090 > >Commodore A2090 is a DMA controller (ST-506) > >r/w speed: buf 32768 bytes, rd 84562 byte/sec, wr 34492 byte/sec > > Please note that the Minscribe is, I believe, a 40 ms or maybe slower drive, > unlike the Quantum 40S's you were using above. Also note that the speed of > a 2090 may well be faster using SCSI than St506. > Not to disagree with the other points in your article, I wanted to correct this one point of information. The Miniscribe 3053 is a fairly high performance drive 44M 25msec access. The 3650 is 40M 61msec access, probably the one you are confusing it with. David Albrecht
joe@cbmvax.UUCP (Joe O'Hara) (10/23/88)
In article <193@kesmai.COM> dca@kesmai.COM (David C. Albrecht) writes: >In article <5030@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > > > > >Miniscribe 3053 5.25" 40meg, CPU=68030, 32bit memory, FFS , Commodore 2090 > > >Commodore A2090 is a DMA controller (ST-506) > > >r/w speed: buf 32768 bytes, rd 84562 byte/sec, wr 34492 byte/sec > > > > Please note that the Minscribe is, I believe, a 40 ms or maybe slower drive, > > unlike the Quantum 40S's you were using above. Also note that the speed of > > a 2090 may well be faster using SCSI than St506. > > >Not to disagree with the other points in your article, I wanted to correct >this one point of information. The Miniscribe 3053 is a fairly high >performance drive 44M 25msec access. The 3650 is 40M 61msec access, >probably the one you are confusing it with. I'm not familiar with the Miniscribe 3053, but I do use a Quantum ProDrive40 SCSI daily. I've run the A2090 and FFS on a variety of ST506 and SCSI drives, since we try to maintain a "representative sample" of the marketplace. The Quantum literally screams in comparison to other drives at its nominal access. It's up to 4 times faster than other SCSIs here (differential varies) and of course leaves ST506 units standing still. The significant difference is its cache buffer. A more telling performance comparison would have been for all controllers working on the same drives. -- ======================================================================== Joe O'Hara || Comments represent my own opinions, Commodore Electronics Ltd || not my employers. Any similarity to Software QA || to any other opinions, living or dead, || is purely coincidental. ========================================================================
jdow@gryphon.CTS.COM (J. Dow) (10/24/88)
In article <12391@steinmetz.ge.com> perley@rocky.steinmetz.ge.com (Donald P Perley) writes: >In article <10150@cup.portal.com> thad@cup.portal.com (Thad Thad Floryan) writes: >>Following are some most-interesting disk performance results. > >> The object of the comparisons are to show that "True DMA" controllers >> are not always the best. In fact, the fastest times were obtained using >> boards that use no DMA, instead using polled I/O to read/write data. >> These were early tests and are not the fastest times obtained. >> These tests show the difference between the non DMA boards and DMA boards, > > > ............ a bunch of benchmarks ............... > >These show good data rates... GREAT! > >As comparisons between DMA and non-DMA, they show that: > > > non-DMA is faster than DMA > > OR > > Quantum pro-drives are faster than Seagate ST251-1 or Miniscribe > 3053. > > OR > > SCSI is faster than ST506 > > OR > > The 2090 design is lacking in some other respect. > > > > >Somehow, with all those variables involved, dma/non-dma doesn't jump >out as the clear explanation. > Well, now - one of the things that affects disk speed most dramatically is the hard format interleave. If you take a drive optimized to run at best speed on say the StarDrive and hook it to a HardFrame controller you'll hardly see any speed change at all. But if you hard format the drive and experiment to find the best interleave for your particular controller setup you will likely see a very dramatic speedup of at least 2:1. Another large factor is seek time. And with the way SCSI drives work it is nearly impossible to separate seeks from pure data access within a track. hence all comparisons must be done with the same SCSI drive (and code revision of the SCSI controller code) in order to make any sense at all. Then the benchmarker must reformat the drive, first to the controller card manufacturer's suggested parameters for hard interleave and then to several others to find the optimum. (StarDrive actually slows down with 1:1 interleave. HardFrame seems to speed up all the way to 1:1 on my adaptec controller. (I am not about to kill the ST277N for tests but indications are it is about the same to a trifle faster.)) ANother thing to beware of in comparing drives is on board cache memory effects. Usually when accessing a drive to load a program you are not pulling data from the cache. So it will offer no perceptable speedup there. For a compile, however, a cache can make a heck of a lot of difference. This is why drive benchmarking and raw transfer rate figures are a tad hazardous when taken alone. They do not often indicate what a user's perceptions of speed might. {@_@} -- Sometimes a bird in the hand leaves a sticky deposit. Perhaps it were best it remain there in the bush with the other one. {@_@} jdow@bix (where else?) Sometimes the dragon wins. Sometimes jdow@gryphon.CTS.COM the knight. Does the fair maiden ever {backbone}!gryphon!jdow win? Surely both the knight and dragon stink. Maybe the maiden should suicide? Better yet - she should get an Amiga and quit playing with dragons and knights.
ricks@iscuva.ISCS.COM (Rick Schaeffer) (10/24/88)
Using a Standard Amiga 2000 and 2090 controller (no 68020) I have seen diskperf (NOT diskperfa!) numbers of 525k/sec using a rhodime 68 meg SCSI drive (3 1/2 inch, 24ms seek). I fully expect numbers upwards of 800k/sec with the Quantum drives as I know Larry Phillips got numbers that high with a CDC Wren IV drive. AGAIN...I do not have a 68020. -- Rick Schaeffer UUCP: uunet!iscuva!ricks ISC Systems Corp. ricks@iscuva.ISCS.COM Box TAF-C8 Phone: (509)927-5114 Spokane, WA 99220