Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Mitchy Mine » Wed, 09 Jun 1999 04:00:00



  Legend states that MaxTransfer came about as a way to deal with the DMA
limitations of IDE drives.  Yet my new phase5 SCSI IV Kit docfiles say
that SCSI users have to be careful with MaxTransfer too.  I don't recall
any of the many other SCSI adapters ever needing MaxTransfer settings.
Why might this be?  I work with REMOVABLE MEDIA (Iomega, etc) which means
I need to find a MaxTransfer and Mask that will work on varying Amigas.
Since the RDB contains the Mask and MaxTransfer info, every time a volume
is moved over to a different Amiga, potential problems (even data damage)
can occur.  I'm fuming that AmigaOS STILL handles Removeable Media so
ineptly.

 It seems flawed to me that Mask info is defined on the media rather than
by inspecting the IO card firmware and/or active memory spaces.

  I get the impression from the docfiles that maybe certain SCSI
adapters might require different MaxTransfers?  Also MASK can be a big
problem due to different memory regions being available (varying ChipMem
or different kinds of Fast RAM: 16bit vs 32bit) depending on how any one
Amiga is configured.  There's 24 bit address space and 32 bit address
space.  And different amount of Chip RAM available (sometimes it's
contiguous with Fast, sometimes not), not to mention pseudo-FastRAM that
can reside in ChipMem-address-space.

 HELP!  I need to set up Mask and MaxTransfer on removable disks (Iomega
mostly) so they can be harmlessly passed around between variably
configured Amigas like:

 unit  OS   SCSI_unit        Accel/Expansion         RAM Fast/16/32/Chip
 ----- ---- --------------- ------------------------ -------------
 1200  3.0  GVP-m 1291      GVP 1230 TurboII+ 030/50 8MB 32bit
 1200  3.0  P5 SCSI IV Kit  Phase5 Blizzard 1230-IV  8-128MB 32bit
 1200  3.0  SurfSquirrel    Assorted                 Assorted
 2000  1.3  GVP HC+8 (2MB)  030 CBM-2630, 1MB Chip   2MB 16bit, 4MB 32bit
 2000  2.1  2090A           CBM2058 2MB Fast 16bit   2MB 16bit, 512K Chip
 2000  2.1  2091            1MB ChipRam Fatter Agnus 2MB 16bit (on 2091)
 1000  1.3  2091 with 2MB                            2MB 16bit, 512KChip
 1000  2.1  2091 with 2MB  *InsiderII w/1.5MB Fast*  3.5 Fast, 512K Chip
 A500  2.1  GVP A500-HD8+   GVP HD8+ Impact SeriesII 1MB Chip, 4MB Fast
 4000  3.0  Zorro DataFlyer 8MB 32bit
 A500  1.3  2090A           some kind of BaseBoard?  1MB Fast, 1MB Chip
 3000  Var* Mostly CBM native                        Varies*

 A universal Mask and MaxTransfer is what I need.

 I checked some HiSoft mountlists for Jaz/Zip removeable media and sure
enough, MaxTransfer is set to 0x100000.  That's only 1,048,576 bytes,
which sounds weak.  Previously, I never put much faith in HiSoft's iomega
savvy since they used keywords like SectorsPerBlock and
SectorSize/BlockSize (which failed on my A2000's ARP and WB2.1 Mount
commands, and also my A1200's 3.0 Mount command).  My pal with a
SurfSquirrel had the same problem, so we both had to comment out certain
keywords to get the HiSoft Jaz/Zip mountlists/DosDrivers to work.

  But after reading the P5 manual I'm thinking HiSoft was (at least) right
about MaxTransfer.  But is this value dependent on the peripheral, or the
adapter card (or can it be both)?  How does one find out the particulars?
I'm thinking maybe this is why the GVP 1291 SCSI adapter always screwed up
for my Iomega drives.  Maybe my Mask and MaxTransfer were illegal.

  As an aside, I'm thinking about finally installing AFS (or maybe I'll
waste some money and forgo it and try PFS), but it uses 1024 bytes per
sector instead of 512, so I don't know how to set the MaxTransfer for such
a filesystem.

