Conference hydra::amiga_v1

    The previous was a comment on how to improve the speed, mine is
    a question:
    
    I just added a SCSI (miniscribe 8051S ) to my 2090A, and after running
    diskperf, it is about 3 times SLOWER than my ST225 connected on
    the same interface.  In fact it is as slow as the first partition
    that uses the OFS (Old File System).
    
    What are the parameters that can be changed to make it faster ?
    Interleave is now at 0 (none) and bufmemtype is 4 (fast ram).  I
    tried increasing buffers to 60, but no improvement.
    
    When I PREPed the drive, it said the number of cylinders was 964
    yet the 8051S tech manual gives 739 cylinders ?  why ?
    
    Shoul I match the mountlist to the drive number for number ?
    
    Another thing, formatting takes a looong time, 30 minutes for the
    40 meg, is this normal ?
    
    Jean
    

    
>    I just added a SCSI (miniscribe 8051S ) to my 2090A, and after running
>    diskperf, it is about 3 times SLOWER than my ST225 connected on
>    the same interface.  In fact it is as slow as the first partition
>    that uses the OFS (Old File System).

Are you sure you formatted it and made the mountlist specify FFS?

    
>    When I PREPed the drive, it said the number of cylinders was 964
>    yet the 8051S tech manual gives 739 cylinders ?  why ?

Check the 8051S technical manual closely. Most often vendors give specs
for all of a product line in the same manual (ie all 80xx series for ex
a 30,40 and 50 meg version). Otherwise, use what the manual says. Prep
may have old/incorrect info.

Actually, with SCSI things like interleave, cylinders, heads, sectors
are relatively irrelevant. As long as the geometry you give prep/mountlist
matches the total number of blocks on the disk, your safe:

	heads*sectors*cylinders = total blocks

>    Another thing, formatting takes a looong time, 30 minutes for the
>    40 meg, is this normal ?
 
Yup. You can specify the QUICK option if you've already formatted it once.

	FORMAT DRIVE xxx: NAME xxxxx FFS [QUICK]

John

    Re: .1
    
    Yeah, I have to second John here, make absolutly sure that the drive
    is mounted and formatted using FFS.
    No selfrespecting and recent SCSI drive uses MFM, so it should be
    faster than your ST-506 drive.
    If you can't fix it, post the mountlist.
    
    And yes, 30 minutes for 40MB isn't too bad. But like John said,
    you should have to go thru this only once...
    
    Regards,
    
    <CB>

    Following is my mountlist, but first what I did this morning after
    I got POed and killed the power at 23:30 last night.  I again tried
    to prep the thing, and it seems that if the menu selection of SCSI
    or ST-506 are used then 17 sectors are AUTOMATICLY assumed, the
    only way to make it accept 28 sectors (like the Miniscribe has)
    is to use the user defined option in the menu (option 0).  Then
    I formatted it again and it came out bigger (2.6 Mb for the 50
    cylinders vs 2.0 Mb before) Oh yes it is formatted with the FFS
    system.  I again ran diskperf and the thing must be filled with
    molasses because it topped out at around 45Kb for a read with 32K
    buffers.
    
    To further confuse things, my buddy has the same drive (bought at
    the same time), but hooked up to a Supra controller on his 1000
    and IT is slow too.  He tried OFS and the results were worse 15Kb
    with 32K buffers and about the same as mine with the FFS.  Are we
    living trough the Mac SCSI slowdown that affected the Seagate drives
    not too long ago?  And how are drives slowed down?
    
    AAAAAAAAAARRRRRRRRRRGGGGGGGGG!!!!!!
    
    Jean
    
    RES0:      Device = hddisk.device		<------	THIS IS FOR THE ST225
           Unit   = 1
           Flags  = 0
           Surfaces  = 4
           BlocksPerTrack = 17
           Reserved = 0
           Interleave = 0
           LowCyl = 0  ;  HighCyl = 1
           Buffers = 1
           BufMemType = 4
#


RES2:      Device = hddisk.device		<------	THIS IS FOR THE SCSI
           Unit   = 3
           Flags  = 0
           Surfaces  = 4
           BlocksPerTrack = 28
           Reserved = 0
           Interleave = 0
           LowCyl = 0  ;  HighCyl = 1
           Buffers = 1
	   BufMemType = 4
