Best settings for Blizzard 1260 with MKIV SCSI

[Leon Besson]

Hello,

I currently own a Phase 5 Blizzard 1260 with MKIV SCSI card.
Currently the cards have max RAM 128MB x 2 (256MB RAM). Attached to the SCSI side I have a V6 Scsi2SD drive with 64GB SD card with PFS 3 19.2 setup.

From a post on here about checksum errors with a SSCSI V6. It appears I may have too little max transfer setup. As every thread I’ve read about scsi.device and IDE max transfer should be 0x1fe00.

I’ve been notified by a long time member on here that it’s too little for SCSI?

So am I right that I should be using Mask 07FFFFFFE Max transfer FFFFFFFF

[Jope]

Have you had any errors in your transfers? If not, don't change anything.

[thomas]

Maxtransfer cannot be too small, only too large. Well, if you set it to 1, then it's too small. But any whole number of sectors will do, even one sector.

The smaller the MaxTransfer value, the more overhead is created. But as an SD card on the SCSI2SD seems to use a ATA command set and thus cannot transfer more than 128 K in one go anyway, setting MaxTransfer to 128 K does not harm.

If you set MaxTransfer too big, you get file corruption. What is too big depends on the driver and the underlying hardware. If the driver is coded corretly it should hide any hardware limitations and allow MaxTransfer to be set to the highest value. Only if the driver is coded badly or if, like in case of the SCSI2SD, it cannot know the limits, you have to set MaxTransfer accordingly.

Mask is a different thing. Mask is used to check which memory is able to do DMA. It depends on the controller hardware used. Check the controller's manual, it should say which Mask value should be used for your controller.

[Jope]

Well, here it is from the SCSIConfig3 docs for people coming in via google. Should apply to (z3|cyb|2060|1230)scsi.device.

*** Mask

This value indicates which area of the memory of the controller can be
directly accessed. As the controller can directly access the complete
address area of the processor and a transmission should always be delivered
in longword limits, the value pre-set by SCSIConfig of "0xFFFFFFFC" should
not be changed as this will cause a significant decrease of the data
transfer speed.

*** MaxTransfer

This value limits the maximum amount of data which can be transmitted. The
default value of "0xFFFFFF" should not be changed.

If RDB formatted hard disks are to be used that were used by other AMIGA
controllers, it is very likely that the Mask value will not be set
correctly for optimal Zorro-III operation (in general, it would have been
set at "0xFFFFFE"), which causes considerable data loss. In this case, the
MASK value for the existing partitions must be changed to the "0xFFFFFFFC"
stated above. Check that ONLY the Mask and MaxTransfer values are changed
as changes to other partition details can cause data to be lost on the
partition.

[Leon Besson]

So it’s a horses for courses setting then? ????

The default I’m using 0xfe00 isn’t causing any errors. Although when I was using 18.5 I was getting a lot of bit errors. Now I’ve upgraded to 19.2 fingers crossed all is well.

Looks like it’s time to experiment.

Thanks for the guidance Jope and Thomas.

Maybe the sticky note at the top of this needs amending perhaps?

[Jope]

Could you link to the message you mean please? You can get the direct message link from the top right corner where there is a # and a number.

The horses here are your hard disks and the courses here are the controllers/computers they're connected to. MaxTransfer 0x1fe00 will probably not break anything and in reality there is not much speed penalty either. Going over 0xFFFFFF might be a problem for the Phase 5 controllers, but they don't explain why you shouldn't go higher. The mask is quite relevant when you have a DMA storage controller, as Thomas said, you ought to select the correct one every time.

[Leon Besson]

Yeh this sticky;

http://eab.abime.net/showthread.php?t=45491

I know it mentions IDE and !ax transfers. Maybe a new sticky for SCSI?

Just a thought.

Just tried those settings on my test 1200 TX 1260 tower and low and behold it’s broken some of the SCSI connectivity to other devices ??????
Not sure if this is because I’m also using a Mediator 1200 TX. Will revert back to see if it fixes the issue.

[Jope]

The IDE thread is there because there is a destructive non-obvious data corruption problem with most versions of the IDE scsi.device and the default MaxTransfer value.

Thanks for the suggestion, but I don't think it's worth another thread, the amount of SCSI controllers with problems like the IDE maxtransfer issue is not very high.

[alexh]

If you are using solid storage (e.g. SCSI2SD) then larger max transfers possibly have no effect other than reduce command overhead (which will be a fraction of the total transfer time).

But back in the day with spinning magnetic media, especially older SCSI disks which didn't have large caches (any caches?) using a bigger max transfer would significantly reduce read latency and improve performance.

I expect it eliminated the seek times.

[patrik]

I think the p5 docs posted above are extremely vague - just a value which was valid for one of their controller for a specific driver version and no explanation of how it works.

I am running mine with mask 0xffffffff and max transfer 0xffffff. Mask with a C at the end will not allow the driver to do transfers to from word and byte aligned addresses and this is disregarding if DMA is used or not.

