clemon@lemsys.UUCP (Craig Lemon) (12/03/90)
OK, thanks go to all who responded. This is my summary so far of replies received and thoughts about each... >That mount list entry is PRETTY strange. >SizeBlock 128? Also, it's using the 1 surface let the SCSI figure >it out option. If you can find the surfaces/cylinders/blockspertrack/ >etc etc etc and put it it, there won't be any lag time for translation >(at least from what I've heard FOAF :) I only have the info for a >Quantum ProDrive 40S, else I'd post it. Of course, my advice >is to get a Kronos! :) >-- >John M. Adams --**-- Professional Student on the eight-year plan! /// Well...The software set all the mountlist options for me with defaults from the drive. I also know/have heard that SCSI doesn't need all of the heads/cylinders etc... info because SCSI works on block numbers anyways. To late to buy a Kronos :-) >Interleave that sucker, now! I don't know about maxtransfer, but the short >pulses you see when loading a large file are caused by the computer >having to wait for disk latency. Well I agree that the problem certainly seems like an interleave problem, the HardFrame shouldn't need an interleaved drive. It's performance is supposed to be so much greater than that of any drive. I have also had responses stateing that the problem may be that it _is_ interleaved (other than 1:1 like it is now). This may be something to look into further. I'm not up to re-formatting quite yet however. >> MaxTransfer : 131072 >MaxTransfer = 130560 > >You'll be a little safer to drop this down to 130560 to prevent possible >problems. I will give this a try shortly. I really don't see how less than 1K difference in MaxTransfer can make such a difference. BTW, the 131072 value was a software (RDPrep) default. >>(BTW, I use addbuffers dh0: 30 in my startup). > >30 buffers isn't much for such a large drive. I use 1000. I tried this, no effect. Also mentioned in this reply was getting a new version of RDPrep. Why should the version of the RDBlock program make such a performance difference? Definitely worth looking into as I like to keep as current as I can. I purchased my HardFrame exactly a year ago, just to give you a concept of it's age. >You should be seeing numbers a LOT higher than this. With a CDC Wren III >I was getting about 600-700 KB/sec (measured with DiskSpeed, it's a lot >more accurate and consistant than anything else out there). With a >Quantum 105 it's about 750-850 KB/sec. This is with a Hardframe and the >A2620 card, for a 68010 the numbers will be a little lower. > >First guess is that the interleave on the drive is set to something >other than 1:1. The only way to change this is to back up the drive, and >run the low-level format again. As stated earlier, my interleave is 1:1 (low level) and 0 (high level DOS interleave) as per the RDPrep/software defaults. I've formatted several times since purchasing the drive and the performance has never changed. > >Second guess is fragmentation, it can easily cut your speed in half. As I said in my original post, this performance has never really changed. Even when freshly formatted I got this performance. A freshly formated (low and high level) drive can't really be fragmented. I've also run de-fragmentation utilities (both BAD and Disk Mechanic) to no avail. Now that my drive is about 80% full there is some decrease in performance but not much. This will be the fragmentation/fullness kludging syndrome. > >-- >Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 >> Mask : 0x0fe > >This is most likely to be the biggest factor in your lack of speed. Tha mask >value is used to determine where host adapter is allowed to use DMA, and where >it has to use programmed IO. With the value set as you show it here, the >HardFrame will only DMA into even addreses between $00 and $fe. _ALL_ accesses >to or from FAST memory, or to CHIP memory above $fe, will be done using >programmed IO. > >The proper value here is 0xfffffe for a 2000, which says that the host adapter >may DMA to any even address in the natural addressing range. This is a typographical mistake in my original post. My mask is :0x00fffffe in reality. I wish the problem was that simple :-). >IMHO: There is only ONE possible solution. You are using OFS with your >harddisk. Hardframe is one of the fastest Amiga contollers abailable, and >with FFS and 100Mg quantum you should be (easilly) get speeds Over 700Meg >per second... (Even my old A2090a measures 700K with Quantum 40Meg)... Nope. Sorry. I've always used FFS on this drive. Well guys....Anything else about this problem. I'd like a lot of net input on this. All the technicians in this place are really poorly trained and the stores basically rip you off so I'm not even bothering to ask the so-called educated ones. I'm relying on you guys to try to shed some light. It seems that I have a slow data bus or something like that. When my machine is totally empty except for the controller, it still functions the same way. I suppsoe interleaving could be the problem but _WHY_? The HardFrame (or any Amiga controller) shouldn't need interleaving. Interleaving is for puny little MessyDos 4 MHz, 8-bit machines :-). I've exhuasted all my ideas. Please guys, try to help me out here. I'm still looking for a Microbotics rep. on the net to discuss this and some other things with. Hello, Microbotics rep. ? -- Craig Lemon - Kitchener, Ontario. Amiga B2000/10--2400 bps--AmigaUUCP 1.03D clemon@lemsys.UUCP or lemsys!clemon@xenitec.on.ca ....!{uunet}!watmath!xenitec!lemsys!clemon
blgardne@javelin.es.com (Blaine Gardner) (12/04/90)
clemon@lemsys.UUCP (Craig Lemon) writes: >>> MaxTransfer : 131072 >>MaxTransfer = 130560 > I will give this a try shortly. I really don't see how less than >1K difference in MaxTransfer can make such a difference. BTW, the 131072 >value was a software (RDPrep) default. This won't make any performance difference, but it will prevent possible data corruption. The smaller value is correct, the 131072 number was an error in an older version of the software. >a new version of RDPrep. Why should the version of the RDBlock program >make such a performance difference? Definitely worth looking into as I >like to keep as current as I can. I purchased my HardFrame exactly a year >ago, just to give you a concept of it's age. The new graphical RDPrep is a whole lot smarter than the old software was. It's not just a change to the RDB, though that's part of it. My Hardframe is about two years old, and the software that came with it sounds like what you've got. The new stuff is only about 6 months old. >functions the same way. I suppsoe interleaving could be the problem but >_WHY_? The HardFrame (or any Amiga controller) shouldn't need >interleaving. Interleaving is for puny little MessyDos 4 MHz, 8-bit >machines :-). I've exhuasted all my ideas. The Hardframe DOES work with the Quantum 105 at 1:1 interleave, and the combination is capable of 700KB/sec, it's what I've got running on my A2500. But since your Hardframe software is so much older than mine, some of the number don't compare too well. The first thing I'd do is get the new software from Microbotics. > Please guys, try to help me out here. I'm still looking for a >Microbotics rep. on the net to discuss this and some other things with. >Hello, Microbotics rep. ? I don't think any of them are on Usenet, they do have an official support conference on BIX though. -- Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 blgardne@esunix.UUCP BIX: blaine_g {decwrl, utah-cs}!esunix!blgardne PLink: BlaineG DoD #0046 My other motorcycle is a Quadracer.
moore@bombe.enet.dec.com (W. Bruce Moore) (12/05/90)
In article <4120.660191024@lemsys.UUCP>, clemon@lemsys.UUCP (Craig Lemon) writes: |> |>>> MaxTransfer : 131072 |>>MaxTransfer = 130560 |>> |>>You'll be a little safer to drop this down to 130560 to prevent possible |>>problems. |> |> I will give this a try shortly. I really don't see how less than |>1K difference in MaxTransfer can make such a difference. BTW, the 131072 |>value was a software (RDPrep) default. The 131072 value is *KNOWN* to cause severe problems! This was acknowledged by Microbotics as a bug in the original RDPrep program, later versions have been corrected to use the lower value. Contact Microbotics for an update. -- W. Bruce Moore Moore@bombe.pa.dec.com