#
------------------------------------------------------------------------
NEWCON:, PIPE:, RAD:... CUT OUT FROM HERE
------------------------------------------------------------------------
DI0:
    Device = hddisk.device		<------	THIS IS FOR MY ST225 (20M)
    FileSystem = l:FastFileSystem
    Unit   = 1
    Flags  = 0
    Surfaces  = 4
    BlocksPerTrack = 17			
    Reserved = 2
    Interleave = 0
    LowCyl = 33  ;  HighCyl = 612
    Buffers = 30
    GlobVec = -1
    BufMemType = 4
    Mount = 1
    DosType = 0x444F5301
    StackSize = 4000
#

Dh2:					<------	THIS ENTRY IS FOR THE NEW
    Device = hddisk.device			SCSI DRIVE (Miniscribe 8051S)
    FileSystem = l:FastFileSystem
    Unit   = 3
    Flags  = 0
    Surfaces  = 4
    BlocksPerTrack = 28
    Reserved = 2
    Interleave = 1
    LowCyl = 2  ;  HighCyl = 50		<------ THIS IS ONLY TO CUT DOWN
    Buffers = 30				FORMATTING TIME
    GlobVec = -1
    BufMemType = 4
    Mount = 1
    DosType = 0x444F5301
    StackSize = 4000
#

Re: .2

>Actually, with SCSI things like interleave, cylinders, heads, sectors
>are relatively irrelevant. As long as the geometry you give prep/mountlist
>matches the total number of blocks on the disk, your safe:

Your're completely right about cylinders, heads, sectors being irrelevant.
The embedded controller knows the true geometry of the drive, and given
a block number, will find that block.  Some drives (like the Quantum)
actually have a very funny geometry where the number of sectors per
track is a function of the track number.

However, the interleave usually is very relevant.  Although some SCSI
disks have track buffers (like the Quantum) and always use 1:1 interleave,
most don't play this trick.  Having a bad interleave on a SCSI or
non-SCSI disk can slow it down by a factor of twenty!

Re: .0

I suspect that the drive has the wrong interleave.  Unlike ST-506 disks,
interleave isn't handled by the host system (so, your mountlist interleave
entry should remain zero).  Instead, the low level SCSI format of the
drive tells the drive the interleave that it should format itself with.

Since I don't have a Commodore controller, I don't know how you tell it
to change the interleave of the SCSI disk.  I suspect that the "user
drive setup" alluded to in previous notes may be the way to accomplish
this.

If you find out how to set it, try setting the interleave to 4 and
then seeing how well the drive performs.  If you get a big increase
in performance, try setting the interleave to 2.  If that slows it
down, try an interleave of 3.  (It's been my experience that a 1:2
interleave usually works best for Amiga hard drives.)

Interleave is a funny thing.  If a interleave of "n" is good, an interleave
of "n-1" may be slightly faster, or may cause the drive to run at its
absolutely slowest speed!

    My freind called Supra to ask them about this speed issue, the person
    there told him the drive was fine and that they were using the same
    drive and getting 250Kb transfer rates.  However, he said that the
    drive was running a "new" version of the SCSI protocol and the
    interface would need to be upgraded (soft + hard {ROM?}), has anyone
    heard about "new" protocol being used by SCSI drives/controllers?
    
    Jean
    
    PS I'm going to call CBM (Canada) to find out if THEY know anything 
    about this.

> Your're completely right about cylinders, heads, sectors being irrelevant.
> The embedded controller knows the true geometry of the drive, and given
> a block number, will find that block.  Some drives (like the Quantum)
> actually have a very funny geometry where the number of sectors per
> track is a function of the track number.

Yup, it's called Zoned Bit Recording (or ZBR). It basically packs more
sectors on the outer tracks since the bit's on non-ZBR drives are further
apart on the larger radius. ZBR attempts to provide a constant 
"recording density" over the entire radius of the drive. It does this, 
as Randy said, by changing the number of sectors/track, typically in 2 or 3
zones across the radius (i.e. cyls 0-300 might have 40 sectors, 301-600
have 35 sectors and 601-1000 have 30 sectors).

SCSI II provides a mode page to get info for these "notched drives".

> However, the interleave usually is very relevant.  Although some SCSI
> disks have track buffers (like the Quantum) and always use 1:1 interleave,
> most don't play this trick.  Having a bad interleave on a SCSI or
> non-SCSI disk can slow it down by a factor of twenty!

Randy is correct here. Although I don't think most SCSI adapters are be smart
enough to let you change the interleave since this requires issueing a 
SCSI FORMAT command to take effect. And since the AmigaDOS FORMAT command
prints each cylinder as it formats it, it obviously does NOT use the SCSI FORMAT
command, but instead just does a WRITE followed by a READ (verifying...).

