Here we go again: Mask & MaxTransfer settings

Here we go again: Mask & MaxTransfer settings

Post by Rolf Rotv » Tue, 22 Oct 1996 04:00:00



What are good maxtransfer and mask values for a Quantum Lightning 730 mb
running on the internal SCSI controller of a A3000-25 with 16 + 2 mb of ram=
?

Currently mask is set to 0xfffffe and maxtransfer to 0xffffff. =

Is it a good idea to avoid DMA'ing to chip ram? What numbers would I need=
 to
do that? (Hexadeciamal is greek to me :-)).

   Rolf

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Joanne D » Thu, 24 Oct 1996 04:00:00




Quote:

>Currently mask is set to 0xfffffe and maxtransfer to 0xffffff. =

<tera-sigh> Mask = 0x7ffffffx with x = F, E, or C (I use C) and
yor maxtransfer is just fine.

{^_^}     Joanne Dow, Amiga Exchange Editor on BIX, aka The Wizardess

          Opinions are my own hard won prejudices and nobody else's, darnitall.

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Cristiano Zanel » Sat, 26 Oct 1996 04:00:00


In a message dated 23-Ott-96 10:00:21, about Re: Here we go again: Mask &
MaxTransfer settings, Joanne Dow wrote to Tutti:

Quote:>>Currently mask is set to 0xfffffe and maxtransfer to 0xffffff. =

 JD> <tera-sigh> Mask = 0x7ffffffx with x = F, E, or C (I use C) and
 JD> yor maxtransfer is just fine.

I'm using an Oktagon controller with the same HD. Which File System are you
using to set Mask to 0x7ffffffc? I'm using 0xfffffe both on FFS and FFS.

