Conference hydra::amiga_v1

Re .0
    
    I have been running under FFS for the past 4 or 5 days and have
    seen no guru that I can attribute to the drive or device driver.
    
    My configuration is:
    
    B2000 rev 4.4 
    no true FAST RAM
    2 floppies
    1 PP Overdrive with ST157N drive affixed
    The Overdrive.device file that I have is dated 24-Mar-88 so it's
        not likely to be the one optimised for FFS.
    
    The important parts of my MountList follow:
    Note that I have 3 partitions (2 equal at ~20M and 1 for the remainder)
      and that my maxtransfer parm is set to 4096.
         
/* MountList for V1.3 */


/* An example mount entry using the fast file system with a partition
   of the hard disk using the 2090 disk controller.  PREP has been
   used to create the first partition (up to cylinder 20).  The second
   partition is MOUNTed, using the following entry:
   NOTE: Some hard disk drivers require more stack than specified here.
   Some may required less.
   (The hard disk is not included; this is only an example.)
*/

DH0:
    Device = overdrive.device
    FileSystem = l:FastFileSystem
    Unit   = 1
    Flags  = 0
    Surfaces  = 6
    BlocksPerTrack = 26
    Reserved = 2
    Interleave = 0
    LowCyl = 1  ;  HighCyl = 260
    Buffers = 5
    GlobVec = -1
    BufMemType = 2
    MaxTransfer = 4096
    Mount = 1
    DosType = 0x444F5301
    Mask = 0x7FFFF
#
DH1:
    Device = overdrive.device
    FileSystem = l:FastFileSystem
    Unit   = 1
    Flags  = 0
    Surfaces  = 6
    BlocksPerTrack = 26
    Reserved = 2
    Interleave = 0
    LowCyl = 261  ;  HighCyl = 520
    Buffers = 5
    GlobVec = -1
    BufMemType = 2
    MaxTransfer = 4096
    Mount = 1
    DosType = 0x444F5301
    Mask = 0x7FFFF
#
DH2:
    Device = overdrive.device
    FileSystem = l:FastFileSystem
    Unit   = 1
    Flags  = 0
    Surfaces  = 6
    BlocksPerTrack = 26
    Reserved = 2
    Interleave = 0
    LowCyl = 521  ;  HighCyl = 607
    Buffers = 5
    GlobVec = -1
    BufMemType = 2
    MaxTransfer = 4096
    Mount = 1
    DosType = 0x444F5301
    Mask = 0x7FFFF
#
    

    
    Thanks for making the new driver available.  I won't be able to
    rerun the low level format until Monday night, but I'll report again
    here as soon as I do.  I was wondering how I was going to be able
    to change the interleave factor, now I know.  I'm glad that PP has
    taken it into account.  I was a little disappointed when I ran
    diskperfa against my newly formatted FFS device and it did not compare
    favorably to some of the timings I saw on usenet. 
    
    Anyway, in short, I've been running just fine for days now, but I
    have been running using the software optimised for 1.2.

    
    Gary

Re: .0

Further investigation over the weekend seems to indicate that the problems
I am having with the Overdrive controller are hardware, not software.

I had though that the device driver might have used uninitialized variables
since crashes seemed to occur under a warm boot.  Switching the Amiga
off and then back on (to clear memory) seemed to always fix the problem.
Since this could also be the symptom of a heat problem, I once turned
on the Amiga, waited what seemed to be a long time, and then booted it.
I booted fine.

Well, this weekend, turning the machine off temporarily (for the minimum
5 seconds mandated by the manual) didn't solve the problem.  Turning
the machine off for several minutes did solve the problem.

Sunday, I turned the machine on and didn't feed it a boot disk for two hours.
When I finally gave it a boot disk, it crashed doing hard disk I/O.

Turning the machine off for a few minutes fixed the problem.

Thus, it sounds like a heat related hardware problem.

The problem might be in my 8 meg memory board.  I've pulled the memory
board to see if I can get a crash without it.

The memory board and the disk controller card are in adjacent slots.
Since the space between slots is narrow, the reduced airflow might
be the culprit.

I am a little worried that removing either card from the machine
increases the air flow enough around the other card that the
heat related bug will not be able to be pinned down.

Both the memory board and the disk controller are under warranty, so
I am set if I can pin it on either.

I haven't been able to crash my Pacific Peripherals controller all day.
I removed my 8 Meg memory board from the system, and tried to crash the
dish controller.

I couldn't.

I put the board back and tried to crash the system.

I couldn't.

I ran extensive diagnostics on the memory board.  It checked out ok.

I've been running the system seven hours without a crash.

