Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!widener!dsinc!bagate!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.sys.amiga.hardware Subject: Re: Anyone own an ICD SCSI hd controler? Others mentioned.. Message-ID: <20352@cbmvax.commodore.com> Date: 4 Apr 91 03:12:22 GMT References: <91084.191834IO91461@MAINE.BITNET> <2254@wet.UUCP> Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Organization: Commodore, West Chester, PA Lines: 93 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") ;-)