Blizzard PPC scsi transfer speeds

[Boot_WB]

Hello,

I have BPPC/040/240 with scsi, and have been tweaking the settings to try to get the max transfer rate I can out of my Seagate 8.4GB UW hard drives (ST39173LC).  They're capable of differential 16-bit trnsfers, but have jumper set to force single ended, and automatically fall back to 8-bit transfer modes.
Termination is correct - I have created a 68-50 pin cable adapter for the blizzard ppc, so that a 68-pin cable attaches to the 50 pin HD connector on the PPC as shown here:

1  BPPCscsi provides low-byte termination
2  first position has a 68-50 pin adapter providing high-byte termination.
3  Next 2 positions have the 2 68-pin drives (set to single-ended mode)
4  Last position has a 68-pin active terminator on the end of the chain.

Thus both high-bytes are terminated around the hard drives (to keep them happy) and low-bytes are terminated at the Blizzard and at the end of the chain.  
I get no scsi errors, lockups, etc.

SCSIspeed reports that with 256Kb buffer, in Sync mode with 3-handshake bits I get ~8MB/s transfer speeds.  Not quite 10MB/s, but I am happy with that.

When I actually transfer a single large file (say 30MB) I get:

Hard-drive to memory = ~2MB/s
Memory to Hard-drive = ~1.8MB/s
Partition - Partition = ~1.8MB/s

I am currently using SFS, however the results were about the same with PFS3.

Mask        = 0xFFFFFFFF
MaxT        = 0x7FFFFFFF
Block size  = 1024
Buffers     = 256

(Buffer size = (Buffers * Block size) = 256Kb

Also, my TEAC scsi CD/rw doesn't perform as well as I'd expect - transfer speeds according to SCSIspeed are - at best - around 2.2MB/s.  The drive is capable of 32X speeds (around 4.8MB/s) - what gives?  I'm using CacheCDFS, since the Blizzard CD munting tool doesn't seem to support multi-volume drives.

All help/advice appreciated.

[Framiga]

use 512 Block Size for SFS (always)

Rise the dosbuffers to at least 400 (more if it is a large partition).

Then use SFSCache to tuneup the read-ahead cache size i.e (if you have some MEM)

SetCache PARTITION_NAME: 32 32768

in User-Startup (as PARTITION_NAME: the partition device name)

:-)

Edited the wrong SFSChache line.

SetCache PARTITION_NAME: 32 32768

[Boot_WB]

Thanks Framiga, I'll give that a try.

[EDIT] - forgot to mention, the drive is split into 4 * 2.1GB partitions.

[patrik]

Wierd, it sounds just like your Mask would be the stock "Zorro2 compatible" 0xFFFFFF and thus forcing your system to shove the data through chipram and using the cpu to copy it to/from chipram to the correct location.

Not that this should make any difference, but try setting those values to the defaults for a 32-bit system - Mask=0x7FFFFFFF and MaxTransfer=0xFFFFFF. Do this for each one of your partitions.


/Patrik

[Framiga]

but his Mask its already "almost" correct. Its the MaxTranfer thats wrong... or not?

f.e. i have:

Mask=0xFFFFFFFC (for SCSI and IDE)

MaxTransfer= 0x00FFFFFF (for SCSI) cybppc.device

MaxTransfer= 0x0001FE00 (for IDE) A4000 internal

AFAIK i could use even 0x7FFFFFFC as Mask.... what do you think Patrik?

[Boot_WB]

I took the settings from the SFS.guide

SFS.guide:
Devices which can access data located anywhere in memory (a SCSI
controller which is embedded on an accelerator card, or a Zorro-III
IDE or SCSI controller) should have a mask of 0xFFFFFFFF.
....
In any case, if you have a SCSI drive, then a MaxTransfer value of
0x7FFFFFFF should be just fine.  For IDE drives, you probably need to
set it to 0x1FFFE or to 0xFFFE.  Those values represent 128 kB minus 2
bytes and 64 kB minus 2 bytes respectively.

Is this incorrect?

[patrik]

@Boot_WB:

No it is not wrong, but you have a wierd issue which doesn't seem logical at all and  then it is often good to also try settings that should not matter. So, try setting the MaxTransfer=0xFFFFFF (six F).

@Framiga:

You should only clear the least significant Mask bits if the controller cant write/read data to/from say 16-bit aligned or 8-bit aligned addresses. So if you set the mask 0xFFFFFFFC, then it will only be able to read/write data to/from 32-bit aligned addresses and if it is fed a buffer on say a 8-bit boundary, it will transfer the data through chipmem and between chipmem and fastmem using the cpu, which will be very slow.

Neither the BPPC or CSPPC controller has any such limitations and should have the mask set to 0x7FFFFFFF or 0xFFFFFFFF.

Compare the results for the WORD and BYTE-aligned parts of these tests:
Mask 0xFFFFFFFC
Mask 0xFFFFFFFE
Mask 0xFFFFFFFF


/Patrik

[Framiga]

perfect Patrik... thanks a lot for the clarification :-)

[Boot_WB]