What changed?  I don't know.  Did the system get better because I
reseated the memory board?  Did vacuuming the large dust bunnies
off the configuration jumpers on the memory board solve the problem?

Beats me.

After my two hours of testing failed to crash the system, I moved
the memory board to the last expansion slot.  I left the disk controller
in the first expansion slot.  I figure that configuration will minimize
heat transferred for board to board, maximize the airflow between
the boards, and minimize the dust build up on the components on the
memory board.

    Re .3
    
    Glad things are going better.
    
    How about another topic.  I've been working to get my drive formatted
    under FFS to provide me with the best possible performance.  I've
    been using DISKPERFA as a guideline.  I'm being driven to distraction
    trying to get the block read/write times as good as those seen on
    the usenet.  I tweaked the interleave parm in the overdrive.drives
    entry for the ST157 from 2 to 3.  I've got maxtransfer set to 64K.
    And I've gotten roughly the same performance no matter what I do.
    
    Anyone have any suggestions?
    
    Gary

    
    Don't know about your specific controller, but with the C Ltd system,
    interleave can only be set by deep formatting.  The mounlist entry
    is always set to zero.
    
    Ed.

    Byte 04 in the format field sets the interleave format of the drive.  Ed is
    correct, as with the C-Ltd controller, you need to low level format
    the drive to change the interleave.
    
    As a side note, you can run two different controllers simultaneously.
     I ran the C-Ltd controller and the Overdrive controller, (as well
    as the GVP Controller) all at the same time, but you have to be
    veeerrry careful!
    
    I did this to make rebuilding drives on different controllers easier,
    since each controller formats the drive differently.  The DMA
    controllers, as recent postings have shown, seem to fare better
    on larger transfers.  The other controllers seem to do better with
    small to medium transfers.  All can be optimized to be very comparable
    in speed to each other.  It seems to boil down, at least to me,
    on personal preference.
    
    The only crash I had with the OverDrive was my own fault.  If you
    have two controllers in your system, you MUST bring up the non-DMA
    controller FIRST, i.e. mount a drive connected to the non-DMA
    controller first, then mount a drive from the DMA controller.  Doing
    the reverse will hang the system big time (doesn't hurt the disk
    thankfully!).
    
    By the way, At one time I had almost all the slots in the 2000 full,
    2 internal floppies, internal hard drive in 5 1/4 bay, two 2 meg
    expansion mems, two disk controllers,  a CMI accelerator board,
    a borrowed flickerFixer, and a very warm workshop.  All this was
    run round the clock for over a week without any over heating or
    power problems.
    
    This should be a separate topic, but if you try and run some V1.3
    ROMS at 14 Mhz using the CMI processor Accelerator, you may have
    problems ranging from intermittent crashes to full lockup of the
    system when you switch from 7mhz to 14 mhz. The fix is to get another
    V1.3 ROM and hope (expensive) or swap back to the V1.2 ROM.  I verified
    this with the folks at CMI, and they are aware of the problem. 
    The ROMS used may or may not be marginal at 14 mhz, depending on
    the batch, vendor, phase of the moon, etc..  The fix is to simply
    disable the fast ROM option on the CMI board.
    
    John
    

Re: .5

You are entirely correct, Ed.  The Interleave parameter in the Mountlist
is useless for SCSI drives.  The interleave on SCSI drives is set by the
low-level format program that is run before doing the AmigaDOS format.

However, the author of .4 is doing the right thing.  He is setting the
interleave parameter of his disk by editing the overdrive.drives file.
The Overdrive controller's low level format utility reads this file
when it runs to discover what the characteristics are of the drive
attached to the controller.  When the Overdrive utility program runs,
it asks the drive what model it is, looks up the model in the
overdrive.drives file, and then the utility knows the geometry of
the drive and what interleave factor to use when doing a low level
format.

Re: .4

For an ST-157N and Overdrive controller, the best interleave to use is
2.  Using an interleave of 3 just decreases performance by a little.
(Actually, I believe write times speed up a little, but read times
suffer.)  At an interleave of 2, one block transfers are slow (about
20K/sec), but any multiple buffer transfer screams (I believe the
next larger buffer size used by diskperfa results in 120K/sec.  A
32K buffer results in 300K/sec transfer.)  Since programs that use
single block buffers are rare, that statistic isn't worth worrying about.

I believe your problem is your mountlist entry (as given in .1)

