schabacker@frocky.dec.com (Tim, posting for C. Balzer) (10/20/88)
Hi folks, I've just completed a series of HD controller tests for a local distributor, who supplied my with a GVP Impact 2000, a Supra 2000 DMA controller and a Rodime 3085S (70MB, 28ms) hard disk. I also tested my A2090 with the same hard disk, while the distributor tested it with a Cltd controller. Due to some problems with the 5.1 Supra software, I was unable to test this controller with FFS (FastFileSystem), so I left it out of the competition. Feel free to take a look at the results below, make your own conclusions and then read mine at the end of this article. All the results were obtained by using the unmodified Diskperf program from Fish disk #48. Where not otherwise stated, Blitzdisk, a cache program (sorta Facc-II for hard disks) by Microsmiths, was run with 200 reserved blocks (=100KB) with the DIRONLY option enabled (only FileInfoBlocks are cached, no FileData). My standard environment consists of AmiCron, Facc-II, the memory clock (mclk) by Mike Meyer, an AntiVirus program and in this special case a full size perfmon (Performance monitor by Dale Luck). I'm running these things from a 3MB (2MB FastMem) B2000, with a 680 * 274 * 2 PAL WB screen, using Kickstart 1.2 and Workbench 1.3 (omega 9, since even CBM Germany doesn't seem to have the final release, gak). Running "alone" means all background tasks killed and priority of the diskperf CLI raised to 3 (This way you can compare these results to some extend with monotasking systems). ---------- GVP Impact A2000 with Rodime 3085S, FFS. With Blitzdisk, standard environment: File create/delete: create 15 files/sec, delete 29 files/sec Directory scan: 84 entries/sec Seek/read test: 66 seek/reads per second r/w speed: buf 512 bytes, rd 26479 byte/sec, wr 25954 byte/sec r/w speed: buf 4096 bytes, rd 145635 byte/sec, wr 113975 byte/sec r/w speed: buf 8192 bytes, rd 163840 byte/sec, wr 124830 byte/sec r/w speed: buf 32768 bytes, rd 262144 byte/sec, wr 201649 byte/sec Without Blitzdisk: File create/delete: create 15 files/sec, delete 30 files/sec Directory scan: 87 entries/sec Seek/read test: 66 seek/reads per second r/w speed: buf 512 bytes, rd 26479 byte/sec, wr 25954 byte/sec r/w speed: buf 4096 bytes, rd 145635 byte/sec, wr 113975 byte/sec r/w speed: buf 8192 bytes, rd 174762 byte/sec, wr 145635 byte/sec r/w speed: buf 32768 bytes, rd 262144 byte/sec, wr 201649 byte/sec Without Blitzdisk, running "alone": File create/delete: create 16 files/sec, delete 31 files/sec Directory scan: 104 entries/sec Seek/read test: 75 seek/reads per second r/w speed: buf 512 bytes, rd 28187 byte/sec, wr 27306 byte/sec r/w speed: buf 4096 bytes, rd 174762 byte/sec, wr 131072 byte/sec r/w speed: buf 8192 bytes, rd 174762 byte/sec, wr 154202 byte/sec r/w speed: buf 32768 bytes, rd 291271 byte/sec, wr 201649 byte/sec ---------- CBM A2090 controller with Rodime 3085S, FFS. With Blitzdisk, standard environment: File create/delete: create 16 files/sec, delete 52 files/sec Directory scan: 87 entries/sec Seek/read test: 60 seek/reads per second r/w speed: buf 512 bytes, rd 22598 byte/sec, wr 25954 byte/sec r/w speed: buf 4096 bytes, rd 174762 byte/sec, wr 137970 byte/sec r/w speed: buf 8192 bytes, rd 291271 byte/sec, wr 187245 byte/sec r/w speed: buf 32768 bytes, rd 524288 byte/sec, wr 262144 byte/sec Without Blitzdisk: File create/delete: create 15 files/sec, delete 47 files/sec Directory scan: 87 entries/sec Seek/read test: 94 seek/reads per second r/w speed: buf 512 bytes, rd 62415 byte/sec, wr 25700 byte/sec r/w speed: buf 4096 bytes, rd 163840 byte/sec, wr 137970 byte/sec r/w speed: buf 8192 bytes, rd 262144 byte/sec, wr 187245 byte/sec r/w speed: buf 32768 bytes, rd 436906 byte/sec, wr 262144 byte/sec Without Blitzdisk, running "alone": File create/delete: create 16 files/sec, delete 50 files/sec Directory scan: 104 entries/sec Seek/read test: 109 seek/reads per second r/w speed: buf 512 bytes, rd 70849 byte/sec, wr 27594 byte/sec r/w speed: buf 4096 bytes, rd 174762 byte/sec, wr 154202 byte/sec r/w speed: buf 8192 bytes, rd 291271 byte/sec, wr 201649 byte/sec r/w speed: buf 32768 bytes, rd 524288 byte/sec, wr 262144 byte/sec ---------- Sorry, no Supra today... ---------- C Ltd SCSI-Controller (SCSI_DOS 3.0), FFS, RODIME 3085S. With Blitzdisk buffers 100 dironly, no other tasks. File create/delete: create 10 files/sec, delete 26 files/sec Directory scan: 89 entries/sec Seek/read test: 82 seek/reads per second r/w speed: buf 512 bytes, rd 45990 byte/sec, wr 42974 byte/sec r/w speed: buf 4096 bytes, rd 87381 byte/sec, wr 67216 byte/sec r/w speed: buf 8192 bytes, rd 104857 byte/sec, wr 79437 byte/sec r/w speed: buf 32768 bytes, rd 124830 byte/sec, wr 100824 byte/sec Without Blitzdisk, no other tasks. File create/delete: create 9 files/sec, delete 13 files/sec Directory scan: 82 entries/sec Seek/read test: 73 seek/reads per second r/w speed: buf 512 bytes, rd 42281 byte/sec, wr 42974 byte/sec r/w speed: buf 4096 bytes, rd 84562 byte/sec, wr 65536 byte/sec r/w speed: buf 8192 bytes, rd 100824 byte/sec, wr 81920 byte/sec r/w speed: buf 32768 bytes, rd 119156 byte/sec, wr 100824 byte/sec ---------- (Here's an example for a "good" ST-506 drive) CBM A2090 controller with Micropolis 1325 (70MB ST-506), FFS. With Blitzdisk, standard environment: File create/delete: create 16 files/sec, delete 55 files/sec Directory scan: 98 entries/sec Seek/read test: 57 seek/reads per second r/w speed: buf 512 bytes, rd 22028 byte/sec, wr 27306 byte/sec r/w speed: buf 4096 bytes, rd 131072 byte/sec, wr 113975 byte/sec r/w speed: buf 8192 bytes, rd 187245 byte/sec, wr 131072 byte/sec r/w speed: buf 32768 bytes, rd 218453 byte/sec, wr 163840 byte/sec Without Blitzdisk, running "alone": File create/delete: create 16 files/sec, delete 50 files/sec Directory scan: 102 entries/sec Seek/read test: 96 seek/reads per second r/w speed: buf 512 bytes, rd 62415 byte/sec, wr 28493 byte/sec r/w speed: buf 4096 bytes, rd 131072 byte/sec, wr 119156 byte/sec r/w speed: buf 8192 bytes, rd 187245 byte/sec, wr 154202 byte/sec r/w speed: buf 32768 bytes, rd 238312 byte/sec, wr 174762 byte/sec ---------- Now for my resumee: The clear winner (speedwise) is the A2090 by Commodore, something that doesn't surprise me, but may confuse some of you. But if you take a look at way the 2090 does it's thing (A500/2000 Tech. Ref. Manual), it get's clearer. The only possible competition could be the Supra controller, and I promise that I'll suply the results of this beast as soon as I get it (the software that is) to work. An interresting tidbit seems to be the fact that Blitzdisk only helps "slow" disks/controllers while "fast" ones suffer from the obvious overhead. I still have Blitzdisk running, trading transfer speed for less disk access and faster directory searches. Some things to consider: - Cltd is creeping even with FFS and their SCSI-DOS 3.0, due to their non DMA concept, but they've got the most flexible controller with the most (non HD) SCSI applications. Their software was a pain userfriendlywise, and to some extend still is. Data transfer with this controller is the CPU's job, which really hurts multitasking. - GVP has the ideal combination of a RAM board and a hard disk controller, their speed is reasonable and they seem to be as immune as possible to severe (and deep) overscan. Their software is straightforward, not too userfriendly but painless. And for a "half" DMA style controller, their CPU usage is pretty low and acceptable. - Supra has the most userfriendly software, but this is also their biggest caveat. The usage of Supramount (their replacement for binddrivers and mount) the need to partition your hard disk and the enforced device names (DH0:, DH1:. etc.) with Supraformat may be helpful for a beginner but can be very disturbing for a "pro" (I know they were for me, hell, I couldn't even install a non Supra partition with their 5.1 software). A bug plus is the fact that Supra is the first company to support the "HardBlock" standard HD identification method proposed by CBM, which will allow the usage of a HD formatted by controller X with controller Y without the need to reformat it. But one thing that really made my cortex ripple is the fact that during data transfer this controller STOPs ALL multitasking. Yuck. And this with a MC68440 DMA chip on their board. <Head shaking in amazement> - Commodore did quite a good job on the 2090, despite all the critisism I heard on this and other forums. All HD DMA vs. Video DMA problems were solved with Fastmemfirst and their latest driver software, although the transfer speed suffers badly with severe (deep) overscan. But I'm willing to bet some vital organs, that the 2090A will be even faster, due to their new onboard driver and enhanced firmware. And from what I hear in this newsgroup, the prep kludge seems to be more userfriendly now. The real nice thing about the 2090x is the fact that it transfers data via "hidden" DMA, with nearly no loss in CPU performance. And that's what an Amiga (or any multitasking system) controller should do. And as a last measure, compare the pricing of these products. I really hope that this wasn't too long, and I don't have any affiliation(sp???) with one of the mentioned companies, nor did they bribe me (although I'd wish someone would :-). Eagerly awaiting your comments, - <CB> -- _ _ / / | \ \ <CB> aka Christian Balzer - The Software Brewery - < < |-< > decwrl!frambo.dec.com!schabacker OR schabacker@frambo.dec.com \ \_ |_/ / CIS: 71001,210 (be brief!), Phone: +49 6150 4151 ------------ Snail: Im Wingertsberg 45, D-6108 Weiterstadt, F.R.G. "The first cut won't hurt at all, the second only makes you wonder, the third will have you at your knees, you start bleeding, I start screaming" From the song "Duel" by Propaganda.
space@sns.UUCP (Lars Soltau) (10/24/88)
In article <8810201315.AA19782@decwrl.dec.com> schabacker@frocky.dec.com (Tim, posting for C. Balzer) writes: >Where not otherwise stated, Blitzdisk, a cache program (sorta >Facc-II for hard disks) by Microsmiths, was run with 200 reserved >blocks (=100KB) with the DIRONLY option enabled (only FileInfoBlocks >are cached, no FileData). If you mount a partition, which you have to do if you are using FFS, you can include those two lines into your Mountlist: Buffers = <n> BufMemType = 1 These Buffers are 512 bytes each and from my experience I suppose that they are used for File Info Blocks only, too. So what is the need for Blitzdisk? BTW, if someone could enlighten me about the purpose of the "BufMemType" entry, I'd much appreciate it. I have tried both 1 and 0, and each time the buffers are allocated from FastMem, which of course is the right thing to do, I guess, but then what the heck is this BufMemType entry for? I'd very much appreciate any pointers to information about these things, as I have not found details in the RKM manuals or anywhere else. -- Lars Soltau UUCP: ...uunet!unido!sns!space BIX: -- no bucks -- Here's looking at you, kid! -- the Medusa
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/26/88)
:BufMemType = 1 :BTW, if someone could enlighten me about the purpose of the "BufMemType" entry, :I'd much appreciate it. I have tried both 1 and 0, and each time the buffers :are allocated from FastMem, which of course is the right thing to do, I guess, :but then what the heck is this BufMemType entry for? Exactly what it says .. the type of memory that can be used in buffers passed to the trackdisk. MEMF_PUBLIC 1 MEMF_CHIP 2 MEMF_CHIP|MEMF_PUBLIC = 3 MEMF_FAST 4 MEMF_FAST|MEMF_PUBLIC = 5 any memory: 1 (just MEMF_PUBLIC). It depends on the kind of driver you have. Some drivers, like the floppy trackdisk.device, can only utilize CHIP memory and thus BufMemType = 3 (MEMF_PUBLIC|MEMF_CHIP). 0 is private and 1 is public, and since neither CHIP or FAST is specified, both can be used if you specify 0 or 1. (Side note: Theoretically, you should always specify MEMF_PUBLIC and thus should never specify 0). Some add-on 32 bit memory cards (not the C-A one) cannot be DMA'd to and implement another memory type, MEMF_DMA or something like that which must be specified in the BufMemType so the filesystem allocates only DMAable memory for sector buffers. -Matt
ejkst@cisunx.UUCP (Eric J. Kennedy) (10/27/88)
In article <42@sns.UUCP> space@sns.UUCP (Lars Soltau) writes: > >If you mount a partition, which you have to do if you are using FFS, you can >include those two lines into your Mountlist: Okay, I've seen enough people say something of this sort, and the 1.3 Enhancer manual says something like this too, that the first partition on the drive must be the old filesystem. Now, is this really true for all cases or is it only true for the A2090? I have a C.LTD SCSI controller and hard disk on my A1000, and the FFS appears to work OK, even though I have only 1 partition, covering the entire disk. Anyone know for sure? Thanks, -- +-=-=-=-=-=-=-=-=-+ Eric Kennedy | Bush & | ejkst@cisunx.UUCP | Bentsen '88 !! | +-=-=-=-=-=-=-=-=-+
andy@cbmvax.UUCP (Andy Finkel) (10/27/88)
In article <13363@cisunx.UUCP> ejkst@unix.cis.pittsburgh.edu (Eric J. Kennedy) writes: >on the drive must be the old filesystem. Now, is this really true for >all cases or is it only true for the A2090? I have a C.LTD SCSI >controller and hard disk on my A1000, and the FFS appears to work OK, It's only true if your first partition is automounted. If you fire up your hard disk by using the Mount command (rather than binddrivers) you can make the whole thing ffs. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "I first began to lose faith in software engineering when I found out that no two printers were compatible." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/28/88)
:Okay, I've seen enough people say something of this sort, and the 1.3 :Enhancer manual says something like this too, that the first partition :on the drive must be the old filesystem. Now, is this really true for :all cases or is it only true for the A2090? I have a C.LTD SCSI :controller and hard disk on my A1000, and the FFS appears to work OK, :even though I have only 1 partition, covering the entire disk. Anyone :know for sure? If you want to autoboot and have a controller that can autoboot, but also want to run the FFS on your HD, then your setup must be that the first partition on the HD is under the old file system (OFS). The reason is quite simple: The FFS handler is a file and NOT in rom for 1.3 ... it is not possible to *boot* off the FFS because it can't find the FFS handler because nothing is mounted yet (this is the kind of problem that would make an AI go in circles). This should be clear: The first partition need not be very large. You can make it 3 cylinders, I believe ... just enough to hold the FFS handler and other goodies to Mount the remainder of the disk. If you do NOT want to autoboot, or can't even ... then you will be booting off floppy and can make ALL the partitions on your HD run under FFS. Since I can't autoboot, this is what I do. My particular setup is an A1000, Starboard + Stardrive, and duel HD running FFS on all 5 partitions. -Matt
erickson@cbmvax.UUCP (Lee Erickson) (10/28/88)
In article <8810271754.AA14920@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >:Okay, I've seen enough people say something of this sort, and the 1.3 >:Enhancer manual says something like this too, that the first partition >:on the drive must be the old filesystem. Now, is this really true for >:all cases or is it only true for the A2090? > > If you want to autoboot and have a controller that can autoboot, >but also want to run the FFS on your HD, then your setup must be that the >first partition on the HD is under the old file system (OFS). It is NOT necessary to have a partition with the "old file system" on it to autoboot IF you have a controller that takes advantage of Commodore's new "standard" way of storing the filesystems on the disk. I believe I saw this mentioned on the net previously. -- Lee Erickson - not working with, uucp: {ihnp4|seismo|caip}!cbmvax!erickson or in any way officially representing arpa: cbmvax!erickson@seismo.css.GOV Commodore.
space@sns.UUCP (Lars Soltau) (10/29/88)
In article <5116@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >In article <13363@cisunx.UUCP> ejkst@unix.cis.pittsburgh.edu (Eric J. Kennedy) writes: >>on the drive must be the old filesystem. Now, is this really true for >>all cases or is it only true for the A2090? I have a C.LTD SCSI >>controller and hard disk on my A1000, and the FFS appears to work OK, > >It's only true if your first partition is automounted. If you fire >up your hard disk by using the Mount command (rather than binddrivers) >you can make the whole thing ffs. Even with an A2090 you can use your whole HD with FFS, it ain't clean, but it works: Prep your HD with the first (automounted) partition using only track 2. Then set up your Mountlist with the next partition starting at track 2. Format this partition with FFS. If you now access the automounted partition, you get a "not a dos disk" requester. Don't care, just hit cancel. As long as you don't reformat this partition, the FFS partition is completely safe. When I still had an ST506 HD, I even had a program written by a friend of mine called RenameHD which renames all DHX: devices into HDX:, so that I could still install the FFS partition as DH0:. Now I have an SCSI HD and the automounted partition is called DH2:, so I don't need RenameHD any longer. -- Lars Soltau UUCP: ...uunet!unido!sns!space BIX: -- no bucks -- Here's looking at you, kid! -- the Medusa
schabacker@frambo.dec.com (Tim, posting for C. Balzer) (11/01/88)
Hi folks, Here are the promised results for the Supra controller, as I managed with the help of their tech support to install a FFS partition using the standard mount command. An error in the 5.1 Supra software .ARC file made these tests impossible for the original review. ---------- Supra DMA 2000 controller with Rodime 3085S, FFS. With Blitzdisk, standard environment: File create/delete: create 13 files/sec, delete 43 files/sec Directory scan: 87 entries/sec Seek/read test: 82 seek/reads per second r/w speed: buf 512 bytes, rd 59578 byte/sec, wr 25206 byte/sec r/w speed: buf 4096 bytes, rd 163840 byte/sec, wr 131072 byte/sec r/w speed: buf 8192 bytes, rd 262144 byte/sec, wr 174762 byte/sec r/w speed: buf 32768 bytes, rd 436906 byte/sec, wr 262144 byte/sec Without Blitzdisk: File create/delete: create 13 files/sec, delete 28 files/sec Directory scan: 86 entries/sec Seek/read test: 80 seek/reads per second r/w speed: buf 512 bytes, rd 59578 byte/sec, wr 25206 byte/sec r/w speed: buf 4096 bytes, rd 163840 byte/sec, wr 131072 byte/sec r/w speed: buf 8192 bytes, rd 262144 byte/sec, wr 187245 byte/sec r/w speed: buf 32768 bytes, rd 436906 byte/sec, wr 262144 byte/sec Without Blitzdisk, running "alone": File create/delete: create 15 files/sec, delete 30 files/sec Directory scan: 102 entries/sec Seek/read test: 90 seek/reads per second r/w speed: buf 512 bytes, rd 65536 byte/sec, wr 27594 byte/sec r/w speed: buf 4096 bytes, rd 174762 byte/sec, wr 145635 byte/sec r/w speed: buf 8192 bytes, rd 291271 byte/sec, wr 218453 byte/sec r/w speed: buf 32768 bytes, rd 436906 byte/sec, wr 291271 byte/sec ---------- The above results are relativly close to that of the 2090(a) (about 20% slower), but since the Supra is also a DMA controller, that was to be expected. A major fault in their hardware/software design is IMHO the fact that they "take over" (freeze) the system during data transfer. The 2090(a) currently performs better or equal with a considerably lower CPU and bus usage. Perfmon showed during the Supra diskperfs a solid 100% CPU usage, while the 2090 only used about 50% (with a "standard" usage of 25% in my environment, thats only a 25% additional usage). NO, I'm not the new CBM propaganda department nor a leftover from the dirtspitting Bush campaign, these tests and their results were obtained by an unbribed and free mind. Feel free to do it yourself... To those of you who missed the original (initial) posting or thoughtlessly discarded this brilliant work :-), I offer to email the complete review. InterNet/ARPA style addresses preferred. Keep your comments coming in, - <CB> -- _ _ / / | \ \ <CB> aka Christian Balzer - The Software Brewery - < < |-< > decwrl!frambo.dec.com!schabacker OR schabacker@frambo.dec.com \ \_ |_/ / CIS: 71001,210 (be brief!), Phone: +49 6150 4151 ------------ Snail: Im Wingertsberg 45, D-6108 Weiterstadt, F.R.G. "Another hope, another dream, another truth, installed by the machine" From the song "P-Machinery" by Propaganda.