SCSI says an interleave of 0 means "use your default". Some drives (particularly
those which have embedded servos) will not even let you change interleave
anyway.


John

> apart on the larger radius. ZBR attempts to provide a constant 
> "recording density" over the entire radius of the drive. It does this, 
> as Randy said, by changing the number of sectors/track, typically in 2 or 3

Let me clearify this a bit. "It does this.." by changing the recording
density - changing the rate at which bits are layed down, which results
in more total bits for the outer tracks, and hence , more sectors.

John

Supra? Guess I missed that.

Supra just came out with "Series II" driver software set. Sounds like your
friend has ooold  stuff. He should call for the upgrade.

John

CBM Canada (416)-499-4292
ask for customer support

 mark

Today, I called Miniscribe and told them the problems I was having and 
they told me that the drive was not tested on Amigas (to their knoledge
at least) and that the drive was built mainly to be hooked up to MACs, and
on those the performance programs available gave around 400Kb of transfer
rate, since we were not comparing apples to apples (pun intended), I kinda
dismissed the results.

I then called Commodore Canada, and they told me that they may just have
a drive of the same make and type (Miniscribe 8051S) and that they were
going to test it and call me back tuesday.

Then I tought that I could try a different drive to see if the results were
similar, so I borrowed an RZ23 and hooked that up.  The first few numbers 
looked good, but then it too topped out at a dismaly slow speed.

Following are the results from diskperf for Dh0 (ST-225 first partition 
OFS), DH2 (RZ23 small 1.6Mb partition FFS) and DI0 (ST-225 second partition
FFS)

I looked at the results posted by CB with an A2090 hooked up to a Rodime
drive (SCSI) and he got an easy 500Kb, what is different from his set-up?
All I can see is that I have an A2090A which may have a different firmware
than the A2090 he used.  The other factor is that both of the drives that
I tried are of quite recent manufacture and THEY may just implement a
different subset of the SCSI protocol.  This last one may make a lot of
sense because my friend with his Supra interface on his 1000 was told by
Supra that he did not have the latest software to drive it to it's full
potential (he is going to test the RZ23 tomorrow).  If that is the case,
what must be updated on the A2090A to make it perform the way it should?

Where's that bottle of aspirin?

Jean


This is Dh0 (boot partition) with the OFS 

File create/delete:	create 9 files/sec, delete 25 files/sec
Directory scan:		40 entries/sec
Seek/read test:		65 seek/reads per second
r/w speed:		buf 512 bytes, rd 34044 byte/sec, wr 20164 byte/sec
r/w speed:		buf 4096 bytes, rd 44431 byte/sec, wr 23831 byte/sec
r/w speed:		buf 8192 bytes, rd 45197 byte/sec, wr 23831 byte/sec
r/w speed:		buf 32768 bytes, rd 45990 byte/sec, wr 24272 byte/sec

This is an RZ23 formatted with the FFS

File create/delete:	create 11 files/sec, delete 28 files/sec
Directory scan:		45 entries/sec
Seek/read test:		84 seek/reads per second
r/w speed:		buf 512 bytes, rd 42974 byte/sec, wr 22405 byte/sec
r/w speed:		buf 4096 bytes, rd 60963 byte/sec, wr 25954 byte/sec
r/w speed:		buf 8192 bytes, rd 62415 byte/sec, wr 25954 byte/sec
r/w speed:		buf 32768 bytes, rd 62415 byte/sec, wr 26479 byte/sec


This is my old workhorse ST-225 with the FFS

File create/delete:	create 10 files/sec, delete 32 files/sec
Directory scan:		102 entries/sec
Seek/read test:		78 seek/reads per second
r/w speed:		buf 512 bytes, rd 59578 byte/sec, wr 25450 byte/sec
r/w speed:		buf 4096 bytes, rd 119156 byte/sec, wr 79437 byte/sec
r/w speed:		buf 8192 bytes, rd 154202 byte/sec, wr 93622 byte/sec
r/w speed:		buf 32768 bytes, rd 201649 byte/sec, wr 100824 byte/sec

Try it (RZ23, Miniscribe) on another 2090 board. Sounds like a system/2090
problem.


John

Re: .11

>This is an RZ23 formatted with the FFS
>
>File create/delete:	create 11 files/sec, delete 28 files/sec
>Directory scan:		45 entries/sec
>Seek/read test:		84 seek/reads per second
>r/w speed:		buf 512 bytes, rd 42974 byte/sec, wr 22405 byte/sec
>r/w speed:		buf 4096 bytes, rd 60963 byte/sec, wr 25954 byte/sec
>r/w speed:		buf 8192 bytes, rd 62415 byte/sec, wr 25954 byte/sec
>r/w speed:		buf 32768 bytes, rd 62415 byte/sec, wr 26479 byte/sec