Thanks for your expert help!

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Ralph Schmi » Wed, 09 Jun 1999 04:00:00



Quote:>  Legend states that MaxTransfer came about as a way to deal with the
DMA
>limitations of IDE drives.  Yet my new phase5 SCSI IV Kit docfiles
say
>that SCSI users have to be careful with MaxTransfer too.  I don't
recall
>any of the many other SCSI adapters ever needing MaxTransfer
settings.
>Why might this be?  I work with REMOVABLE MEDIA (Iomega, etc) which
means
>I need to find a MaxTransfer and Mask that will work on varying
Amigas.
>Since the RDB contains the Mask and MaxTransfer info, every time a
volume
>is moved over to a different Amiga, potential problems (even data
damage)
>can occur.  I'm fuming that AmigaOS STILL handles Removeable Media so
>ineptly.

All p5 devices(let's ignore Blizzard 3) use 0x00ffffff as the max
transfer which is also the length for scsi direct
transfers(devices/scsidirekt.h) which must be supported.

Quote:>24 bit is optional.

--


 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Rask Ingemann Lambertse » Wed, 09 Jun 1999 04:00:00


On 08-Jun-99 13:12:46, Mitchy Miner wrote the following about "Removable SCSI Disks and Universal Mask/MaxTransfer Problems?":

Quote:>   Legend states that MaxTransfer came about as a way to deal with the DMA
> limitations of IDE drives.

   AFAIK MaxTransfer has been there much longer than that. If you ask me, I
think MaxTransfer (and Mask, for that matter) came about because C= shipped HD
controllers with broken drivers. The A590 driver that doesn't check for
24bitDMA before trying DMA, to name one.

   That it much later turned out to be a workaround for broken IDE drive
firmware is purely coincidental.

Quote:> Yet my new phase5 SCSI IV Kit docfiles say
> that SCSI users have to be careful with MaxTransfer too.

   Ralph Laire has confirmed that this is also the case with the *Storm
PPC SCSI. Unforgivable for a driver written in the middle to late 1990's.

Quote:> I don't recall
> any of the many other SCSI adapters ever needing MaxTransfer settings.
> Why might this be?

   They might have working drivers.

Quote:> I work with REMOVABLE MEDIA (Iomega, etc) which means
> I need to find a MaxTransfer and Mask that will work on varying Amigas.
> Since the RDB contains the Mask and MaxTransfer info, every time a volume
> is moved over to a different Amiga, potential problems (even data damage)
> can occur.  I'm fuming that AmigaOS STILL handles Removeable Media so
> ineptly.

   There is nothing wrong about AmigaOS's handling of the matter. You cannot
blame AmigaOS for problems caused by broken drivers.

Quote:>  It seems flawed to me that Mask info is defined on the media rather than
> by inspecting the IO card firmware and/or active memory spaces.

   It is not intended for normal use. Mask and MaxTransfer are emergency
workarounds for driver bugs. They only exist so people can at least copy their
files off the disk to somewhere else, or at least still use their HD until
a bug fixed driver is available. You're supposed to use 0xFFFFFFFF for both in
normal use.

Quote:>  2000  1.3  GVP HC+8 (2MB)  030 CBM-2630, 1MB Chip   2MB 16bit, 4MB 32bit

   According to the documentation, the driver works as far as Mask and
MaxTransfer is concerned, and that is my experience with it too.

   I wish you good luck with the A2090 and A2091, at least with C='s ROMs.

Quote:>  A universal Mask and MaxTransfer is what I need.

   Difficult given the multitude of buggy drivers and the variety in their
bugs. Mask = 0x0003FFFF (first 256 kB of chip memory) and MaxTransfer =
0x00000100 (512 bytes) ought to work with even the most broken drivers you
can imagine.

Quote:>   As an aside, I'm thinking about finally installing AFS (or maybe I'll
> waste some money and forgo it and try PFS), but it uses 1024 bytes per
> sector instead of 512, so I don't know how to set the MaxTransfer for such
> a filesystem.

   What is the problem?