>DH0:
>    Device = overdrive.device
>    FileSystem = l:FastFileSystem
>    Unit   = 1
>    Flags  = 0
>    Surfaces  = 6
>    BlocksPerTrack = 26
>    Reserved = 2
>    Interleave = 0
>    LowCyl = 1  ;  HighCyl = 260
>    Buffers = 5
>    GlobVec = -1
>    BufMemType = 2
>    MaxTransfer = 4096
>    Mount = 1
>    DosType = 0x444F5301
>    Mask = 0x7FFFF
>#

Remove the Mask parameter.  The Mask parameter allows the Mountlist
to inform the Fast File System that there exists memory in your
Amiga that the disk controller can not access.  This situation
is rare: about the only time is occurs is when you have a 68020
or 68030 board in your Amiga with private memory.  (Note that
the Commodore 68020 board has memory on it, but it isn't private.
A device can DMA to it.)

The overdrive controller is perfectly happy doing DMA to Chip memory,
half-fast memory (the other 512K in a 2000 or 500), or expansion
memory.

Removing the Mask parameter will cause the system to use the default
value which is "do DMA to anything with a 24 bit address" (this is
the entire addressing range of a 68000).

With your Mask, the controller will refuse to do DMA to any user
buffers located in your half-fast memory.  Effectively, you have
turned the Fast File System into the old file system.  Whenever
the file system sees a request for a read into a non-DMA'able
buffer, the file system does single block DMA into one of its
private buffers (set up by Buffers = in the Mountlist), and then
uses the CPU to copy the data into the user buffer.

As an experiment, you can keep the Mask parameter, but run NoFastMem
before running diskperfa.  Since NoFastMem will force diskperfa's
buffers to be allocated into chip ram (which is DMA'able according
to your mountlist), you should see a tremendous speed up.

Of course, the correct, permanent solution is to delete the Mask
parameter from the mountlist.

I have a few criticisms of your other Mountlist entries:

BufMemType should always be odd.  This parameter is the "type of memory"
argument passed to the AllocMem function when the system sets up the
file system's private buffers.  The low order bit says that the memory
should be "public" memory that can be shared between tasks.  Setting
this bit isn't important right now since AmigaDOS doesn't do memory
management, but it doesn't hurt to look to the future.  (Ok, I'm
being a bit silly here: you'd need a hardware and software upgrade
before this became an issue.)

Good values for BufMemType are:
	1	Allocate fast memory if available, otherwise use chip
	3	Allocate only chip memory
	5	Allocate only fast

I recommend a value of 1.  Unless you run tons of memory in your
startup sequence, it will result in the buffers being in fast memory.
If you do manage to use up all of your "fast" memory before mounting
the partition, it will allow the mount to succeed (but use chip memory).

Your mountlist uses 2.  This sets the chip-memory-only flag.  Since
this gains you nothing and limits your ability to open screens and
windows, it isn't a good idea.

You have LowCyl = 1.  You can gain a bit of extra room by setting
LowCyl = 0.  You will have to reformat (using the AmigaDOS format)
in order to use that partition after making this change.

You may want to bump up your MaxTransfer parameter.  Since my system
started working, I've been using MaxTransfer = 65536.  Larger values
would probably work (yes I've tested this by using a program with super
large buffers), but programs with such large buffers are rare.  The
value you are using will put a performance cap on programs that more
than 4K of buffer).

You may want to bump up your Buffers =  parameter.  The Fast File System
works well with large number of buffers because it is more intelligent
that the old file system about what is worth buffering and what isn't.
Additional buffers help when working with large directories.  This is
a trade off against I/O speed versus memory size, and thus is difficult
to make.   Since you only have a one meg system, you definitely don't
want a large number here, but "burning" an extra 50K of memory for
buffers may make things seem smoother.  (Each buffer is half a K.)
So try and see if you see any difference with Buffers = 20 for each of
your three partitions.

By the way, another night of beating on my system turn up no Gurus.
Reseating my memory board (or vacuuming it) seems to have fixed
my problems.

P.S., the sample Mountlist included in the ARC I uploaded isn't
necessarily a great one.   I made minimal changes to the one
generated by the overdrive utilities program.

    
    Re:  CMI Accelerator reading the ROMS at 14 MHz...
    
    John, the last time I spoke with Bill at CMI, he indicated that
    he was considering allowing a wait state in the CMI board to deal
    with slower ROMS.  Alternately, he was considering reading them
    at 12 MHz, which all ROMS seem to be capable of.
    
    Until this is resolved, I'm staying with my 1.2 ROMS.
    
    Ed.

    Re: .7
    
    Thanks for your input.  After trying a myriad of combinations of
    mountlist parms last weekend I tried removing the MASK parm, as you suggest.
    Unfortunately, I was rewarded with a number of gurus.  It behaved
    beautifully, for awhile, but oddly enough, when I loaded up my copy
    of DME.  Task held.  It was repeatable.  Now I'd be willing to give
    up DME if it were the only thing choking on the truly fast FFS.
    However, on occasion I'd get gurus on startup.  It seemed to happen
    when DMouse spawns its process.  Now one thing that I *didn't* do,
    was Format the partition after changing the mountlist.  It didn't
    seem necessary in this case.
    
    Anyway, it was fast while it lasted but I have set the numbers back
    until I have more time to experiment.  (And reseat my Overdrive
    card.)
    
    
    Gary