Mask is just a kludge to get around bad driver+he combo limitations. You can test yourself what works with your controller by setting mask to 0xffffffff (no limit/kludge) and test a partition you don’t care about using diskspeed - it will do byte/word/longword aligned read/writes.

[Jope]

This thread is P5 specific in my eyes. :-) Other controllers will have other recommended settings.

The PFS3 manual has a reasonable explanation.

The DMAMask indicates which memory areas the device can access with DMA. High
speed devices like disk controllers can read and write data from memory
without any CPU load. This is called Dynamic Memory Access or DMA.
Unfortunately some devices can only access part of the memory. Any ZorroII
board, for instance, can only access the lower 16MB of memory. The
corresponding value for Mask is 0xfffffc. ZorroIII boards can access all
memory, so for those 0xfffffffc should be used. Double check what kind of
board is used, since if the Mask is set wrong it can result in serious
problems with the disk.

The mask is also used to control the alignment of any buffers used to access
the device. Alignment to longword is recommended. Some controllers will work
without alignment, but even those will perform a lot better with aligned
memory. Longword alignment is selected by ending the mask with a 'c'.

For most boards the best Mask settings are:
Zorro II board: use 0xfffffc.
Zorro III board: use 0xfffffffc.


If you don't have memory problems you should use the same mask as FFS/PFS2
did. The mask is filesystem independent.

For the A1200/A4000 internal IDE controller use 0xfffffffc
For ZorroIII boards (Fastlane, Phase5, 4091) use 0xffffffff
For ZorroII boards and Oktagon 4008 use 0x7ffffffc


If you experience problems with the Mask, you can try other values.

It omits the word alignment setting which would have the mask end in e.

[patrik]

There are many strange things in that documentation too.

1. The Mask value is not tied to DMA and is surely not called “DMAMask”. The Mask value is used by the filesystem to decide if a transfer to/from an address in memory should be sent as is to the .device driver. If the address does not match the mask, the filesystem will attempt to do something “safe” which is totally up to the filesystem. FFS for example splits up the transfer in very small parts and transfers via chipmem, copying to/from the intended address using the cpu - very very slow!

With Mask not being tied to DMA, I mean that the filesystem has no idea if the underlaying .device driver intends or even can do a DMA transfer, but will apply this “safe” and generally very slow scheme disregarding if it is a p5 DMA controller or the A1200 PIO IDE controller.

2. The buffer address will in general be the buffer an application has allocated from the highest priority memory and sent to dos.library/Read() or dos.library/Write(). The application will also in general not know the mask of the underlaying filesystem as it is not practical to find out, so the filesystem will just get whatever in the common case and the Mask value will not magically aid the applications with memory allocations.

Setting the mask to something reatrictive (say C at end) when not needed will not improve performance, only make it worse for those cases applications send of an unaligned Read() or Write(), forcing the filesystem to do the transfer in a “safe” manner.

With all this said, memory allocations are aligned to at least C (32-bit) by exec, so most Read()/Write() will not suffer from such unnecessary restrictive Mask, but still there is no point in such restrictive Mask to begin with unless your driver+hw is known buggy.

2. For filesystem internal buffers, I assume that they are aligned well disregarding mask, because it would make no sense to align them on say byte aignment if mask ends with F, as that would never be a performant thing to do .

[patrik]

Using an A1200 with B1260 + B1230-scsi-IV + old IBM DPSS-309170N 9GB drive to show F vs C Mask difference with FFS here.

Mask=0xFFFFFFFC FFS partition:

9.Ram Disk:> version FULL 1230scsi.device 
1230scsi.device 8.5
9.Ram Disk:> changebootpri 1230scsi-FFS-C: 
IDH8:
  Not Bootable
  AutoMount
  BootPri     = 0
  DosType     = 0x444F5303
  Mask        = 0xFFFFFFFC
  MaxTransfer = 0xFFFFFF
9.Ram Disk:> diskspeed DRIVE=1230scsi-FFS-C: FAST LONG WORD BYTE BUF1=262144 BUF2=0 BUF3=0 BUF4=0 
MKSoft DiskSpeed 4.2  Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68040  AmigaOS Version: 47.102  Normal Video DMA
Device:  1230scsi-FFS-C:    Buffers: 30

CPU Speed Rating: 9731


Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file:      6422528 bytes/sec  |  CPU Available: 57%
Write to file:    9338880 bytes/sec  |  CPU Available: 73%
Read from file:   7208960 bytes/sec  |  CPU Available: 76%

Testing with a 262144 byte, MEMF_FAST, WORD-aligned buffer.
Create file:       614147 bytes/sec  |  CPU Available: 13%
Write to file:      63388 bytes/sec  |  CPU Available: 65%
Read from file:    520385 bytes/sec  |  CPU Available: 14%

Testing with a 262144 byte, MEMF_FAST, BYTE-aligned buffer.
Create file:       603725 bytes/sec  |  CPU Available: 13%
Write to file:      62826 bytes/sec  |  CPU Available: 65%
Read from file:    522329 bytes/sec  |  CPU Available: 13%

