lphillips@lpami.wimsey.bc.ca (Larry Phillips) (02/26/90)
In <21294@watdragon.waterloo.edu>, mwandel@tiger.waterloo.edu (Markus Wandel) writes: >I've also found that a 68000 based Amiga doesn't really need more than 300K/sec >disk transfer rate. My (homemade) interface goes that fast, and I've found >that all my compiles, Zoo compresses, etc. are now compute bound as shown by >the low duty cycle of the "blips" of the disk activity light. And my >interface isn't even DMA. So don't worry about it... That's your opinion, and you are welcome to stick with it. In my experience, there is a significant difference between a drive that has a DiskSpeed figure of 350K/sec and one that has a DiskSpeed figure of 750K/sec. The faster drive leaves me waiting less on all disk activity, and the whole machine feels snappier. Sure, some programs, even many programs are CPU bound, but certainly not all, and even speedups in loading are welcome around here. Then of course there is the possibility of upgrading to a faster CPU. Maybe you like to muck about changing drives and/or controllers, but most don't. Saying you don't need more than 300K/sec is accurate, but as maningless as saying 'You don't really need a hard drive', which is just as true. -larry -- Gallium Arsenide is the technology of the future; always has been, always will be. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (02/26/90)
I recently received my A2000HD with the Quantum hard drive. I've been
relatively happy with the setup (except for needing to populate the
two meg space on the A2091.) However, I am not happy with the
results of DiskSpeed 3.0. Friends of mine running Kronos 16bit
non-DMA cards with Segate 28ms drives are reporting faster
rates. Shouldn't a DMA card with a 19ms drive perform much better?
Oh, the background processes running concurrently with this
run are: ConMan, QMouse, Handshake, NoClick, Bypass_ARP_fr,
and Bridgeboard [Atime, Amouse, PCDisk.]
I've run the test with none of the above and the results weren't
much better. (At best a few 10k bytes/sec increase -- but not an
accurate reflection of my normal environment anyways.)
The Quantum is rated at 2.0 megabytes/second asynchronious transfer
rate in addition to having a 64k cache. So I doubt the drive slows
the performance. So is this standard? Has Commodore limited a
speed demon? Here is the output from Diskspeed 3.0.
DiskSpeed 3.0 - Copyright (c) 1989,90 by MKSoft Development
Device: dh0:
Test Intensity: High Performance Stress: None
5 Files/s Create
23 Files/s Open/Close
65 Files/s Scan
8 Files/s Delete
185 Seek/Read
Buffer Size 512 4096 32768 262144
--------- --------- --------- --------- ---------
Bytes/s Create 15229 85197 159593 203129
Bytes/s Write 16037 107686 315203 347601
Bytes/s Read 35985 167067 365094 520307
--
John M. Adams --*-- Professional Student on the six-year plan! ///
Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu ///
"Houston, we have a negative on that orbit trajectory." Calvin & Hobbs \\X//mwandel@tiger.waterloo.edu (Markus Wandel) (02/27/90)
I tried replying via mail, but the reply bounced, so I'm posting this... In article <22452@uflorida.cis.ufl.EDU> jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: > > ... > > The Quantum is rated at 2.0 megabytes/second asynchronious transfer > rate in addition to having a 64k cache. So I doubt the drive slows > the performance. So is this standard? Has Commodore limited a > speed demon? > > ... No way a Quantum disk will actually give you 2.0 Megabytes/sec sustained data transfer. This is only the speed rating for its SCSI bus interface, using the asynchronous protocol. It does not account for delays between bursts of data from the drive. You can easily work out the theoretical maximum data transfer rate from your disk's specs, if you have them. For mine, for example: 3600 RPM 27 sectors/track 512 bytes/sector That's 60 revolutions per second at 27*512 bytes readable by one head during one revolution, for an absolute theoretical limit of 829,440 bytes/sec. Many factors detract from this, to the point where I believe the maximum transfer rate possible with this disk is about 500-600 K/sec. I've never seen a Quantum giving more than 650K/sec, so I believe its useable transfer rate is in that area. Some disks come with a claimed "sustained average transfer rate" -- something I would interpret to mean the speed at which you can actually get data from the disk. But for both the SCSI disks I have, it is given incorrectly at something well exceeding the theoretical rate at which data can be read in the first place. I've also found that a 68000 based Amiga doesn't really need more than 300K/sec disk transfer rate. My (homemade) interface goes that fast, and I've found that all my compiles, Zoo compresses, etc. are now compute bound as shown by the low duty cycle of the "blips" of the disk activity light. And my interface isn't even DMA. So don't worry about it... Markus Wandel mwandel@tiger.waterloo.edu (519) 884-9547
mks@cbmvax.commodore.com (Michael Sinz - CATS) (02/27/90)
In article <22452@uflorida.cis.ufl.EDU> jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: > >I recently received my A2000HD with the Quantum hard drive. I've been >relatively happy with the setup (except for needing to populate the >two meg space on the A2091.) However, I am not happy with the >results of DiskSpeed 3.0. Friends of mine running Kronos 16bit >non-DMA cards with Segate 28ms drives are reporting faster >rates. Shouldn't a DMA card with a 19ms drive perform much better? >Oh, the background processes running concurrently with this >run are: ConMan, QMouse, Handshake, NoClick, Bypass_ARP_fr, >and Bridgeboard [Atime, Amouse, PCDisk.] >I've run the test with none of the above and the results weren't >much better. (At best a few 10k bytes/sec increase -- but not an >accurate reflection of my normal environment anyways.) > >The Quantum is rated at 2.0 megabytes/second asynchronious transfer >rate in addition to having a 64k cache. So I doubt the drive slows >the performance. So is this standard? Has Commodore limited a >speed demon? Here is the output from Diskspeed 3.0. Well, the Quantum specs say 2.0 megabytes/second. And that is the fastest *ANY* async SCSI-1 device can go. Also, it is only a "burst" rate that they quote. If you happen to not count the time it takes to send the command to the drive (not on the computer, but on the SCSI) and don't want too much information and all of it is in the cache then the Quantum may just happen to send 32K of data at the maximum transfer rate. As you might know, the drive can only get data to the machine at the speed the data comes from the disk spinning below the heads. If you calculate this from the numbers given on Quantum drives, you will notice that the sustained data transfer rate can *NOT* be that fast. In fact, I would guess that it is on the order of maybe 700K to 850K/second of RAW data transfer. (I don't have all of the specs) Also, the Quantum drives used variable sectors/track technology that gives them greater liniar bit density on the outer tracks than other drives. This also means that the data transfer would be faster in the outer tracks. (My Q40 shows ~500K at the inside and ~580K at the outside.) > >DiskSpeed 3.0 - Copyright (c) 1989,90 by MKSoft Development > >Device: dh0: > >Test Intensity: High Performance Stress: None > > 5 Files/s Create > 23 Files/s Open/Close > 65 Files/s Scan > 8 Files/s Delete > > 185 Seek/Read > >Buffer Size 512 4096 32768 262144 >--------- --------- --------- --------- --------- >Bytes/s Create 15229 85197 159593 203129 >Bytes/s Write 16037 107686 315203 347601 >Bytes/s Read 35985 167067 365094 520307 Well, there is one other thing you should note: DiskSpeed != DiskPerf. DiskSpeed numbers are generated in a more accurate method and are based on total time (from OS call to return) With DiskSpeed3.0 on my home system, with a A2620, fast-rom, and a A2091 and a fast drive (faster than the Quantums) I get values in the ~800K to ~900K per second range in the 262144 column and about ~500K to ~550K in the 32768 column. You will notice a major speed increase with an 2620 or 2630 card, and even more noticeable with the ROM moved into 32-bit RAM as there is some file-system and dos.library overhead that is also part of the equation. >-- >John M. Adams --*-- Professional Student on the six-year plan! /// >Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu /// >"Houston, we have a negative on that orbit trajectory." Calvin & Hobbs \\X// /----------------------------------------------------------------------\ | /// Michael Sinz -- CATS/Amiga Software Engineer | | /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | | /// | |\\\/// "I don't think so," said Ren'e Descartes. | | \XX/ Just then, he vanished. | \----------------------------------------------------------------------/
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (02/27/90)
In <SB*#6|&@rpi.edu>, jvmiller@ptolemy0.rdrc.rpi.edu (Jim Miller) writes: > >How do you move the ROM into the 32-bit RAM? >I have a 2500/30 and using Diskperf I am getting about 340K reads >with 32K buffers. This seems a little slow since you are getting >500K reads with the 2620. The performance you get depends a LOT on the controller/drive. (that's controller, as in not the 2090 or 2091), and there are controllers out there that will not do much better than 340K/sec. You can put the ROM into 32 bit ram with SetCPU, using the 'cardrom' option. It takes a filename as an argument. Mine specifies 'S:CardRomList', which contains the line.. 0x202 0x01 0x10000 0x8000 0x4000 CBM_2090A_Disk_Controller This may vary for the 2091. -larry -- Gallium Arsenide is the technology of the future; always has been, always will be. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jvmiller@ptolemy0.rdrc.rpi.edu (Jim Miller) (02/27/90)
> > You will notice a major speed increase with an 2620 or 2630 card, and > even more noticeable with the ROM moved into 32-bit RAM as there is some > file-system and dos.library overhead that is also part of the equation. > > /----------------------------------------------------------------------\ > | /// Michael Sinz -- CATS/Amiga Software Engineer | > | /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | > | /// | > |\\\/// "I don't think so," said Ren'e Descartes. | > | \XX/ Just then, he vanished. | > \----------------------------------------------------------------------/ How do you move the ROM into the 32-bit RAM? I have a 2500/30 and using Diskperf I am getting about 340K reads with 32K buffers. This seems a little slow since you are getting 500K reads with the 2620. Jimmy Miller
perley@trub.crd.ge.com (Donald P Perley) (02/28/90)
In article <1168@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <21294@watdragon.waterloo.edu>, mwandel@tiger.waterloo.edu (Markus Wandel) writes: >>I've also found that a 68000 based Amiga doesn't really need more than 300K/sec >>disk transfer rate. My (homemade) interface goes that fast, and I've found >>that all my compiles, Zoo compresses, etc. are now compute bound as shown by >>the low duty cycle of the "blips" of the disk activity light. And my >>interface isn't even DMA. So don't worry about it... Well.... One of the advantages of a DMA interface is that is doesn't load down the CPU as much so compress, etc would be able to run faster, and a higher transfer rate would be useful. I think loading programs, iff files, etc and opening drawers (if using workbench) make up most of the "feel" of how fast a disk operates, and they aren't especially CPU intensive operations. The original poster was unclear whether he was more concerned with transfer speed or the other stuff like directory scanning, file creation etc. He also didn't say whether his friend with the 2090 (which he said was faster than his 2091) has fast memory. That could make a difference in performance, as would the "addbuffer" count. -don perley perley@trub.crd.ge.com
akcs.clemon@wcbcs (Craig Lemon) (03/01/90)
Those values that people have gotten on a DiskSpeed test on a Quantum 40S
have really been bad. I'm running a Microbotics HardFrame 2000 with a
Quantum 105S and I get about 700K/sec or a little more on the 200K+ buffer
size. My other values range from 300K upwards. What kind of values have
other people gotten from their HardFrames?
-- _
Craig Lemon // |_|
Kitchener, Ontario \X/ | | M I G A
Amiga 2000 -- 2400 bps -- AmigaUUCP 0.50b
..!watmath!xenitec!wcbcs!lemsys!clemon
..!watmath!xenitec!wcbcs!AKCS.clemon
^^ Not Reliable Yet stan@teroach.UUCP (Stan Fisher) (03/02/90)
In article <1170@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >You can put the ROM into 32 bit ram with SetCPU, using the 'cardrom' option. It >takes a filename as an argument. Mine specifies 'S:CardRomList', which contains >the line.. > >0x202 0x01 0x10000 0x8000 0x4000 CBM_2090A_Disk_Controller > >This may vary for the 2091. ^^^^ Anybody know what the entry needs to be for the 2091????? Stan Fisher - stan@teroach.phx.mcd.mot.com - asuvax!mcdphx!teroach!stan Motorola Microcomputer Division, Tempe, Arizona - Voice (602) 438-3228 Call our User Group BBS "M.E.C.C.A." running Atredes 1.1 @ (602) 893-0804 There... two sigs'll make this stupid PNEWS take my short reply!!!! Stan Fisher - stan@teroach.phx.mcd.mot.com - asuvax!mcdphx!teroach!stan Motorola Microcomputer Division, Tempe, Arizona - Voice (602) 438-3228 Call our User Group BBS "M.E.C.C.A." running Atredes 1.1 @ (602) 893-0804