Regards,

/T\

| Registered Phase5 developer  | WWW: http://www.veryComputer.com/~c948374/   |
| A4000, 775 kkeys/s (RC5-64)  | "ThrustMe" on XPilot and EFnet IRC      |
| Never underestimate the bandwidth of a CD-ROM flying through the lab.  |

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Ben Hutching » Thu, 10 Jun 1999 04:00:00




Quote:>  Legend states that MaxTransfer came about as a way to deal with the DMA
>limitations of IDE drives.

It didn't; it's been around for much longer than that.  It is not
designed to deal with hardware limitations; the driver should deal
with those.  It happens to be useful as a workaround for bugs in
some IDE drives that Commodore's IDE scsi.device didn't deal with
before version 40.

I think the real purpose of MaxTransfer is to limit the time that SCSI
devices tie up the memory bus.  This is only a guess, though.

<snip>

Quote:>I work with REMOVABLE MEDIA (Iomega, etc) which means
>I need to find a MaxTransfer and Mask that will work on varying Amigas.

No, you don't.  Use a mountlist/mountfile instead.

<snip>

Quote:>I'm fuming that AmigaOS STILL handles Removeable Media so ineptly.
> It seems flawed to me that Mask info is defined on the media rather than
>by inspecting the IO card firmware and/or active memory spaces.

That is impossible to do.  The driver interface does not have a way of
telling its users what the optimal alignment and positioning of
buffers is, though it should.  Drivers are required to deal with
buffers that are non-optimally aligned or positioned, so you should
not *need* to set Mask unless you have a buggy driver.  Don't blame
broken third-party drivers on Commodore-Amiga!

Quote:>  I get the impression from the docfiles that maybe certain SCSI
>adapters might require different MaxTransfers?

Not AFAIK.

<snip>

Quote:> I checked some HiSoft mountlists for Jaz/Zip removeable media and sure
>enough, MaxTransfer is set to 0x100000.  That's only 1,048,576 bytes,
>which sounds weak.

<snip>

Why?  You aren't still under the misapprehension that MaxTransfer
controls speed, are you?  It actually controls the maximum size of
individual transfers.  You may as well set it to 64K (0x10000); that
should be barely slower than unlimited transfers.
--

Team *AMIGA* | Jay Miner Society | Linux - the choice of a GNU generation
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Ralph Schmi » Fri, 11 Jun 1999 04:00:00



Quote:>On 08-Jun-99 13:12:46, Mitchy Miner wrote the following about

"Removable SCSI Disks and Universal Mask/MaxTransfer Problems?":

Quote:>>   Legend states that MaxTransfer came about as a way to deal with
the DMA
>> limitations of IDE drives.

>   AFAIK MaxTransfer has been there much longer than that. If you ask
me, I
>think MaxTransfer (and Mask, for that matter) came about because C=
shipped HD
>controllers with broken drivers. The A590 driver that doesn't check
for
>24bitDMA before trying DMA, to name one.

devices/scsidisk.h scsi_length > 24 bit is *optional*.

The reason why the maxtransfer is 24bit everywhere is that basicly
every scsi chip i know only has a 24bit dma counter.
To work around this may result into several design problems of
the hardware depending on the address location a transfer started
or for the device which may need a 2nd layer(task) which would also
need to alloc memory for every io job to handle such case cleanly
but that would increase io latency which is very important under
amigaos as the filesystem doesn't make smart use of huge blocks.
There's far more involved in the issue than saying...
uhhh..that dumb device doesn't support mask 0xffffffff and mask
transfer 0xffffffff therefore it sucks.