This is weird.  I've just done the following tests on my system using a test file (Joe_Dirt.avi) from the OS3.9 disk of around 38MB:

Using mask 0x7fffffff
MaxT 0x00ffffff
Filesystem: SFS
Blocksize: 512 bytes
Buffers: 512
System ram: 194MB fast (60ns), 2MB chip

Partition - Partition (Same drive) = 24 seconds
Partition - RAM: = 27 seconds
Partition - Partition (between two drives) = 25 seconds
RAM - Partition = 16 seconds
RAM: - RAM: (copy between directories) = 21 seconds

I'm starting to wonder if there is some issue with having both the mediator and the bvision installed when running the system through the BVision.  When I get the motivation and time I'll try it with the mediator removed.

[alewis]

@Boot_WB

Interesting hack on the cable, personally I prefer to use 50-68 adapters. Can you confirm the drive is an LC model, as LC is seagate's terminology for an 80pin SCA interfaced drive.

I'm sure the problem is OS related, but from own experience:

Having a good few of these drives meself (and the W variant) a few years ago, I was getting less-than-satisfactory results. I changed the PD jumper (which had been set to do parity checking). YMMY.

Also, try changing the SE mode jumper. LVD drives should fall back to SE operation without the jumper set, and this *may* lead to performance boosts. OTOH, you of course may have it set because they didn't! Just gotta love the black art of SCSI.

If you have a couple of adaptors, it might be worth using a native 50way cable, and 50/68 adaptors to attach the drives. IIRC you should have a narrow (native 50pin) SCSI device as the last device in the chain, and use an active terminator at the end of the chain (sorry, can't see original post to remind myself of setup).

sorry about the egg suck, but I always find it useful to check from the wire up, even when I *know* it isn't an issue...

Um, reaching back into the dim distant past when I last used a Miggy in anger... the disk buffers are in fastmem, aren't they?

[Boot_WB]

Hi Alewis,

Thanks for the info.  I'll try removing the SE jumper, see if it makes a difference.  I'll also try setting (or removing, can't remember atm) the parity check jumper.

Good drives ain't they? :-) Someone was ebaying a bulk lot at £2 a piece recently, I got 10 - most of which now populate my PC and my Amiga, although I'm limited by the lack of available Molex connectors.

btw - you're right, the drives are 80-pin SCA, I didn't bother to mention it because they're the same logic as 68-pin versions, it's just the scsi ID, power, and options are set by the cable adapter attached to each drive using an 80-68pin SCA-SCSI adapter, as I have no rack to mount them in.  

If I had sufficient adapters, and an appropriate multi-headed 50-pin HD cable I'd try your suggestion, it was lack of the cable which prompted me to do the rather enlightening research to create the 50-68 pin hack in the first place, as the pitch of the 68-pin cable is the same as the 50-pin HD connector.

It never hurts to check (especially with SCSI) from the wires up, I have no hurt pride, but I really think it is filesystem/settings related rather than hardware - mainly due to the ~8MB transfer speeds I get on scsispeed checks, but also since the speed limitation is affecting my CDRW also, at approximately the same ceiling.

The slow file copying between directories of the RAM disk also suggests to me that something is wrong.  I need to find that memory speed checking program I used to have which showed 68k and PPC memory speeds.  Wish I could remember what it was called....

[alewis]

£2 a pop! I remember the first UW drives I got - 9.1gb Barracudas at £700 a pop. I *knew* I should have sold them on then!  Still use them in a Netware box, and tend to use U160 versions as server boot drives.

Anyway> Maplins are reasonable for Molex connectors, although a local PC shop would be cheaper. The SCA adapter is always a suspicion. Going off topic slightly, the "cheap" ones found on ebay are crap. Literally. I buy mine from SCSI-4-ME in the US

SCSI-4-ME SCA-68 pin adaptor info

They are very, very, very good. Ok, only of use in a u160/320 chain, but I even had problems in an older UW chain using cheap adapters. The first two are common as crap on ebay, and over in 2cpu storage forum are the major source of "scsi newbie" issues.

But yeah, it does seem to be an OS/memory issue. 8mb on the bus is about right for SCSI-2 (though, that 2mb overhead is a little high, imho. Maybe the chipset logic).

I take interest in this as I have an A4K, and one day will get round to making it work again; it was fine with the WarpEngine (and the onboard SCSI seemed fine), then I bought a Cybestorm PPC - about 18months ago! - and have yet to fit it. I really, really, really want to see how ultra-wide SCSI on the Mig performs!

[Framiga]

@Boot_WB

just done some test.

In real life transfer rates, the speed is much slower compared by the one reported by "some" benchmarks tools.

The only unusual setting i've seen in your post, seems to be the 3 Bytes Handshake.

Reset it to 8 and try again (if i set mine to 3, i have less than half speed....although we are on different card/controller/HDs it could make some differences). About the SE thing, you have to force it in SE anyway.

[Piru]

@Boot_WB

I get ~8MB/s transfer speeds. Not quite 10MB/s, but I am happy with that.

This is what I got aswell, with true SCSI-II devices.

When I got my SCSIDE I was happy to find out I could get ~9.6MB/s.