Conference hydra::amiga_v1

    I have also taken the HardFrame plunge, and agree with Ed's comments.
    No problems setting it up.  I installed the hardware, formatted
    the drive and copied 'lots' of software one night after work.  
    Painlessly.  That was a concern of mine, because I had zero
    experience with setting up hard drives.                    
    
    I have run DiskPerf several times.  From a working directory on
    DH0: I get about 500k reads/sec and 250k writes/sec.
    
    From a 'never been used', freshly formatted DH1: I recorded
    655k reads/sec and 325k writes/sec.  Wow!
    
    Obviously, I am very happy with the performance.  I had expected
    slightly higher write performance, but this is not *too* bad.
    Any way to tweak that a bit?  
    
    Steve ( A very happy HardFrame/ST277N owner ) 

    
    Re: .0  
    
    The C Ltd board is sold.
    
    Ed.

    Will the HardFram support ST506 style drives with Omti 3527 adaptors
    and/or Adaptec adaptors?  I recently upgraded from Adaptecs to all
    Omti's (thanks to a friend bringing one over to play with).  I saw
    a speed increase from 180K to 300K+ on SCSIdos.  500K!  WOW!
    
    John
    

    
    The HardFrame does indeed work with ST506 drives.  MB recommends
    the Adaptek 4000A for MFM encoded drives and the Adaptek 4070 for
    RLL drives.  (Naturally they recommend Adaptek, since John just
    upgraded to OMTI :^))
    
    You just assign the Adaptek a SCSI ID and it's drives a Logical
    Unit Number.  
    
    The documentation clearly recommends the use of an imbedded SCSI
    drive.  If you want to get more info from the horse's mouth...
    
    MicroBotics, Inc
    811 Alpha Drive, Suite 335
    Richardson, Texas 75081
    (214) 437-5330
    
    Ed.

    
    I forgot to talk about a rather disappointing problem... my CMI
    Processor Accelerator would not function properly with the HardFrame.
    The machine just wouldn't boot.  The HardFrame documentation talks
    about certain 'plug into the 68000 socket' accelerators that do
    not support DMA, and recommends against their use.  I sent the CMI
    board back to the vendor for upgrading, since I had purchased a
    very early unit.  I'm expecting it back any day now.
    
    CMI has been working with MicroBotics, but they haven't yet received
    their very own HardFrame (MB is sending them one) so they can't
    be certain that the latest firmware will fix the problem.  They
    DO expect some sort of resolution, but I'll believe it when I see
    it.
    
    I'm not too frantic, since I plan on getting an A2620 board in the
    not-too-distant future.  Meanwhile, it's back to my beef-a-roni
    68010.
    
    Ed.
    
    

    		
    	If I have An A500 what controller is needed for A500 to HARDCARD
    to RD54-DB   
    
    		regards
    		Steve G

    A hardcard means that the host controller has a drive mounted on
    it! I don't think you want to mount an RD54 on any controller. Its
    a big and heavy drive. 

    Boy did I have a scare last night.  I was installing a new 40MB
    hard disk onto a Microbotics hardframe into a brand new Amiga 2000.
    Turn on the computer and there's a quick snap and smoke pours out
    of the hard disk!
    
    Immediately I thought "Steve.  You #@#$@ moron, you've hooked it
    up wrong and now its gone!"  After going over the connections about
    20 times I decided I couldn't find anything wrong.  So I called
    microbotics to discuss it.  Get this:  A NUMBER OF UNITS WENT OUT
    WITH BAD CABLES TO POWER THE HARD DISK FROM THE CARD!  I believe
    they misconnected the +5/+12 V supplies.
    
    Mike is trying to arrange with Arrow to get me a new hard disk.
    He is supposed to call me this morning.  Fortunately both the
    2000 and the hardframe seem to be fine.  

    So if you get a Hardframe, use the power cable that is inside your
    A2000 and burn, mutilate, and trash that #@$%@!% 4 inch cable that
    came inside the Hardframe box!!!

    Why me???

    - steve

    I am amazed that the manufacturer didn't contact everyone of its
    dealers immediately so the dealer could check their stock. Sounds
    like someone dropped the ball!

    I probably spent an hour on the phone with Mike at Microbotics
    last night (at his expense).  He insisted that the best offer
    he could give me was a loaner 20 Mb disk until the Quantum they
    had destroyed was repaired.  He said this was the best they could
    do because "that is all the insurance company is willing to pay
    and we (Microbotics) don't have it in our budget to buy you a
    new drive."  Well I didn't give in and was not making much progress
    but I kept my cool.  Finally I told him that if I didn't get 
    satisfied I would be sure to post detailed descriptions of this
    fiasco to Usenet, BIX and any other conference I could access.
    He told me he would talk to his marketing people and get back
    to me.  Ten minutes later he called back and agreed to buy me 
    a new drive from Arrow.  I've got to ship him the bad drive and
    bad cable first though.  Just goes to show, sometimes a good
    threat is more effective than rational arguments!

    I'll let you know how it turns out.
    
    - steve

    re: .5
    Ed, any news on the problem between HardFrame and CMI Accelerator?
    

    re: .10
    
    Well, microbotics came through.  I received a NEW Quantum 40S last
    night from Arrow.  Microbotics also sent me a new power cable.
    I hooked it up and everything went smoothly.  Their installation
    software could not be better.  It does seem to be a pretty
    fast combo considering I didn't even tweak anything (just used the
    defaults).  I ran diskperf and here are the results:
    
    	file create:  16/sec
        file delete:  47/sec
        dir scan:     94 entries/sec
    
        read/write tests
    		buffer size:   512 bytes
    			read	104857 bytes/sec
    			write	 29127 bytes/sec
    		buffer size:  4096 bytes
    			read	238312 bytes/sec
    			write	163840 bytes/sec
    		buffer size:  8192 bytes
    			read	374491 bytes/sec
    			write	218453 bytes/sec
    		buffer size:  32768 bytes
    			read	524288 bytes/sec
    			write	262144 bytes/sec
    
    What amazes me is that multiple simultaneous accesses to this drive
    does not seem to slow it down at all.  I was installing Lattice
    C from DF0: and while that was going on I had two other windows
    where I was doing directories, coping files, etc.  None of the
    disk accesses seemed to slow down at all.
    
    By the way, I used FFS on the entire drive and the Hardframe
    autoboots fine.  I quess in spite of the difficulties I had,
    I'd recommend the HardFrame.
    
    - steve    

	A question for Hardframe users:  How is the installation software/