Basicly cbm set their own dma+scsi limitations as the default for
scsidirekt.h implementations.

Quote:>   That it much later turned out to be a workaround for broken IDE
drive
>firmware is purely coincidental.

>> Yet my new phase5 SCSI IV Kit docfiles say
>> that SCSI users have to be careful with MaxTransfer too.

>   Ralph Laire has confirmed that this is also the case with the
*Storm
>PPC SCSI. Unforgivable for a driver written in the middle to late
1990's.

Maybe it's time you write your own drivers to make first hand
experience about multi threaded scsi drivers, chip limitations
and implementation limitations where dma is for example only
possible on longword align addresses(maybe after a dma the
implementation throws away bytes in the dma fifo so you can't
bend over unaligned addresses with little handcoded copies)
or the chip doesn't really handle polling.
Or maybe it handles polling but only byte/int polling and that
only in async mode.
The 5.xxx fastlane driver even does this sick thing to switch
off sync,async to handle odd transfers and maybe even switch
back into a byte/int poll mode in certain situations.
I can tell you how painful that was with 1 device layer which
you probably can't imagine as you haven't written a lowlevel
scsi driver yet.

Quote:>> I don't recall
>> any of the many other SCSI adapters ever needing MaxTransfer
settings.
>> Why might this be?

>   They might have working drivers.

>> I work with REMOVABLE MEDIA (Iomega, etc) which means
>> I need to find a MaxTransfer and Mask that will work on varying
Amigas.
>> Since the RDB contains the Mask and MaxTransfer info, every time a
volume
>> is moved over to a different Amiga, potential problems (even data
damage)
>> can occur.  I'm fuming that AmigaOS STILL handles Removeable Media
so
>> ineptly.

>   There is nothing wrong about AmigaOS's handling of the matter. You
cannot
>blame AmigaOS for problems caused by broken drivers.

>>  It seems flawed to me that Mask info is defined on the media
rather than
>> by inspecting the IO card firmware and/or active memory spaces.

>   It is not intended for normal use. Mask and MaxTransfer are
emergency
>workarounds for driver bugs. They only exist so people can at least
copy their
>files off the disk to somewhere else, or at least still use their HD
until
>a bug fixed driver is available. You're supposed to use 0xFFFFFFFF
for both in
>normal use.

devices/scsidisk.h scsi_length

and btw..the wd chip also only has a 24bit counter and now
you could find out if it breaks after 16MB length:-)
Beyond that...you could resource the scsi.device and see
how ugly it is(to work around all kinds of WD problems/limitations):-)
I'm sure Randell Jesup still has bad dreams about the WD
scsi.device:-)

--

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Rask Ingemann Lambertse » Fri, 11 Jun 1999 04:00:00


On 09-Jun-99 02:32:27, Ben Hutchings wrote the following about "Re: Removable SCSI Disks and Universal Mask/MaxTransfer Problems?":



> <snip>
>> I checked some HiSoft mountlists for Jaz/Zip removeable media and sure
>>enough, MaxTransfer is set to 0x100000.  That's only 1,048,576 bytes,
>>which sounds weak.
> <snip>
> Why?  You aren't still under the misapprehension that MaxTransfer
> controls speed, are you?  It actually controls the maximum size of
> individual transfers.  You may as well set it to 64K (0x10000); that
> should be barely slower than unlimited transfers.

   Breaking up transfers can actually cause a hard disk to have to make a whole
revolution before resuming that transfer, due to the time lost in command
overhead. If that is the case, you will see a noticable slowdown.

Regards,

/T\

| Registered Phase5 developer  | WWW: http://www.gbar.dtu.dk/~c948374/   |
| A4000, 775 kkeys/s (RC5-64)  | "ThrustMe" on XPilot and EFnet IRC      |
|      Did you ever notice how fast Windows runs? Neither did I...       |

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Rask Ingemann Lambertse » Fri, 11 Jun 1999 04:00:00