*/Ciao./*


<sb>http://www.geocities.com/SiliconValley/Park/3210
<sb>IRC: kriss on #AmigaITA
<tsb>

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Kirk Straus » Mon, 28 Oct 1996 03:00:00


Quote:>In a message dated 23-Ott-96 10:00:21, about Re: Here we go again: Mask &
>MaxTransfer settings, Joanne Dow wrote to Tutti:
>>>Currently mask is set to 0xfffffe and maxtransfer to 0xffffff. =

 JD>> <tera-sigh> Mask = 0x7ffffffx with x = F, E, or C (I use C) and
 JD>> yor maxtransfer is just fine.

Frustration here is greatly understood (see also: parallel-port Zip?).
However, for as many people here that seem to know all about mask and
maxtransfer settings, I had one hell of a time finding anything in
writing.  Everyone says "Geez, not again!", but in this case I don't
think there's any other way for users to find this stuff out.

Quote:>I'm using an Oktagon controller with the same HD. Which File System are you
>using to set Mask to 0x7ffffffc? I'm using 0xfffffe both on FFS and FFS.

AFAIK, mask is totally dependent on your configuration.  If there are
memory blocks you don't want to be DMA-accessible (i.e. 2632 memory
strapped on a 2630 accelerator), you have to set mask to reject that
bank.


www.gxl.com/~kstrauser/ | Team AMIGA \X/  | "Thanks!  Wanna bite?"

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Gary Peak » Mon, 28 Oct 1996 03:00:00



Quote:>>In a message dated 23-Ott-96 10:00:21, about Re: Here we go again: Mask &
>>MaxTransfer settings, Joanne Dow wrote to Tutti:
>>>>Currently mask is set to 0xfffffe and maxtransfer to 0xffffff. =

 JD>>> <tera-sigh> Mask = 0x7ffffffx with x = F, E, or C (I use C) and
 JD>>> yor maxtransfer is just fine.

->>Frustration here is greatly understood (see also: parallel-port Zip?).
->>However, for as many people here that seem to know all about mask and
->>maxtransfer settings, I had one hell of a time finding anything in
->>writing.  Everyone says "Geez, not again!", but in this case I don't
->>think there's any other way for users to find this stuff out.

Quote:>>I'm using an Oktagon controller with the same HD. Which File System are you
>>using to set Mask to 0x7ffffffc? I'm using 0xfffffe both on FFS and FFS.

->>AFAIK, mask is totally dependent on your configuration.  If there are
->>memory blocks you don't want to be DMA-accessible (i.e. 2632 memory
->>strapped on a 2630 accelerator), you have to set mask to reject that
->>bank.

Please ... once and for all ... tell us all what the F, E, and C will map out
or not map out in the mask setting?

--
Gary Peake                                         Coordinator

1:106/7511.1                                       *Team AMIGA*
--

Do bl Sp ce is a v ry saf  me hod of driv  compr s ion

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Joanne D » Tue, 29 Oct 1996 04:00:00



>In a message dated 23-Ott-96 10:00:21, about Re: Here we go again: Mask &
>MaxTransfer settings, Joanne Dow wrote to Tutti:

>>>Currently mask is set to 0xfffffe and maxtransfer to 0xffffff. =

> JD> <tera-sigh> Mask = 0x7ffffffx with x = F, E, or C (I use C) and
> JD> yor maxtransfer is just fine.

>I'm using an Oktagon controller with the same HD. Which File System are you
>using to set Mask to 0x7ffffffc? I'm using 0xfffffe both on FFS and FFS.

He has an A3000. The A3000 DMA speaks to the full 32 bit address space.
Since Commodore reserved $80000000 and above for hardware devices the
controller should not talk up there ever. So the proper mask is as stated.

{^_^}     Joanne Dow, Amiga Exchange Editor on BIX, aka The Wizardess

          Opinions are my own hard won prejudices and nobody else's, darnitall.

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Kirk Straus » Tue, 29 Oct 1996 04:00:00


 JD>>>> <tera-sigh> Mask = 0x7ffffffx with x = F, E, or C (I use C) and
 JD>>>> yor maxtransfer is just fine.

Quote:>->>AFAIK, mask is totally dependent on your configuration.  If there are
>->>memory blocks you don't want to be DMA-accessible (i.e. 2632 memory
>->>strapped on a 2630 accelerator), you have to set mask to reject that
>->>bank.
>Please ... once and for all ... tell us all what the F, E, and C will map out
>or not map out in the mask setting?

Here's the technical description of mask.  If the binary inverse of mask
anded with any given memory location equals zero, then that memory
address is acceptable for DMA.  For example, (!7FFFFFFC)&&(68000000)=0,
so 68000000 is OK for DMA.

Picture this in binary:
   0xF: 11111111 - this won't mask out any values
   0xE: 11111110 - masks out odd values.  Forces word-alignment.
   0xC: 11111100 - only passes addresses divisible by 4.
                   Forces long-word alignment.

Some systems really slow down unless the DMA is long-word aligned, or
at least word-aligned.  For a good demonstration of this, download
DiskSpeed from Aminet, and compare long- vs. word- vs. byte-aligned
speeds.


www.gxl.com/~kstrauser/ | Team AMIGA \X/  | "Thanks!  Wanna bite?"

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Kirk Straus » Wed, 30 Oct 1996 04:00:00


Quote:>->>AFAIK, mask is totally dependent on your configuration.  If there are
>->>memory blocks you don't want to be DMA-accessible (i.e. 2632 memory
>->>strapped on a 2630 accelerator), you have to set mask to reject that
>->>bank.
>Please ... once and for all ... tell us all what the F, E, and C will map out
>or not map out in the mask setting?

What follows is a long-winded and hopefully minimally-inaccurate
explanation of how mask works.  If anyone sees any problems with this,
PLEASE write me!  I don't want to give anyone a wrong answer, and I'd
like to know of mistakes for my own benefit.

OK.  Here is my understanding of the problem, based on a DMA FAQ
(thanks, Claus!):

Before the controller does a DMA write to memory, it has to be able to
tell what locations are suitable for use.  This is where mask comes in.
The OS takes the binary inverse of mask and ANDs it with the mem. loc.
in question.  If the answer is 0, then the location is OK to use.
For simplicity, imagine that you have a computer with a 16-bit addressing
range.  In this case, memory would run in the range of 0x0000 to 0xFFFF.
Suppose that the mask setting in this system is 0x1FFF.  In binary, this
would be:

 a)  0001 1111 1111 1111

inverted =

 b)  1110 0000 0000 0000

Say you want to know if 0x0123 is good for DMA.  You take:

    0000 0001 0010 0011  (0x0123) and AND it with
    1110 0000 0000 0000  (b above) to get
    -------------------
    0000 0000 0000 0000 = 0.  Therefore, 0x0123 is OK for DMA.

How about 0x3000?

    0011 0000 0000 0000  (0x3000), ANDed with
    1110 0000 0000 0000  (part b again) results in
    -------------------
    0010 0000 0000 0000 != 0.  So 0x3000 won't work.
      ^

So, we want a mask that will allow our controller to access all of
our DMA-compatible memory, but nothing else.  After all that above,
this is actually the easy part.  As an example, here are the addresses
of the memory blocks in my 2500.

    0x0780 0000 - 0x07FF FFFF   - 8 meg on my 2632
    0x0020 0000 - 0x005F FFFF   - 4 meg on my 2630
    0x0000 0400 - 0x000F FFFF   - 1 meg chip mem

My RapidFire-II controller can DMA to the 2630 and chip memory banks,
but not the 2632's non-Auto-config memory.  I need a mask that will
accept all values up to 0x5FFFFF, but none of the memory above.
Piece o' cake: the magic number for a mask that does that is 0x5FFFFF.

This is ALMOST the final answer.  We still need to decide how to set the
last digit.

Given this, let's see how the last 8 bits of mask would work out for
F, E, and C:

    0xF = 1111 1111, inverted = 0000 0000
    0xE = 1111 1110, inverted = 0000 0001
    0xC = 1111 1100, inverted = 0000 0011

Because of this, a last digit of F won't block out ANY addresses because
of the last 8 bits of the address (any number AND 0 = 0).  However, E
will block any addresses ending with a rightmost bit of 1 (for example,
any odd addresses).  C takes this further.  It wont pass any address
ending in 01, 10, or 11.  This negates any addresses that aren't
long-aligned.

Many (most? all?) SCSI controllers DMA MUCH faster into long-aligned
memory blocks, so we'll want to make our mask accept only long-aligned
addresses.  To do this, I just take my basic mask setting from above
(0x5FFFFF) and change the last digit to C, giving 0x5FFFFC.  Voila!

To conclude: take the highest memory address you know your system can
use for DMA, and change the last digit to C.  Use HDToolBox, RDPrep, etc.
to make this your mask setting, and you're good to go.

I'm sorry for such a long posting.  However, when I went looking for
this information a little while back, I couldn't find it to save my
life.  A lot of people get mad when someone asks these questions, but
if noone ever answers, what are they supposed to do?  I hope this helps
someone.  If you have any questions, feel free to e-mail me (preferably
including output from ShowConfig).


www.gxl.com/~kstrauser/ | Team AMIGA \X/  | "Thanks!  Wanna bite?"

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Joanne D » Fri, 01 Nov 1996 04:00:00




Quote:>Please ... once and for all ... tell us all what the F, E, and C will map out
>or not map out in the mask setting?

First some real (boring to many) basics, "bitwise boolean logic". First we
generate two numbers, say 100101 and 110110 in binary representation. The
Boolean "AND" function gives as an output a 1 if and only if both inputs are
1. Thus 1 AND 1 = 1 but 1 AND 0 = 0 and 0 AND 1 = 0 and 0 AND 0 = 0. The
Boolean "OR" function gives a 1 if either input is a 1. Thus 1 AND 1 = 1 but
1 OR 0 = 1 and 0 OR 1 = 1 and 0 or 0 = 0. In the bitwise Boolean operations
we perform these operations on each bit position independantly. Thus the
two numbers above, 100101 and 110110, give 100100 as an output when ANDed
together and 110111 when ORed together.

The purpose of the MASK is to give the filesystem a simple way ot telling that
there is a problem transferring data between the controller and memory for
certain addresses. We set a 1 bit to determine all address bits that CAN be
legally set for ANY transfer the device driver makes. We set the others to
zero. Thus if the device driver is happy within the address range from $0
though $ffffff as long as the addresses are on even word boundaries (LSB
always zero) the mask becomes $fffffe, 0000 0000 1111 1111 1111 1111 1111 1110
in 32 bit binary notation. Now all the OS has to do is invert the mask value
to $FF000001 and AND this with the proposed start address for the transfer.
If the result is non-zero the transfer cannot be made. Then the OS (should
and probably does knowing Randall) test to see if the final address is
within this space using the same sort of technique with some diddling on the
low end, which is safe because all transfers are minimum 256 bytes long to
filesystem supported devices.

I hope this helps. (And Warren, please put this into your faq with due
credit to its source, of coures. {^_-})

{^_^}     Joanne Dow, Amiga Exchange Editor on BIX, aka The Wizardess

          Opinions are my own hard won prejudices and nobody else's, darnitall.

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Joanne D » Fri, 01 Nov 1996 04:00:00



>Frustration here is greatly understood (see also: parallel-port Zip?).
>However, for as many people here that seem to know all about mask and
>maxtransfer settings, I had one hell of a time finding anything in
>writing.  Everyone says "Geez, not again!", but in this case I don't
>think there's any other way for users to find this stuff out.

Warren Block maintains an excellent SCSI faq. I believe it is on AmiNet. I
also believe "deja-news" still exists.

{o.o}     Joanne Dow, Amiga Exchange Editor on BIX, aka The Wizardess

          Opinions are my own hard won prejudices and nobody else's, darnitall.
          (Of course all this is findable on BIX without much effort, too.)

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Warren Blo » Fri, 01 Nov 1996 04:00:00



: >
: >Frustration here is greatly understood (see also: parallel-port Zip?).
: >However, for as many people here that seem to know all about mask and
: >maxtransfer settings, I had one hell of a time finding anything in
: >writing.  Everyone says "Geez, not again!", but in this case I don't
: >think there's any other way for users to find this stuff out.

: Warren Block maintains an excellent SCSI faq. I believe it is on AmiNet. I
: also believe "deja-news" still exists.

Thank you very much!  The SCSI Examples document is on Aminet as part of
the A4000 Hardware Guide, I post it to c.s.a.hardware every so often, and
it is also on the CUCUG web site at

http://www.cucug.org/amiga/amiinfo/SCSIExamples.html

However, it doesn't address MaxTransfer or Mask, the former because it's
rarely a problem with SCSI, and the latter because it's a complex enough
software issue to need an in-depth discussion which is outside the scope
of that particular document.  But I think it's been fairly well explained
here.

--
-Warren R. Block * Rapid City SD USA

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Niels Kno » Sat, 02 Nov 1996 04:00:00



> Please ... once and for all ... tell us all what the F, E, and C will
> map out or not map out in the mask setting?

An "F" at the end of the mask allows transfer requests to be passed on
to the SCSI device driver regardless of the address alignment. This is
the way it should be with every correctly working device driver.

However some very ancient SCSI hostadapters have flawed device drivers
which crash or do nonsense when they are ordered to do a transfer to
or from an odd memory address.

This can be fixed by using a mask value which masks out those
addresses. A mask ending with an "E" prevents uneven byte-aligned
addresses from being presented to the device, while using a "C"
also masks out uneven word-aligned addresses.

Masked out transfer requests are then not forwarded to the device
driver in one piece, but splitted up, transferred through a "safe"
buffer and copied to or from the memory address originally requested
using the CPU.

This mechanism works by _dimensions_ slower than any possible method
the device driver itself could implement and use if it was allowed to.
Its performance can be considered the second-worst case (the only
worse being a crash). You can test it for yourself with DiskSpeed
which shows results with long-, word- and byte-aligned buffers.

See it as an emergency procedure of the OS which hopefully seldom
has to take action at all. Misaligned transfers should generally
not happen with any well-programmed application anyhow.

So if you have a decent device driver you can use a "full" mask
of 0xffffffff to ensure maximum performance in all events. If
you don't know what your device driver supports, carefully test
the different mask variants and use the "biggest" on which works.
If you plan to connect your harddisk to other Amigas it might be
a wise move to temporarily set the mask value to 0xfffffc which
ensures that it will boot and work even with the worst old stuff.

--
| Bye!   /// Niels Knoop ///   e-mail:

                                      --

 
 
 

Here we go again: Mask & MaxTransfer settings

Post by Steve Ye » Sun, 03 Nov 1996 04:00:00


Wow! I actually understood that.
I'm not the originator of the request, but thought your info on mask settings
was very comprehensible and well writen.

Thanks for the wisdom.

SYee



> > Please ... once and for all ... tell us all what the F, E, and C will
> > map out or not map out in the mask setting?

> An "F" at the end of the mask allows transfer requests to be passed on
> to the SCSI device driver regardless of the address alignment. This is
> the way it should be with every correctly working device driver.

> However some very ancient SCSI hostadapters have flawed device drivers
> which crash or do nonsense when they are ordered to do a transfer to
> or from an odd memory address.

> This can be fixed by using a mask value which masks out those
> addresses. A mask ending with an "E" prevents uneven byte-aligned
> addresses from being presented to the device, while using a "C"
> also masks out uneven word-aligned addresses.

> Masked out transfer requests are then not forwarded to the device
> driver in one piece, but splitted up, transferred through a "safe"
> buffer and copied to or from the memory address originally requested
> using the CPU.

> This mechanism works by _dimensions_ slower than any possible method
> the device driver itself could implement and use if it was allowed to.
> Its performance can be considered the second-worst case (the only
> worse being a crash). You can test it for yourself with DiskSpeed
> which shows results with long-, word- and byte-aligned buffers.

> See it as an emergency procedure of the OS which hopefully seldom
> has to take action at all. Misaligned transfers should generally
> not happen with any well-programmed application anyhow.

> So if you have a decent device driver you can use a "full" mask
> of 0xffffffff to ensure maximum performance in all events. If
> you don't know what your device driver supports, carefully test
> the different mask variants and use the "biggest" on which works.
> If you plan to connect your harddisk to other Amigas it might be
> a wise move to temporarily set the mask value to 0xfffffc which
> ensures that it will boot and work even with the worst old stuff.

> --
> | Bye!   /// Niels Knoop ///   e-mail:

>                                       --

 
 
 

1. Mask & Maxtransfer settings for 4000?

I know this has been asked before but since I didn't have my 40000 then I    
didn't save the information.  

On my new A4000 with a Seagate ST3391A and a Western Digital AC2540H (both
IDE drives), the read/write performance is disappointing.  Diskspeed 4.0
shows a max of about 280K per second on the Seagate with most tests falling
well below that (in some cases less than 100K per second).  Performance on the
Western Digital drive is about the same.  On my Golden Gate 486SLC board the
WD drive could easily zip along at 1.3M per second.  Currently both drives
are formatted with Fast-File System, directory caching on, buffers = 100,
Mask = oXfffffe and MaxTransfer = oXffffff.  It it matters, the 4000 has a
WarpEngine 40MHz 68040, 2M of chip and 16M of fast.

As I understand it, the Mask setting is the range of memory that is used to
transfer to and from the hard drive.  A setting of oXfffffe equals 16,777,214.
Is this bits or bytes?  If it is bytes then it means only chip memory
(0 through 2,097,151 bytes) is being used, correct?

The MaxTransfer should be the largest data chunk that can be transfered
during one operation, right?  Again is this in bits or bytes?  If bytes then
my system should be able to move 2 meg files segments with ease.

If the Mask and MaxTransfer are expressed in bytes then all I should have to
do is bump the Mask setting up something like oX11fffff to allow all of the
memory to be used instead of only chip ram, right?

Can one of the net gurus correct or confirm my reasoning or at least suggest
some settings that will allow these drives to perform closer to their
potential speed?  

Thanks in advance.


2. Palm m130

3. A4000 IDE MaxTransfer and Mask settings?

4. I don't want splitted Windows !

5. MaxTransfer & Mask

6. What a Wasste of Time

7. FAQ? maxtransfer & mask for Hard disk

8. cannot remote onto machine after remoting to it

9. A590 Maxtransfer & Mask, Question

10. Mask and MaxTransfer

11. Removable SCSI Disks and Universal Mask/MaxTransfer Problems?

12. MaxTransfer and Mask

13. Ancora su MaxTransfer e Mask