device driver?  After doing some fiddling with a bad drive, I'm very displeased
with the PREP program/hddisk.device that came with the A2090.  Particularly
with regard to it isolating bad blocks.  Will the low level format read the
manufacturers bad block table on the drive, or do you have to type it in?  Also,
will your low level format mark bad blocks? 

Mark

    OK guys, I have a weird problem.  When I ran the hard format program on
    my HardFrame/Quantum setup, it accessed the drive very briefly (i.e. a
    second or so) then reported it was "Done".  I finished initializing the
    partitions, etc. and set about loading things onto the hard drive with
    no apparent problems... for about 2 weeks, that is.  Then I started
    getting the dreaded read/write error requesters - Oh sh*t.  DiskSalv
    found whole sections of the disk that seemed to be completely wiped
    out by hard errors.

    I backed up everything this weekend (thanks Quarterback!) and went to
    work on reformatting the drive.  I ran the hard format program again
    (FormatHF) and it finished immediately, like before.  I decided to
    reboot the machine just to be sure everything was clean.  Imagine my
    surprise to find my freshly *hard formatted* drive show up WITH ALL
    FILES INTACT!

    I decided to try doing an AmigaDOS format without the QUICK option
    (contrary to HardFrame's instructions).  It appears to have cured the
    errors.  I copied *lots* of stuff into the partitions which previously
    had errors and have not seen a single failure since.

    Looks like it's time to call Microbotics to find out what's going on
    here.  I wonder whether anyone else has run into this, or am I the
    only one???

>    (FormatHF) and it finished immediately, like before.  I decided to
>   reboot the machine just to be sure everything was clean.  Imagine my
>  surprise to find my freshly *hard formatted* drive show up WITH ALL
> FILES INTACT!

I reformatted a partition on my disk using FFS with the Quick 
option.  Later I ran DiskDoctor on it (for reasons I won't 
explain here, now) and it restored most of the original files.

I know this isn't the same thing as you described, but it is 
similar.

Randy

I've got a Hardframe and Quantum 40S and if I remember correctly low level
formatting should NOT come back right away.  It should format the entire
disk.  When you use the FFS QUICK options on AmigaDOS format I believe it
only modifies some root blocks.  Possibly you entered some invalid numbers
during RDPrep???  If you tried coming up with your own, you might try
redoing RDPrep and taking the defaults.  BTW the defaults RDPrep came up
with for my Quantum 40S did not use the full drive.  If you talk to the
Microbotics guy, he can give you some better numbers.  From memory it was
something like 734 cyls, 3 surfaces, 37 sectors/track.  This utilizes
every sector.

- steve

    I don't think the "Prep" options would affect this because the hard
    format is done *before* Prep.  And I did take default Prep choices
    for everything except dividing the drive into 4 equal partitions,
    (default would make one huge partition).
    
    It's pretty clear the hard format is bailing out for some reason but
    gives absolutely *NO* indication of any problem.

>   I don't think the "Prep" options would affect this because the hard
>   format is done *before* Prep.

I should have realized that since I just re-prepped mine recently.
Sorry for the temporary lapse...  Seems to be happening more and more
lately. :-)