On 10-Jun-99 10:11:06, Ralph Schmidt wrote the following about "Re: Removable SCSI Disks and Universal Mask/MaxTransfer Problems?":


>>On 08-Jun-99 13:12:46, Mitchy Miner wrote the following about
> "Removable SCSI Disks and Universal Mask/MaxTransfer Problems?":
>>>   Legend states that MaxTransfer came about as a way to deal with
>>> the DMA limitations of IDE drives.

>>   AFAIK MaxTransfer has been there much longer than that. If you ask
>> me, I
>> think MaxTransfer (and Mask, for that matter) came about because C=
>> shipped HD
>> controllers with broken drivers. The A590 driver that doesn't check
>> for
>> 24bitDMA before trying DMA, to name one.
> devices/scsidisk.h scsi_length > 24 bit is *optional*.

   We're _not_ talking about direct SCSI commands (HD_SCSICMD), which is what
devices/scsidisk.h is about. We're talking about the standard Exec device
CMD_READ/CMD_WRITE commands (and their NSD extensions), so anything that
devices/scsidisk.h says is completely irrelevant. Give me just one good
reason for a 16 MB limit on io_Length for those commands.

Quote:> The reason why the maxtransfer is 24bit everywhere is that basicly
> every scsi chip i know only has a 24bit dma counter.

   I'm asking for _good_ reasons.

   The reason that you (or anybody else) won't ever be able to come up with a
good reason is that a simple wrapper around the 16 MB limited command will
provide you with one without the limit.

BYTE Read16MBMax (ULONG offset, ULONG length, APTR mem, ULONG *actual);

#define 16MB (16*1024*1024)

BYTE ReadAsMuchAsYouLike (ULONG offset, ULONG length, APTR mem,
                          ULONG *actual)
{
        BYTE  error = 0;
        ULONG actual2;

        for (;
             length >= 16MB && !error;
             length -= actual2, *actual += actual2, offset += actual2,
             ((UBYTE *) mem) += actual2)
        {
                error = Read16MBMax (offset, 16MB, mem, &actual2);
        }

        if (error)
                return (error);

        if (length)
        {
                error = Read16MBMax (offset, length, mem, &actual2);
                *actual += actual2;
        }

        return (error);

Quote:}

Regards,

/T\

| Registered Phase5 developer  | WWW: http://www.gbar.dtu.dk/~c948374/   |
| A4000, 775 kkeys/s (RC5-64)  | "ThrustMe" on XPilot and EFnet IRC      |
|    The impossible is only something that hasn't happened to you yet.   |

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Ralph Schmi » Fri, 11 Jun 1999 04:00:00



Quote:>On 10-Jun-99 10:11:06, Ralph Schmidt wrote the following about "Re:

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?":


>>>On 08-Jun-99 13:12:46, Mitchy Miner wrote the following about
>> "Removable SCSI Disks and Universal Mask/MaxTransfer Problems?":
>>>>   Legend states that MaxTransfer came about as a way to deal with
>>>> the DMA limitations of IDE drives.

>>>   AFAIK MaxTransfer has been there much longer than that. If you
ask
>>> me, I
>>> think MaxTransfer (and Mask, for that matter) came about because
C=
>>> shipped HD
>>> controllers with broken drivers. The A590 driver that doesn't
check
>>> for
>>> 24bitDMA before trying DMA, to name one.

>> devices/scsidisk.h scsi_length > 24 bit is *optional*.

>   We're _not_ talking about direct SCSI commands (HD_SCSICMD), which
is what
>devices/scsidisk.h is about. We're talking about the standard Exec
device
>CMD_READ/CMD_WRITE commands (and their NSD extensions), so anything
that
>devices/scsidisk.h says is completely irrelevant. Give me just one
good
>reason for a 16 MB limit on io_Length for those commands.

>> The reason why the maxtransfer is 24bit everywhere is that basicly
>> every scsi chip i know only has a 24bit dma counter.

