IO91461@MAINE.BITNET (Tom Nezwek) (03/26/91)
Does anyone have an ICD hd controler and wish to comment on its
performance? Dperf2 results? The reason I ask is that this is a
very cheap controler ($129) and a friend of mine is looking for a
cheap/fast controler. In fact Manta, a new Amiga Mail order dealer,
said that diskspeed tests indicated that the ICD Outperformed the
GVP series II by a good margin and blew away the Trump Card Pro.
The salesman from Manta claims that the Trump Card Pro is actually
slower than most of the other, CHEAPER controllers and that to get
the 1.9 meg per sec you need a multi-thousand dollar 20 mega-bit hd.
On a side note, I tested my HardFrame 2000 against a GVP series II
controller and the HF was about 100k per second faster and had 200 more
seeks per sec. (I used the same hd on each controller to aviod
inconsistancies). In 33mhz accelerated mode, my Hardframe increased
its lead over the GVP series II.
Sorry to get side-tracked but I suspect a lot of people want to know
which controllers are really faster than others.. Rather than the
typical mail order shop which follows the following guideline:
"The controller in stock is always the fastest one available.." :)
-Tom Nezwekpk@wet.UUCP (Philip King) (03/29/91)
In article <91084.191834IO91461@MAINE.BITNET> IO91461@MAINE.BITNET (Tom Nezwek) writes: > > Does anyone have an ICD hd controler and wish to comment on its >performance? Dperf2 results? The reason I ask is that this is a Well, I have an 'ADscsi 2000', or as they used to call it an 'Advantage 2000' SCSI host adaptor. I use it with a Imprimis/Seagate 94350-230S/ ST-1239N 200 Meg. drive, which is rated at 15ms access. While I don't seem to have the figures handy, it seemed to peak out at somewhere around 600k reads, on my unaccelerated A2000. This seems to jibe fairly closely with the readings ICD publishes using Quantum drives of similiar performance. In those specs, it shows the ICD to be faster than nearly every other controller shown (which includes the GVP II, Wordsync, Trumpcard, 2091, and others) in most parameters. Since the ICD is not a DMA device, and since it uses data caching, the specs are particularly impressive on an accelerated Amiga. The only card that had any significant number of parameters where it occasionally beat the ICD (according to their tests) was the HardFrame. On the other hand, someone mentioned recently in one of the Amiga newsgroups, that because of the algorhythm that ICD uses for caching, some bad stuff could happen if the cpu happens to crash at certain moments. I don't know much about that. I don't have much experience with a _good_ DMA controller (the A2090 I had before doesn't qualify!), so I don't know what the differences would be. I do notice with the ICD that screen updates don't appear to happen until the transfer/directory scan finishes. This may be due to the fact that non-DMA controllers tie up the CPU more. The reason I bought the ICD was the price, the (reputed) speed, and the removeable-media support. Before anyone else, ICD claimed to support auto-diskchange, and to this day I believe they are the only ones who say you can interchange _differently partitioned_ Syquest cartridges without having to restart everything. Unfortunately, the documentation I received with my board is pretty sketchy...one of the few that comes close to rivalling Commodore in that respect, unfortunately. By the way, I tested the speed with Diskspeed 3.1, which is by all accounts a superior benchmark program to Dperf2. Khalid Aldoseiri, who wrote Dperf and frequents CI$, noted some of its limitations himself, such as choking at very high data-transfer rates. I believe Diskspeed 3.1 is either PD or shareware, and commonly available. It might help to have a standard frame of reference for these comparisons. > > > -Tom Nezwek Philip pk@wet.uucp {ucsfcca,claris,hoptoad}!wet!pk
daveh@cbmvax.commodore.com (Dave Haynie) (04/03/91)
In article <2254@wet.UUCP> pk@wet.UUCP (Philip King) writes: >I do notice with the ICD that screen updates don't appear to happen until the >transfer/directory scan finishes. This may be due to the fact that non-DMA >controllers tie up the CPU more. Sure 'nuf. And if the ICD that's shipping is the same design as the one we tested last year on the A3000, it's using up ALL the CPU time during disk reads. Even during seeks. It triggered the A3000's default timeout of just over 8us (that's about 200 68030 wait states). No functional problem on production A3000s, which enable to longterm bus error timeout at 1/4 sec, but an awful waste of your CPU time. The A2091 uses around 40% of the CPU time during a disk transfer, the A3000 about 6%. >The reason I bought the ICD was the price, the (reputed) speed, and the >removeable-media support. That is the fastest way to run a hard disk, if all you care about is disk performance (eg, CPU time doesn't limit you anywhere). This technique is very popular on single-tasking systems like PClones and Macs. >By the way, I tested the speed with Diskspeed 3.1, which is by all >accounts a superior benchmark program to Dperf2. It really is. DPerf doesn't have enough grain at higher speeds, and will apparently die if it goes too fast. Mike Sinz could fill in all the details. One interesting test of SYSTEM performance is to run DiskSpeed and Dhrystone 2.1 at the same time. What's really needed, though, is a simple "remaining CPU time" mode in DiskSpeed, so you can not only guage the disk performance, but the amount of CPU time you're paying for that speed. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
jesup@cbmvax.commodore.com (Randell Jesup) (04/04/91)
In article <2254@wet.UUCP> pk@wet.UUCP (Philip King) writes: >In article <91084.191834IO91461@MAINE.BITNET> IO91461@MAINE.BITNET (Tom Nezwek) writes: >> >> Does anyone have an ICD hd controler and wish to comment on its >>performance? Dperf2 results? The reason I ask is that this is a > >Well, I have an 'ADscsi 2000', or as they used to call it an 'Advantage >2000' SCSI host adaptor. I use it with a Imprimis/Seagate 94350-230S/ >ST-1239N 200 Meg. drive, which is rated at 15ms access. > >While I don't seem to have the figures handy, it seemed to peak out >at somewhere around 600k reads, on my unaccelerated A2000. This seems >to jibe fairly closely with the readings ICD publishes using Quantum >drives of similiar performance. I would expect it to be in the same range as the other people using Quantums, since the base hardware is the same, and for larger transfers the speed is basicly limited by the speed at which the bits come off the platter (assuming you have a controller/processor that can keep up - most can). > In those specs, it shows the ICD to >be faster than nearly every other controller shown (which includes the >GVP II, Wordsync, Trumpcard, 2091, and others) in most parameters. Since >the ICD is not a DMA device, and since it uses data caching, the specs >are particularly impressive on an accelerated Amiga. The only card that >had any significant number of parameters where it occasionally beat the >ICD (according to their tests) was the HardFrame. Once again, see above. One thing that current disk performance modules don't do well is measure cpu usage (the diskspeed "cpu contention" thing is pretty useless, since it's a busy-wait at priority 0, and the cpu-intensive transfers occur from higher-priority tasks). DMA contention is a good testing idea, and does affect cpu-bound controllers to some degree. >On the other hand, someone mentioned recently in one of the Amiga >newsgroups, that because of the algorhythm that ICD uses for caching, >some bad stuff could happen if the cpu happens to crash at certain >moments. I don't know much about that. I don't have much experience >with a _good_ DMA controller (the A2090 I had before doesn't qualify!), What do you mean by caching? there are several different things: cpu caching of data from memory in a cache, drives with sector caches on them used to preread data or hold data already read, and cached controllers which are like the drive caches, but the memory is on the card (a bit like a fixed number of addbuffers). CPU caching shouldn't cause any problems with ICD. >so I don't know what the differences would be. I do notice with the >ICD that screen updates don't appear to happen until the transfer/directory >scan finishes. This may be due to the fact that non-DMA controllers >tie up the CPU more. Right. I think you'll find that you're hitting close to 100% CPU usage (at high priority) when doing disk IO. Acceptable to some people, unacceptable to others (such as in multimedia it can be annoying, running animations, etc). Have you tested serial response (dropped characters) when doing heavy disk I/O? BTW, I do believe that IDE drives will show up as slightly faster in some cases, at the cost of massive amounts of CPU overhead (on reasonably fast CPUs, they can stay ahead of the interface, and there's less setup/protocol overhead to start a transfer. But they kill multitasking performance to do this.) >The reason I bought the ICD was the price, the (reputed) speed, and the >removeable-media support. Before anyone else, ICD claimed to support >auto-diskchange, and to this day I believe they are the only ones who >say you can interchange _differently partitioned_ Syquest cartridges >without having to restart everything. Should be possible, though a bit tricky. Long-term plans here are to modify the rdb standard/implementation to make that easy for everyone. >By the way, I tested the speed with Diskspeed 3.1, which is by all >accounts a superior benchmark program to Dperf2. Khalid Aldoseiri, >who wrote Dperf and frequents CI$, noted some of its limitations >himself, such as choking at very high data-transfer rates. I believe >Diskspeed 3.1 is either PD or shareware, and commonly available. It >might help to have a standard frame of reference for these comparisons. Diskspeed is far better, especially for fast drives. I dumped diskperf (not that I liked it before this) when the new 2.0 ramdisk was so fast that diskperf tried to divide bytes transferred by 0 ticks. (It does ~6-6.5 Mb/s on my A3000 nowadays). It also said my changes had produced a 10x improvement in speed for exnext, when my own exnext benchmark showed more like 10-20% (at the time). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
rbabel@babylon.rmt.sub.org (Ralph Babel) (04/04/91)
In article <2254@wet.UUCP>, pk@wet.UUCP (Philip King) writes: > While I don't seem to have the figures handy, it seemed to > peak out at somewhere around 600k reads, on my > unaccelerated A2000. > [...] > In those specs, it shows the ICD to be faster than nearly > every other controller shown (which includes the GVP II, > Wordsync, Trumpcard, 2091, and others) in most parameters. 600k reads on a standard A2000 is no problem for the A2091 or GVP's Series-II (don't know about Wordsync or Trumpcard). > Before anyone else, ICD claimed to support > auto-diskchange, GVP have supported removable media for >2 years now. Ralph
rbabel@babylon.rmt.sub.org (Ralph Babel) (04/04/91)
In article <20352@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes: >> On the other hand, someone mentioned recently in one of >> the Amiga newsgroups, that because of the algorhythm that >> ICD uses for caching, some bad stuff could happen if the >> cpu happens to crash at certain moments. > > What do you mean by caching? there are several different > things: cpu caching of data from memory in a cache, drives > with sector caches on them used to preread data or hold > data already read, and cached controllers which are like > the drive caches, but the memory is on the card (a bit > like a fixed number of addbuffers). CPU caching shouldn't > cause any problems with ICD. True. Philip was referring to ICD's deferred writing of disk sectors, however. Ralph