- steve

For what is it worth, if I format my Quantum drive using my Pacific
Peripherals Controller, the drive formats instantly.  I've been
assuming that since the Quantum has a fixed interleave that low
level format ends up not needing to do much.  But then, I don't
know fer sure...

The drive works fine.

I keep meaning to try and hunt down a phone number for Quantum
to call and get the technical manual on their drives, but I've
just never thought of it at the right time (anyone got a phone
number or address for them off hand).

> Peripherals Controller, the drive formats instantly.  I've been
> assuming that since the Quantum has a fixed interleave that low
> level format ends up not needing to do much.  But then, I don't
> know fer sure...

Usually formatting a drive will re-write both data and header information.

Quantum's (and lots of others) have what's called "Embedded Servo" which,
to make things short, means that headers can;t be re-written. So a format
on these drives can do one of two things:

	1. Fix up the defect lists and return (quick!)
	2. Fix up the defect lists, do a read/write or the media
		mapping out additional defects.

#2 has several permutations, but basically takes long like you'ld expect
format to do.

John

Re: .20

>Quantum's (and lots of others) have what's called "Embedded Servo" which,
>to make things short, means that headers can;t be re-written. So a format
>on these drives can do one of two things:
>
>	1. Fix up the defect lists and return (quick!)
>	2. Fix up the defect lists, do a read/write or the media
>		mapping out additional defects.

I was hoping that John would step forward with a definitive answer.
Thanks.