>   I'm asking for _good_ reasons.

I gave you several but you completely missed reading and
*understanding* them.

Quote:>   The reason that you (or anybody else) won't ever be able to come
up with a
>good reason is that a simple wrapper around the 16 MB limited command
will
>provide you with one without the limit.

Yeah..sure..in a theoretical world. I know that 24bit*8bit = 32bit
but that has nothing to do with the problems in a real world.

Quote:

>BYTE Read16MBMax (ULONG offset, ULONG length, APTR mem, ULONG
*actual);

Shows that you haven't thought about or even designed a multi threaded
1 layer device.

--

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Ben Hutching » Sun, 13 Jun 1999 04:00:00




>On 09-Jun-99 02:32:27, Ben Hutchings wrote the following about "Re:
>Removable SCSI Disks and Universal Mask/MaxTransfer Problems?":> In


>> <snip>
>>> I checked some HiSoft mountlists for Jaz/Zip removeable media and sure
>>>enough, MaxTransfer is set to 0x100000.  That's only 1,048,576 bytes,
>>>which sounds weak.
>> <snip>

>> Why?  You aren't still under the misapprehension that MaxTransfer
>> controls speed, are you?  It actually controls the maximum size of
>> individual transfers.  You may as well set it to 64K (0x10000); that
>> should be barely slower than unlimited transfers.

>   Breaking up transfers can actually cause a hard disk to have to make a whole
>revolution before resuming that transfer, due to the time lost in command
>overhead. If that is the case, you will see a noticable slowdown.

Decent SCSI controllers and device drivers will queue commands, so
there is minimal command overhead.  For IDE disks the driver will
usually limit transfers to 64K anyway to be safe, and the most you can
possibly transfer at once is 128K.  The better SCSI and even IDE disk
drives will buffer whole tracks, anyway, so it makes little difference
that there can be a brief pause between 64K blocks.
--

Team *AMIGA* | Jay Miner Society | Linux - the choice of a GNU generation
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.
 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Peter Rinn » Tue, 22 Jun 1999 04:00:00


Hello,
I'm looking for a copying program for floppy disk.
Does it thrue that program named "nibbler" at some years ago
was a very good one?
I need to copy 3,5" floppy disk, also bad sector and everything.

Peter Rinne

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Mike Leavit » Tue, 22 Jun 1999 04:00:00


Hello Peter Rinne

Quote:> Hello,
> I'm looking for a copying program for floppy disk.
> Does it thrue that program named "nibbler" at some years ago
> was a very good one?
> I need to copy 3,5" floppy disk, also bad sector and everything.

> Peter Rinne

I find Xcopy is good for most floppy disks. I think is is on Aminet,
though I got it years ago from a PD house (DevWare, I think).

--

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by vbende » Thu, 24 Jun 1999 04:00:00


Get XCopyPro.  The best damn pirate copy program available.

> Hello,
> I'm looking for a copying program for floppy disk.
> Does it thrue that program named "nibbler" at some years ago
> was a very good one?
> I need to copy 3,5" floppy disk, also bad sector and everything.

> Peter Rinne

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by Rask Ingemann Lambertse » Thu, 01 Jul 1999 04:00:00


On 12-Jun-99 15:52:54, Ben Hutchings wrote the following about "Re: Removable SCSI Disks and Universal Mask/MaxTransfer Problems?":



>>On 09-Jun-99 02:32:27, Ben Hutchings wrote the following about "Re:
>>Removable SCSI Disks and Universal Mask/MaxTransfer Problems?":> In


>>> <snip>
>>>> I checked some HiSoft mountlists for Jaz/Zip removeable media and sure
>>>>enough, MaxTransfer is set to 0x100000.  That's only 1,048,576 bytes,
>>>>which sounds weak.
>>> <snip>