Average CPU Available: 43%  |  CPU Availability index: 4184
9.Ram Disk:>

Mask=0xFFFFFFFF FFS partition:

9.Ram Disk:> version FULL 1230scsi.device 
1230scsi.device 8.5
9.Ram Disk:> changebootpri 1230scsi-FFS-F: 
IDH7:
  Not Bootable
  AutoMount
  BootPri     = 0
  DosType     = 0x444F5303
  Mask        = 0xFFFFFFFF
  MaxTransfer = 0xFFFFFF
9.Ram Disk:> diskspeed DRIVE=1230scsi-FFS-F: FAST LONG WORD BYTE BUF1=262144 BUF2=0 BUF3=0 BUF4=0 
MKSoft DiskSpeed 4.2  Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68040  AmigaOS Version: 47.102  Normal Video DMA
Device:  1230scsi-FFS-F:    Buffers: 30

CPU Speed Rating: 9988


Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file:      6389760 bytes/sec  |  CPU Available: 56%
Write to file:    9338880 bytes/sec  |  CPU Available: 71%
Read from file:   7897088 bytes/sec  |  CPU Available: 74%

Testing with a 262144 byte, MEMF_FAST, WORD-aligned buffer.
Create file:      6422528 bytes/sec  |  CPU Available: 57%
Write to file:    9371648 bytes/sec  |  CPU Available: 71%
Read from file:   7929856 bytes/sec  |  CPU Available: 74%

Testing with a 262144 byte, MEMF_FAST, BYTE-aligned buffer.
Create file:      6389760 bytes/sec  |  CPU Available: 57%
Write to file:    9371648 bytes/sec  |  CPU Available: 71%
Read from file:   7897088 bytes/sec  |  CPU Available: 71%

Average CPU Available: 67%  |  CPU Availability index: 6692

[Leon Besson]

So this interesting. Tried changing mask settings and max transfer as above.
So on my test tower setup I’m booting from a Seagate 2GB SCSI-II drive with the 1260 and SCSI kit.

On standard 1fe00 max transfer I was getting around >5MB/sec. I the. Introduced “my unit control” into the startup sequence with P=10 and drive is using Synchron setting via RGB. This put it up to >6MB /sec. Now with also changing the Max Transfer to 0x00FFFFFF I now get >7MB/sec. But changing the max transfer also causes issues with my Nakamichi 16x Speed SCSI CD changer as that then stops being seen. Which has a knock effect with my Mediator and RTG ( Nakamichi on ID5 last device and Terminated and auto starts via mount on DOSDrivers).

Will carry on playing around with it.

[patrik]

I also use unitcontrol to set the SCSI bus to 10MHz synchronous.

In the CD0 dosdriver shipped with 3.2.1, it has 0x100000 as default MaxTransfer at least (if you edit the file).

Some questions:
- Which version of 1230scsi.device do you have?
- It is not the 10MHz synchronous speed causing issue with the CD changer?
- What happens with the mediator?
- What are you testing the speed with?
- Is the termination working properly? Sry, but it is a super common, especially if the termination requires that termination power is supplied from the SCSI bus and nothing on the bus is supplying any for whatever reason - can for example even be burnt-out protection diode. It will sortof work anyway as the B1230-scsi-IV has a built-in terminator sourcing termination power from itself, but not be reliable synchronous mode. Does the CD changer specify how it sources termination power?

[Leon Besson]

1230scsi.device = 8.5

Only using 10Mb Synchro on Units 0,4 and 2. 0 = HDD 4 = Jaz Drive 2 = SCSI Multi card Reader

Mediator loses RTG function but maybe tied to Intuition error due to not finding and mounting Multi-CD drive

Using Sysinfo 4.4 for testing speed with

Termination looks to be fine but I am counting on the CD drive termination which normally works fine until I attempt any of the Mask and Max Transfer changes.

[alexh]

CD drives have a different block size to HDDs I don't know if that is significant?

[Leon Besson]

I also have a Yamaha CD-RW drive on ID 3 which is seen

So complete setup I’m testing this on;

Rev 1D1 board recapped with polymer caps
KS 3.1.4
Mediator 1200TX 2016 version
Phase 5 Blizzard 1260 with rev 5 68060
Phase 5 SCSI Kit add-on MKIV with 8.5 SCSI ROM
2GB Seagate Mechanical Hard Drive on ID 0
Iomega Jaz 2GB drive ID 4
SMC Multi-Card Reader/Writer ID 2
Yamaha 6/10/16 CD-rewriter Drive ID 3
Nagamichi 5 CD Reader ID 5 (Terminated)

OS 3.9 with BB 1-2 + 2018 released BB 3+4

So 3.1.4 workbench.library

[patrik]

If one CD drive has issues with maxtransfer, do not change it for that one.

[Leon Besson]

Originally Posted by patrik

If one CD drive has issues with maxtransfer, do not change it for that one.

I’m not changing any of the transfers for the CDs though.

I’m using HDToolBox to only change the values on the HDD partitions. So not sure how this effects the CD drive?