ZuluSCSI Performance tips & fun stuff

[StompinSteve]

Hello everybody,

For anyone looking for performance tips on using the ZuluSCSI, I wrote an article on the ZuluSCSI GitHub Homepage: https://github.com/ZuluSCSI/ZuluSCSI...iscussions/133
I also wrote an article with fun stuff you can do with a ZuluSCSI: https://github.com/ZuluSCSI/ZuluSCSI...iscussions/134

Cheers and take care,
Steve

[jbenam]

Hi Steve, very nice findings you got there.

I just wish that someone will come up with a real solution for HD sounds - something using samples like WinUAE. Relays are only part of the equation

These new fancy SCSI solutions could easily expose motor signal outputs on an header - a smallish ARM board with a speaker could handle the rest.

[StompinSteve]

Well I have to say that the Beleth's Drum does a pretty good job. It sounds pretty darn good. What is missing is the sound of the spinning of the platters. The "whining" so to speak. But later SCSI-2 drives where almost silent in this respect anyway, often drowned out by the system's fan(s).

It is easy to influence the sound of the Beleth's Drum. If you suspend it, hanging it by a piece of string so that nothing of the unit comes in contact with the computer's case, it sound quiet, timid, in the background.

If you suspend it via a metal wire that is in contact with the case, it sounds a bit louder. Kinda like a really early harddisk.
If you want to go really old school, you can stick it to the case with double-sided tape. It will then use the case as an echo-chamber. It becomes really loud and metal-isch "toink toink" like, and not a soft "bleepy di bleep bleep" like when it's fully suspended.
It all depends on how much contact the Drum has with metal or plastic parts.

I like the adjustability of the Beleth's Drum. And as it's hardware, no need to use a software solution. No need to turn up the volume. The sound is always there.

[thebajaguy]

Tinkering with a new v1.1 ZuluSCSI, and a P5 A2060 with SCSI interface, MuLibs loaded, FastROM enabled. This 53C710 Fast SCSI interface is considered one of the fastest in the Amiga land (of the 8-bit SE SCSI range of interfaces). I'm pulling 2 different speeds with SCSI ID 1 and SCSI ID2:

1GB ID1 = 3657 KB/sec - RDB has Sync Flag Enabled.
2GB ID2 = 4096 KB/sec - RDB does not have Sync Flag enabled.

Enabling the Sync SCSI in the RDB of ID2 lowered it to the slower speed of ID1. Disabling the Sync SCSI flag on both brought them both even to the faster speed.

I know this accelerator card will enable Fast protocol by default (most 53C710 drivers/interfaces successfully negotiate Fast if the device supports it) so that accounts for the reasonable speeds seen above 2.5MB/sec. The drop with Sync enabled indicates something might not be optimal.

I have an 8GB Dell SD card in the ZuluSCSI that is used in relatively modern servers for OS booting (VMWare is popular). It is new, and I consider it industrial-grade media. I made sure the latest ZuluSCSI firmware (December 2022) was on it. I used Dummy File Creator - a useful tool (free/Windows) if you need to make a blank file of some large and exact size.

Ref: Using my RSCP_020 tool which ignores partitioning, and does SCSI_Direct reads with CPU benchmark. CPU is ~99% free on both.

I'm going to give things a run in the near future on the TekMagic A2060 card's SCSI, which is a faster 68060 clocking and same 53C710 SCSI interface.

The speeds you see on your interface on the link, which is >5.0MB/sec, indicate it's negotiating both Sync and Fast. It's nice to see another flash-based SCSI interface/device offer these higher speeds.

[StompinSteve]

Originally Posted by thebajaguy

MuLibs loaded, FastROM enabled

I get the best performance with "MuFastZero On MoveSSP=FastSSP FastExec) which moves the Exec and Expansion libraries to FAST RAM. Gives a real boost, especially on real-life Filesystem Ops (who cares about raw-reads anyway).
Of course this also requires MuMove4K but I need that anyway for ShapeShifter.

Using the disk benchmark in SysSpeed 2.6, the biggest boost is with "Seek/Read" which jumps from 1500-ish Ops/Sec (with just MoveSSP=FastSSP, no FastExec) to 4300-ish (4356 during the last run, see below) with FastExec enabled. Listing long directories in DOpus for example, is noticeably quicker with Exec in FastRAM. No surprises there.

So fully-tuned, my A1200 now shows these results in SysSpeed:
Create - 140 Ops/Sec
Open - 474 Ops/Sec
DirScan - 1228 Ops/Sec
Delete - 1075 Ops/Sec
Seek/Read - 4356 Ops/Sec
CreateFile - 3.90 MB/s
WriteFile - 3.95 MB/s
ReadFile - 4.67 MB/s
RawRead - 5.58 MB/s

[patrik]

Originally Posted by StompinSteve

I get the best performance with "MuFastZero On MoveSSP=FastSSP FastExec) which moves the Exec and Expansion libraries to FAST RAM. Gives a real boost, especially on real-life Filesystem Ops (who cares about raw-reads anyway).
Of course this also requires MuMove4K but I need that anyway for ShapeShifter.

The Blizzard1230/1240/1260 are notorious for not adding their memory using normal autoconfig, so its fastmem is available too late so the library base for exec.library and the system stack is allocated from chipmem. As you noticed this causes a quite big performance hit as this is the most heavily used library base of the system.

Not sure if thebajaguy's Blizzard2060 has this feature too?

I have a WIP project for finding out things like that slowing down the system.
Some docs and examples: https://github.com/patrikaxelsson/ResidentSpeed
Binary: http://megaburken.net/~patrik/pt/ResidentSpeed

[thebajaguy]

I'm quite familiar with cards that add RAM via the ROM on an AutoConfig card. When a card adds their RAM after the OS structures get built, that certainly calls for MuFastZero remap (via MMU) of the lower ChipRAM vectors and related structures. That's not the case here.

The memory >16MB address on the P5 is loaded into the memory list very early by it's onboard $F00000 ROM (if can run on 3.1 because of that) before expansion.library processes cards, so all of the OS ends up in the high speed memory. I checked where everything is getting located with xoper. I'd see it down low in ChipRAM address range if it did not.

The P5 2060 card isn't mine. It belongs to a client. Edit: The full MuLibs package added the MuFastZero call in the User-Startup, so it was active for this card.

The numbers from RSCP and it's 3 buffer sizes (16K, 128K and 512K) are normally comparable to the other speed tools, and between 16K-128K is really what many Amiga loads and saves end up doing. On flash media, latency is nil.

RSCP merely takes an honest look at how I/O affects CPU access to system memory, or does the I/O take up all the CPU's free time to get those values. With little/no CPU free, it can't process as many filesystem duties while data is also trying to be transferred.

On the cards that have the 53C710 moving data, CPU performance concurrent with I/O is excellent .

I just need to drop the TekMagic card at some point in and see what it does. I've seen up past 7MB/sec on that with a capable target. It has the same memory-add very early on it's $F00000 ROM, and the 53C710.

Edit: located the TekMagic 2060/66MHz w/64MB and used it's 68060.library v2.3 and integrated FastROM combo (Ralph Babel's design) vs MuLibs, and I pull 4.338MB/sec on 512K (99% CPU), 3.792K with 128K (98% CPU), and 1030K on 16K (97.5% CPU) off the ZuluSCSI. I'm not complaining, really. Beats the Async SCSI era easily. I boot OS 3.2 in less than 10 seconds from the blip of the SCSI floppy/HD taking off to workbench, and that includes enabling the AmigaNet/Roadshow stack.