As I said before, when I just format the drive, it returns instantly
(corresponds to John's #1).

As John predicted, if I select verify drive (corresponds to John's #2),
it checks all the blocks on the drive for defects, and takes forever.

    Interesting!  I recall seeing something about "Embedded Servo" being
    employed in DEC's RA-series drives.  Servo data is written into what
    would otherwise be just inter-sector gaps.
    
    So it looks like the FormatHF program only offers the 'quick' (#1)
    flavor of formatting.  By letting AmigaDOS Format write everything
    it did effectively a 'slow' (#2) format.
    
    Anyway, it's still working perfectly.

Re: .22

>    So it looks like the FormatHF program only offers the 'quick' (#1)
>    flavor of formatting.  By letting AmigaDOS Format write everything
>    it did effectively a 'slow' (#2) format.

The AmigaDOS format actually counts as #3.

With my controller (Pacific Peripherals) and its associated software,
there is two levels of SCSI formatting.

The first was "Format," which corresponds to John's #1. It has the side
effect of setting the drive's interleave.  This type of format does not
check the disk for bad blocks.  On a seagate disk and another disk
made by some Japanese company whose name I don't remember, this command
would run for a three or four minutes.

The second was "Bad Block Scan," which corresponds to Jonh's #2.  It
would test every block on the disk, and if it was bad, would ask the disk
to revector it.  This process takes a very long time.  (Some SCSI drives
can verify themselves and reassign bad blocks upon receiving a single
SCSI command requesting them to do so.  I think the more common case
requires the host to test each block and reassign bad blocks.)

After that, you could then do a AmigaDOS format of the disk.  I don't
think that AmigaDOS has any strategy for dealing with bad media (except
for retries).  The AmigaDOS folks at Commodore believe that the device
itself should handle bad blocks (true of SCSI disks) or that the device
driver software should handle them.  Above the device driver level, the
disk must be perfect.  Thus, if AmigaDOS format finds any problems, there
is nothing it can do.

By the way, I don't recommend the Pacific Peripherals controller.  It
seems to be at fault in not getting along well with my ASDG memory
board.  Thus, I have to use a version of the driver software that slows
down the drive considerably to avoid stomping on the hidden refresh of
the memory board.  Pacific Peripherals didn't design the controller:
they bought the design from Interactive Video Systems, or IVS, who
now sells a disk controller under the product name TrumpCard.  I don't
trust IVS to correctly obey the bus protocol with their new controller,
so I don't recommend them either.

	Well, my A2090/ST-251-1 combo beat my planned backup by about an
hour with its monthly crash, unfortunatly taking some stuff I'd rather not
have lost with it.  Being tired of the montly rebuild everything cycle, and
running out of room on the ST-251, I decided to upgrade to a Hardframe with a
Quantum Prodrive 105S.  

	I rigged it as a stand-alone hardcard.  Turn my machine on, and nothing
happens - no power led, no fan noise, no disk access.  Take out the hardcard,
and things work normally.  Put the card back in - nothing.  Call Microbotics,
talk to a tech.  He recommends trying the following two things:  Power the
drive from the Amiga power supply; and if that doesn't work, mounting the
drive in the drive bay (good thing I don't have a second floppy), and removing
the disk frame from the controller.  So, I switched the drives power - nothing.
Next I set it in the bay, and removed the frame from the controller.  Works
great.  I go through the very easy installation process and everything seems
hunky-dory.  Okay, I'll just fasten the drive to the bay, and close up the
system, right?  Wrong!  Machine won't come on again.  Okay, undo the srews, 
and everything works fine - all the data I put on is there.  I ended up
setting the drive on a piece of rubber, and securing it in the bay with
duct tape.  It works fine, but I think I'm going to call Microbotics 
tommorow and have a talk with them.

	On performance, I planned to run diskperf, but didn't seem to have
a copy on my machine.  I searched this notesfile till I found the diskperf
note, which included my old timings.  I downloaded them along with a copy
of diskperf to run on the new drive.  Much to my suprise, some operations
show up as slower on the new setup!  Here are the comparative timings:

	Amiga B2000, 3MB RAM
	Microbotics Hardframe w/Quantum ProDrive 105S
	Recently Formatted FFS

File create/delete:     create 10 files/sec, delete 41 files/sec               
Directory scan:         92 entries/sec                                         
Seek/read test:         132 seek/reads per second                              
Read/Write:		Buff		Read		Write
			----		----		-----
			512 		100824 		29127
			4096		238312 		145635
			8192 		327680		201649
			32768 		436906 		262144

-------------------------------------------------------------------
	Amiga B2000, 1MB RAM
	Commodore A2090 w/Seagate ST-251-1
	Recently Formatted FFS

File create/delete:	create 13 files/sec, delete 43 files/sec
Directory scan:		94 entries/sec
Seek/read test:		99 seek/reads per second
Read/Write:		Buff		Read		Write
			----		----		----
			512		77101		27306
			4096		131072		104857
			8192		174762		124830
			32768		238312		137970


Mark

    
    MarK:  Ouch!  I have the exact same setup as you (HardFrame
    w/Quantum105) and am getting much better disk performance.
    
    Buffer Size 	512  	  4096      32768     262144                  
    --------- 		--------- --------- --------- ---------     
    Bytes/s Create       28966    154273    286178    370255
    Bytes/s Write        30117    190989    572357    673614 
    Bytes/s Read        173819    287814    593883    681885
    
    Here's the data I used when running RDPrep...
    
    (The low and high cyl numbers are actually different, since I use two
    partitions, but you get the idea...)
    
    TableSize           : 16        
    SizeBlock           : 128       
    SecOrg              : 0         
    Surfaces            : 6         
    SectorPerBlock      : 1         
    BlocksPerTrack      : 32        
    Reserved            : 2         
    PreAlloc            : 0  
    PreAlloc            : 0         
    Interleave          : 0         
    LowCyl              : 0       
    HighCyl             : 1067      
    NumBuffers          : 20        
    BufMemType          : 5         
    MaxTransfer         : 130560    
    Mask                : 0x0
    BootPri		: 0
    DosType		: "Dos^A"
    
    
    Also, Mike at MB told me that I should use the FastFileSystem handler
    from the 1.3.2 distribution, as the version in 1.3 has a bug.
    
    You are using what should be among the highest performing systems
    available (I guess you knew that, which is why you're miffed, right?),
    so I'd bend MB's ear until things are straightened out.
    
    Ed

Ed,

	I like your numbers much better than mine - wanna swap? :)

	Yes, I expected a faster setup than I seem to be getting.  I s'pose
it's what I get for doing it the lazy way.  I took the one drive, one
partition, no questions option for RDPrep, so couldn't tell you what my
numbers are.  I downloaded yours, though, and when I have the time, I'll
back everything up and play with RDPrep.

	I do know about the 1.3 FFS bug, and am using the 1.3.2 version.

	BTW, what are you using to measure disk performance?  You show
figures for things my copy of diskperf didn't seem to test.

Thanks,
Mark

    
    I used an Intuition-ized program called 'DiskSpeed'.  It is on the net
    somewhere.
    
    Ed.

Re: .24 to .26

I have a Quantum 105S and a Commodore 2091 controller.  I've found
that the performance measured by disperfa is sensitive to the
partition that I run the test on (even when the partitions are
the same size and empty).

I suspect very strongly the results are due to the strange geometry
of the Quantum: The number of physical sectors per track is a
function of which "zone" the track is in.  The 105S has three different
zones.  If I test a partition located in a zone where there are
more sectors per track, the disk performance is about 600K bytes/sec
for 32K buffers.  If I test the other end of the disk where there
are fewer sectors per track, the performance drops to about 400K
bytes/sec for 32K buffers.  (Beware: these numbers are from memory!)

Thus, if you test the disk as one big partition, you are going to
get very different numbers from someone who tests a small partition
near the edge of the disk.