>>> Why?  You aren't still under the misapprehension that MaxTransfer
>>> controls speed, are you?  It actually controls the maximum size of
>>> individual transfers.  You may as well set it to 64K (0x10000); that
>>> should be barely slower than unlimited transfers.

>>   Breaking up transfers can actually cause a hard disk to have to make a
>>   whole
>>revolution before resuming that transfer, due to the time lost in command
>>overhead. If that is the case, you will see a noticable slowdown.
> Decent SCSI controllers and device drivers will queue commands, so
> there is minimal command overhead.

   They can only queue commands if they get them (obviously, but this is an
important point). FFS from OS 2.x seems to send at most one read/write command
at a time during transfers, meaning that there won't be anything to queue at
the driver level. I don't know if this has changed in later versions.

Quote:> For IDE disks the driver will
> usually limit transfers to 64K anyway to be safe, and the most you can
> possibly transfer at once is 128K.

   I think the most you can ask the drive for is 256 sectors, but I haven't
read the whole ATA specification yet.

Quote:> The better SCSI and even IDE disk
> drives will buffer whole tracks, anyway, so it makes little difference
> that there can be a brief pause between 64K blocks.

   They only have so much buffer space. If they run out of read-ahead buffer
space, you'll lose a revolution. The overhead of an extra command can easily
cause this to happen if the buffer->host transfer rate isn't somewhat faster
than the disk->buffer transfer rate. In the case of something like
MaxTransfer, which is handles at a fairly high level (the file system), the
command overhead could perhaps be as much as a millisecond (depending on quite
a lot of factors, though).

Regards,

/T\

| Registered Phase5 developer  | WWW: http://www.gbar.dtu.dk/~c948374/   |
| A4000, 775 kkeys/s (RC5-64)  | "ThrustMe" on XPilot and EFnet IRC      |
| If a train station is where a train stops, what is a workstation then? |

 
 
 

Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

Post by William Overbaug » Tue, 13 Jul 1999 04:00:00


Lose a revolution? Ha! Thats a good one. Modern hard drives are all shipped with 1:1 interleave because they incorporate a multi-sector
buffer large enough that you dont need to worry about losing revolutions. The major bottlenecks in large transfers are the head seeks
and platter switches. The best way to get around these is to shorten the distances the head seeks, and to reduce the number of platters
(this is why you can find old 1.3g SCSI full height drives in the junk bin- they are *slow*). Yes, ATA does not support more than a 256
sector transfer (at least properly), but if you do the math, that works out to 128k (maxtransfer is rated in BYTES not SECTORS). Many
Klone drives are extremely crappy and cannot handle more than 128 sectors. Most PC bios'es dont send multi-sector requests anyway, so
the drive manufacturers are quite lazy about this.
 
 
 

1. FAQ? maxtransfer & mask for Hard disk

This might be a very FAQ, but I cant find the FAQ-file, so here we go!!

Could some kind soul out there explain what the 'maxtransfer' and 'mask'
fields in HDToolBox means?
Is there some rule that says which values are the correct ones?

I have a 86M Fujitsu 'M26125' and a 100M Quantum '105S ProDrive LPS', both
using (spaces added for easier reading)
        mask='$7f ff ff fe' and
 maxtransfer='$00 ff ff ff'
in my A3000 with 2+8meg RAM.

--
-------------------------------------------------------------------------------
 Lars Holmgren_    _         | E-mail:               | Phone: +46 46 395254


2. FA: Maxxed Out Libretto 1100v at auction

3. Mask and MaxTransfer

4. Advance search form connected to access

5. Here we go again: Mask & MaxTransfer settings

6. Client Server & Open Systems Conference (BEAQM0T)

7. A4000 IDE MaxTransfer and Mask settings?

8. XBOX Live

9. MaxTransfer and Mask

10. Ancora su MaxTransfer e Mask

11. Mask/MaxTransfer, who does it?

12. Mask vs. MaxTransfer 1200 IDE

13. A3000: which Mask/Maxtransfer values best?