Re: .9

Are you using the latest version of the driver software that I uploaded?
If not, that could be your problem.

You should need to do a reformat unless you change the low or high
cylinder number or do a low level format.

The Mountlist entries that I use are:

/* OverDrive Drive definition */

/* SEAGATE  ST157N */

DH0:	Device = overdrive.device
	Unit = 1
	Flags = 9
	Surfaces = 6
	BlocksPerTrack = 26
	Reserved = 2
	Interleave = 0
	LowCyl = 0  ;  HighCyl = 304
	Buffers = 256
	BufMemType = 1
	GlobVec = -1
	FileSystem = l:FastFileSystem
	Mount = 1
	Stacksize = 0x800
	MaxTransfer = 65536
	DosType = 0x444F5301
#


DH1:	Device = overdrive.device
	Unit = 1
	Flags = 9
	Surfaces = 6
	BlocksPerTrack = 26
	Reserved = 2
	Interleave = 0
	LowCyl = 305  ;  HighCyl = 608
	Buffers = 256
	BufMemType = 1
	GlobVec = -1
	FileSystem = l:FastFileSystem
	Mount = 1
	Stacksize = 0x800
	MaxTransfer = 65536
	DosType = 0x444F5301
#


You should reduce the value of Buffers = to something more reasonable
for your 1 meg system.

Also, be aware that not all ST-157n drives have a cylinder number 608.
You may only be able to have a HighCyl = 607.

>    Unfortunately, I was rewarded with a number of gurus.  It behaved
>    beautifully, for awhile, but oddly enough, when I loaded up my copy
>    of DME.  Task held.  It was repeatable.

My most usual Guru occurred when loading a large program in from disk.
My usual Guru numbers were 3 (most common) and 4.

>And reseat my Overdrive card.

It was reseating (or vacuuming) my memory card that fixed my problem.
I never removed the overdrive card.  However, reseating your board
can't hurt.

By the way, I wrote .7 last Wednesday just before the machine hosting
this notesfile went down.  It's been about a week now with no crashes!

    Re .10
    
    I am using the new software that you uploaded.  Thanks.  
    
    My mountlist now looks very much like yours, except that I'm using
    30 buffers instead of 256.
    
    I reseated the board last night, to no avail.
    
    The gurus I'm seeing are typically 3's and 4's as well.  I don't
    think that I would say that it gurus when I load large files.  DME
    is not particularly large, and I am able to load some that are larger.
    
    I'll do some more experimenting later.
    
    
    Thanks,
    
    Gary

    I'm continuing this here rather than via mail because it might be
    of interest to others...
    
    Randy,
    
    Are you a workbench user?  
    
    I have determined that my problem with
    the Overdrive stems from the fact that I set my MaxTransfer value
    too high.  Andy Finkel of CBM suggested that I lower it to 1024
    and when I did things went much better.
    
    Anyway, I find that I can load some of my problem programs via CLI with
    the MaxTransfer rate set over 16K, but it seems that as soon as
    I try to start some of these from WB, the guru's return.  As a
    consequence, I've lowered the rate to 1K.  
    
    Am I nuts, or is this possible?
    
    Gary

Re: .12

Yes, I use the Workbench quite a lot.  And my system has not crashed
since I reseated the memory board.

Are you sure you installed the software properly?  Try putting the driver
in both the devs directory of your boot floppy and your hard disk's
devs directory.

    Re: .13
    
    Yes, I've got the .device in both places.  I've also got the same
    mountlist in both places.  I tried moving the Overdrive card away from
    the power supply last night to see if I could lessen any heat buildup.
    I noticed, or thought I noticed, that the # of gurus increased the
    longer I had the machine turned on.  So I thought that moving it away
    from the biggest source of heat might make a difference.  Could
    be.  But I still get gurus if I set the MaxTransfer rate much above
    512.  Not ideal, but I can live with it.  Besides, I've gotten my
    fill of tweaking.  I want to actually *use* the machine for a change.
    
    Perhaps I'll call Pacific Periph again next week and see if they
    have anything new to tell me.
    
    Thanks for your help,
    
    Gary