Yep, your interleave is wrong (see my previous note).  I saw lots
of diskperf numbers like that when I experimented with different
interleaves.

I don't know how to change the interleave of a SCSI disk using the
Commodore "prep" program.  If you find someone with a Pacific Peripherals
Overdrive controller, they can change the interleave for you.  The
overdrive comes with a text file that contains the SCSI commands
sent to the drive to format it.  Byte four (counting from zero) of the
SCSI format command is sets the drive interleave.  Pacific Peripherals
may invert a few buss signals here and there, but at least their
drive setup software is flexible.

From USENET:

Article 38436 of comp.sys.amiga
Path: shlump.nac.dec.com!decuac!haven!rutgers!sun-barr!apple!oliveb!amiga!cbmvax!daveh
From: [email protected] (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: A2090A and Ronin 030
Message-ID: <[email protected]>
Date: 22 Aug 89 19:14:14 GMT
References: <[email protected]>
Distribution: usa
Organization: Commodore Technology, West Chester, PA
Lines: 47

in article <[email protected]>, [email protected] (Stuart J. McIntyre) says:
> Keywords: 2090 2000 1.3 Ronin 68030

> With the ronin CPU/memory OFF the machine works great.  With maxtransfer
> set to 262144 on the FFS partitions we were getting 508K/sec.  But!!!
> in order to use the 68030 we had to add "Mask = 0xfffff" to the mountlist
> for each of the FFS partitions.  This dropped diskperf down to 80k/sec!!

Yup.  Look carefully at that mask value.  It has the effect of restricting
all DMA to Chip memory.  The result of this is that you're fast DMA disk
is now running about as slow as possible in such a system.  The only way
you can speed it up at all would be to DMA into Fast memory and then CPU copy
to Ronin RAM, but that's not going to be all that much faster.  

This is a two-way problem.  Obviously a DMA controller can't get to RAM that's
not in it's address space.  Only, the Ronin memory normally sits in autoconfig
space, though it doesn't autoconfig, and it's not DMA-able.  That's pure evil,
there aren't many other rule this Ronin RAM could have broken.  There's supposed
to be a way to move it up out of the autoconfig space -- I'd recommend that, as
that's where such memory belongs, if you have it -- out of the 24 bit address
space.  Then you can benefit as much as possible from expansion bus Fast memory,
and set your mask to 0xfffffe to keep the DMA within the 24 bit space.

> required to avoid the guru, (so now we have a 20 MHZ Amiga with a 
> quantum running at 80k/sec and 4Mb 32 bit ram but we can't remap
> kickstart into the fast ram without crashing.)

I suspect you have a 14.3 Mhz Amiga, perhaps with a 20 or 25MHz math chip, 
unless this is a new version of the Ronin card.  I hope not -- I'd like to
think they wouldn't introduce the same flaws twice.  They were the first 3rd
party 68020 design to at least get the basic bus interface stuff 100%, at
least as much as I've tested the thing (played with one for 2 weeks); why stop
at halfway right?

> Will a trump card (or Kronos card) solve the DMA/fast RAM problems?

Any non-DMA card will work faster in such a setup; C Ltd., IVS, or GVP are ones
I know of.  They still won't be as fast as DMA could be with an A2620 or A2630,
but they'll work FAR better than your current setup.

> -Stuart


-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
            We have no choice.  We are, after all, professionals.

    I tried a different controller (A2090, the old one) and the results
    were the same.  Like a previous noter replied, I'm sure that the
    interleave is wrong but none of the software I have (prep or format)
    changes a thing.  I tried to format while changing the interleave
    parameter in the mountlist, but it does not seem to change anything.
    I suspect that a low level formatter would though, but as of now
    it does not exist for the Commodore A2090(a) it does however exist
    for the new A590 made for the A500.  
    
    At this point my options are:
    
    1- Hook the drive up to a different controller an low level format
       it untill the performance improves (long and lenghty process).
    
    2- Beat up on C= to get them to issue the proper software if it
       exists somewhere (I wouldn't hold my breadth for this).
    
    3- Get the dealer or C= to take all the hardware he sold me because it
       does not perform to spec and buy a different controller (for
       future compatibility I would tend to stay with C= stuff)
    
    What a mess, what to do? any easier options?
    
    Jean
    
                            
    

    Re: .15
    
    Uh, did you try to set the desired interleave in the RES2: entry
    of the mountlist and do a prep afterwards? Might just do the trick.
    If it fails, I would have it low-level formatted using something
    like the A590 at your dealer.
    
    Or just wait for the A2091. ;-)
    (Sorry, I'm being sarcastic again)
    
    Regards,
    
    <CB> 
    

I could issue a SCSI FORMAT command from some test stations here in Marlboro
Mass USA.  That would fix the interleave for sure.

John

    IT WORKS, IT WORKS
    
    I was always under the assumption that the hard drive that "autoboots" needed
a small partition ONLY to do just that.  THIS IS NOT TRUE, at least as far as
the A2090A is concerned.  The Commodore controller will AUTOMOUNT all drives
that are connected, but they will use the OFS even if you try to format them
with FFS, they will not be FFS partitions.  

Before I added the SCSI drive, I had an RD51 hooked up, when I ran diskperf
on that drive, the results were about the same as my first partition of the
first drive that was in OFS.  Since I was not expecting miracles from the
RD51 and I thought it was a slow drive anyway, the numbers were ignored.  
When I added the SCSI drive, I expected much better results than those given
by the ST-506 drives, when I found how dismal these were I assumed (did this
ever make an a$$ of me) that something was wrong, at first hardware then
software.  

What got me on the track, was that I started to disconnect everything hooked-up
to my system (genlock, extra memory the first ST-506 drive) with no change
whatsoever.  Then I reconnected my old RD51 and started to build it up, but
when I prepped it, I called the first partition "dh1" and in the mountlist,
I had the second partition named "dh1" also.  This confused Amigados enough
that it would not format the second partition.  At this point a good night's
sleep was needed, so I had a full day to think about my next move.

"When every thing else fails, READ THE MANUAL"  we have all seen or heard
this at one time or another.

Excerpt from the AMIGADOS 1.3 enhancer software manual

"Since Commodore's Hard disk/SCSI Controller auto-mounts the default file 
system on the first partition of a hard disk, it is not possible to use the
FastFileSystem there.  However, using the new 1.3 Version of the MOUNT command,
it is possible to make additional partitions that will use the FastFileSystem."

I followed what the manual said and made a 2 cylinder partition on each drive,
formatted the 2 cylinder partition with OFS and the rest with FFS the results
are given below.  What I thought was a dog, the ST-412 turns out to be faster
than my ST-225, were it not for it's size and small capacity, I would keep it.
The Miniscribe 8051S gives a respectable showing, I will experiment with
interleave to see if it can be made even faster, the next drive that I buy
though will be a Quantum.


This is the performance of an ST-412 (RD51)

File create/delete:	create 14 files/sec, delete 45 files/sec
Directory scan:		111 entries/sec
Seek/read test:		90 seek/reads per second
r/w speed:		buf 512 bytes, rd 62415 byte/sec, wr 27306 byte/sec
r/w speed:		buf 4096 bytes, rd 131072 byte/sec, wr 104857 byte/sec
r/w speed:		buf 8192 bytes, rd 174762 byte/sec, wr 124830 byte/sec
r/w speed:		buf 32768 bytes, rd 238312 byte/sec, wr 145635 byte/sec


This is the performance of my new Miniscribe 8051S (SCSI)

File create/delete:	create 15 files/sec, delete 45 files/sec
Directory scan:		108 entries/sec
Seek/read test:		82 seek/reads per second
r/w speed:		buf 512 bytes, rd 54613 byte/sec, wr 27594 byte/sec
r/w speed:		buf 4096 bytes, rd 97090 byte/sec, wr 137970 byte/sec
r/w speed:		buf 8192 bytes, rd 163840 byte/sec, wr 187245 byte/sec
r/w speed:		buf 32768 bytes, rd 327680 byte/sec, wr 238312 byte/sec

This is the performance of a 40Mb Quantum I borrowed (SCSI)

File create/delete:	create 17 files/sec, delete 55 files/sec
Directory scan:		108 entries/sec
Seek/read test:		126 seek/reads per second
r/w speed:		buf 512 bytes, rd 87381 byte/sec, wr 29454 byte/sec
r/w speed:		buf 4096 bytes, rd 238312 byte/sec, wr 163840 byte/sec
r/w speed:		buf 8192 bytes, rd 327680 byte/sec, wr 238312 byte/sec
r/w speed:		buf 32768 bytes, rd 524288 byte/sec, wr 291271 byte/sec


I hope all this keeps someone else from pulling their hair out.


Jean