GVP Impact Series II HD8+ much slower with TerribleFire 536

[StompinSteve]

Hello everybody,

I just upgraded my mostly stock A500 Plus (with 2MB Chip Mod and KickStart ROM 3.1) and GVP Impact Series II HD8+ (with a ScsiZulu RP2040 inside) with a TerribleFire 536 and the SCSI HDD performance has dropped significantly.

Before buying the TF536, i read up on any potential (DMA) compatibility issues and I could not really find anything conclusive. There are issues with this TF and other SCSI solutions which are well documented but this GVP seemed ok. So i gave it a go and bought the TF536. It has 64MB RAM onboard.

The combination works. The system boots normally, is super stable and basically all good. But... the HDD (ZuluSCSI) performance with the original 68000 CPU was a little over 1 MB/s. Now with the TF563, it dropps to 630 KB/s
After fine-tuning with MMUlibs to get the MMU enabled etc., I got the HDD speed up to a whopping 714 KB/s

Despite everything working error-free, and people saying that GVP's are not impacted (pun intended) by the often reported compatibility issues with the TF536 (and TF534), this might still be a DMA issue i guess?

The GVP Manual says the Mask should be 0xFFFFFE (not a typo) but that is of course with it's own 8MB Onboard Fast-RAM. I have this RAM disabled now. No point having slower "old" Fast-RAM besides the 64MB RAM on the TF536.

I tried changing the MASK in HDtoolbox from 0x7FFFFFFF (This is what the GVP came with when I got it) to 0xFFFFFE (as per GVP Manual) but it does not help to speed-up the HDD (SD Card in ZuluSCSI) at all. No effect. Same lousy 718 KB/s.

The MaxTransfer is still set to 0x1fe00 (the previous owner of the drive did that and I never changed it).

To be honest, despite reading up, I don't know what i'm doing when changing the mask. I understand what it is for, but not what a correct value would be on a system with 2MB Chip and 64MB RAM on the TF.

I'm hell-bent to stick with SCSI. I love the look of the GVP Impact II sitting besides the A500. All my Amigas are pure SCSI because that's just me. I'm a SCSI nut and cannot be healed. I'm also not going the route of PiStorms etc. I'm just not interested as for me, that is not "Commodore Amiga" anymore. So please refrain from making comments like "use the TF's IDE". Not gonna happen.
(I use a 44-pin terminator on the my A1200's Motherboard and on this A500's TF536 to solve the boot-delay problem when there is no IDE HDD 7 CF-Card attached).

[pipper]

I think it all boils down to the SCSI controller not being able to DMA into TF‘s memory (the TF was never intended to do that). Instead, now the card runs in „PIO“ mode and each byte is shoveled into fastmem by the CPU, defeating the purpose of SCSI…
I have a similar problem with the A590 Being very Slow. There is no known workaround except MAYBE using the mythical Guru ROMs on the A590. These are allegedly aware of the DMA capable onboard memory and will automatically redirect reads to memory that the controller can DMA into. Are Guru ROMs available for your SCSI controller maybe?

[patrik]

As already said, DMA over Zorro2 cannot reach memory above first 16MB, so there will never be any DMA to/from TF memory.

Mask is just a kludge/workaround option to be able to get bad hardware and drivers to work. It should not be “matched” to the memory configuration of your machine in any way unless it is broken and crashing or corrupting data in some way.

At least with the recent gvpacsi.device available at babel.org, the device is aware of the Zorro2 limitations and does not need the Mask kludge to not crash the computer. In fact, with the Mask kludge, you will force the filesystem to do “safe” transfers, which is whatever it deems safe. For example FFS will generally showe the data through chipmem, at very small blocks, making it super slow.

With a recent enough gvpscsi.device it would be more efficient to set mask to default 0x7FFFFFFE and let the driver handle the copying instead of the filesystem doing a safe thing.

The difference of this can only be seen in a test program which tests the speed with the filesystem. Only good test I know which does this is diskspeed. SysInfo, RSCP etc only do direct device reads so the mask setting will not be used and even they used it, it will not be running the filesystem code so it is pointless anyway as what matters is the speed you get though the filesystem.

One thing btw. The GVP cards has this funny double-speed memory which the SCSI controller can DMA to/from faster than the CPU can access. It might be so that if you have some memory onboard the GVP card, gvpscsi.device can work more efficiently by doing DMA specifically to/from that memory between the copy with CPU that must be done to/from TF memory. Without onboard GVP memory it could be that it resorts to PIO directly against the SCSI chip registers, which will be very slow, but could explain your 700kB/sec. This is only a theory though. If true, this would affect raw device reads too, so would be seen in SysInfo etc.

So try:
- Mask = 0x7FFFFFFE
- Memory on GVP

Btw, maxtransfer can be the default 0xFFFFFF, it is not a problem. Will only help with large reads/writes, but this is not the A600/A1200/A4000 IDE controller that this 0x1FE00 setting is intended for.

[StompinSteve]

"With a recent enough gvpscsi.device it would be more efficient to set mask to default 0x7FFFFFFE and let the driver handle the copying instead of the filesystem doing a safe thing."

The GVP currently has a 4.13 ROM in it. I ordered a 4.15 ROM-Chip (the last version ever released from what I understand) which is still in the mail. Can the 4.15 be soft-loaded in the meanwhile?
Will try re-enabling the 8MB in the GVP and see what that does.


"Btw, maxtransfer can be the default 0xFFFFFF, it is not a problem. Will only help with large reads/writes, but this is not the A600/A1200/A4000 IDE controller that this 0x1FE00 setting is intended for."

You sure? As it is a SD-Card in a ZuluSCSI and not a real HDD. I thought 0x1FE00 was for SD-Cards etc. because FlashMemory works differently.

Concerning the 64MB on the TF536: can it be disabled? I mean, 2 MB Chip and 8 MB Fast (on the GVP) has always been enough so far. Or would a TF 534, which has 4 MB, have been a better choice to avoid all this? (My reasoning: 2 MB CHIP + 8 MB GVP Fast-RAM + 4 MB on TF534 = 14MB which is less that the 16MB limit).

[fgh]

Turn on the GVP RAM again, it probably gets lower priority than the TF RAM, so it will not slow anything down.

Edit: And yes, maxtransfer bug is an ATA1 vs ATA2 thing, not confirmed on other drivers than (600/1200/4000) scsi.device. It’s not relevant on SCSI.

[alexh]

If you disable the onboard 8MB FAST-RAM you limit the SCSI driver to either "DMA to CHIP RAM" or "PIO", both of which are much slower than DMA to FAST RAM.

Turn the RAM back on. Bingo.

[StompinSteve]

Ok i'll re-enable the 8 MB RAM on the GVP (jumpers). But it does not make sense why it would have an influence, because the HD8+ has RAM from the factory. The HD+ does not. It's the exact same SCSI-Controller device, just without RAM (it could be added of course). But for the sake of argument, i'll turn the RAM back on. I hope you are right.

Side-question: how do I check, and if needed, configure that RAM to have a lower priority that the 64 MB RAM from the TF ?

[Jope]

You can see the ram priorities with sysinfo.

The HD+ without RAM will be just as slow if you don't have fast ram. Back when these controllers were new, the hard disks available were not super fast either. 500kB/s was quite ok performance in many cases.

[StompinSteve]

Ok i've re-enabled the 8MB on the GVP. I had to Disable the MuTools stuff for now, as it causes an endless bootloop with guru's etc.

I changed the Mask to 0x7FFFFFFE and maxtransfer to 0xFFFFFF. No difference whatsoever. Because the MMU and it's optimizations are not used at the moment, the HDD performance is back to a scorching 681 KB/s which is what i've started out with.

@ Jope: the ZuluSCSI in the GVP did a little over 1 MB/s before I installed the TF (with the 68000 and just the 2MB Chip and 8MB Fast on the GVP and the old Mask and MaxTransfer settings).

Sysinfo reports the following memory in the system:
64 MB 32bitRAM Public Kick
Node Name: Expansion Memory
Prio = 20
Start Address: $40000000
End Address: $44000007
First address: $400023D8

8 MB FastRAM Public Kick 24bit DMA
Node Name: Expansion Memory
Prio = 0
Start Address: $00200000
End Address: $009FFFFF
First address: $00204020

2MB CHIP RAM Local Public Kick 24bit DMA
Node Name: chip memory
Prio = -10
Start Address: $00000000
End Address: $001FFFFF
First address: $000005A0

So as a half-noob, I see the word "DMA" twice and think yeeeeeh I got DMA Memory but then eeehm, why is the GVP not able to use it. Can I use the Mask to force the GVP to use the memory area in the 8 MB Fast RAM on the GVP ?

Again the MMUlibs stuff is disabled at the moment so the only thing used so to speak, it the 68030.library from the MMUlib distro (sidenote: which is identical as the same file on the disk that was shipped with the TF)

[hooverphonique]

Interesting end address of the TF ram

[patrik]

The general usage scenario is: An application allocates some memory, it will get the highest priority memory, then it asks the filesystem to read data into it from a file.

In your case the highest prio memory will and should be the fastest memory - your accelerator memory. So this memory is above first 16MB, so disregarding what solution is chosen by hardware+driver+filesystem, the CPU has to be involved as the Zorro2 DMA controller can’t reach it.

Ok, so what if the application could allocate some specific memory that your controller can DMA to. Sure, it could and there are surely some use cases for it and this is what the MEMF_24BITDMA flag you saw is for - helping an app do such an alloc for the few usecases that is appropriate.

In general however, this would be a bad idea - surely, the transfer itself would be carried out with DMA efficiently, but when the CPU then starts doing actual work on that data, it is in super slow Zorro2 ram compared to the accelerator ram and it is now wading in molasses.

It is a generally better idea to let the filesystem+device+hardware just transfer the data for you to the highest prio memory as then the CPU only has to do the slow access of the data once over the Zorro2 bus, not potentially many times if it is working directly against the Zorro2 ram (depends on workload of course).

1MB/sec SCSI speed is very slow for an GVP Impact Series 2. You should reach over 2MB/sec with a good drive: http://megaburken.net/~patrik/amigab...OldUnknown.txt

1MB/sec to Zorro2 ram on the GVP or chipmem and then a copy to accelerator fastmem by the driver assuming top 3.5MB/sec Zorro2 speed would ideally get you the aggregated speed 1/((1/1)+(1/3.5)) ~ 0.78MB/sec.

You probably get a bit less without mmu libs because without the rom remap (MuFastROM?) your kickstart rom is on the same 68000 bus as the Zorro2 interface, stealing cycles from it because it is executing lot of OS code from it at the same time. On 3.1 you can just run the OS-included “cpu fastrom” for the same effect btw.

[thebajaguy]

The GVP-FAQ on the OS 3.1.4 and later media has the answers to addressing performance. If not handy:

Set all DMA Mask values to 0xFFFFFFFE on all applicable partitions with your default partitioning tool - the gvpscsi.device driver is 24/32-bit DMA aware and handles CPU-buffering more efficiently than the File System Mask Hack

The HC8 should have 2MB 16-bit RAM on it, if possible. SCSI DMA to/from that memory will be done automatically, and the CPU will get called to drop into/pull it from the TF's 32-bit Memory.

Worst case (no 16-bit FastRAM), DMA will happen to ChipRAM - not ideal, but still faster than the Filesystem Mask Hack.

Best performance will be about 1/2 the bus speed of Z2, which is in the ballpark of 1.7MB/sec under optimal conditions (disk unit capable of those speeds, and very fast CPU clock/good 32-bit memory speeds).

I wrote the GVP FAQ in the 3.1.4/3.2.x release media, and I worked at GVP Tech Support.

[StompinSteve]

I actually suspect that my Kickstart is not in FastRam because in SysInfo, It says "64MB" and "8MB". On my Blizzard 1240T (with the Fastrom jumper set), it says 63.5 MB RAM meaning 0.5 is consumed by the remapped Kickstart.

Back to this A500+. I solved the crashed with MMUlib after enabling the 8MB on the GVP. I must use the "Head" parameter with MuFastRom and then I have the full CPU performance back (and Kick is in Fast). HDD (ZuluSCSI) Performance is back to around 780 KB/s. But nowhere near where it should be.

I will try Bajaguy's advice next. Watch this space.

[thebajaguy]

If you have to manually add the FastRAM on the TF with a command, use the AddMem feature in MuLubs config file instead so that the memory is added when SetPAtch is loaded with the CPU library, and the Kickstart Remap can happen (after) to that memory (and not the GVP 16-bit FastRAM).

[StompinSteve]

"If you have to manually add the FastRAM on the TF with a command, use the AddMem feature etc."

Hello Bajaguy i'm sorry i'm not following. Is it related to this: When I don't use the "head" parameter with MuFastRom (so just "MuFastRom On Protect") I get an endless boot-loop with funky disco-graphics. When I do ""MuFastRom On Protect Head" the system works again (I don't need "head" when I disable the 8MB RAM in the GVP HD8+).

If I don't use MuFastRom at all, I can achieve Kick in Fast by using "cpu fastrom". Both work to map kickstart 3.1 to fast.

By the way, the result of setting all DMA Mask values to 0xFFFFFFFE on all 4 partitions: same speed as before. No difference. Still 720-isch KB/s.
The previous value was 0x7FFFFFFE on all 4 partitions. Both values result in the same performance in SysInfo.

Can my GVP's ROM v4.13 have anything to with it? A bug? 4.15 release-notes speaks of "fixing problems with accelerators".

[patrik]

Originally Posted by StompinSteve

"If you have to manually add the FastRAM on the TF with a command, use the AddMem feature etc."

Hello Bajaguy i'm sorry i'm not following. Is it related to this: When I don't use the "head" parameter with MuFastRom (so just "MuFastRom On Protect") I get an endless boot-loop with funky disco-graphics. When I do ""MuFastRom On Protect Head" the system works again (I don't need "head" when I disable the 8MB RAM in the GVP HD8+).

Sounds strange that MuFastROM should need the HEAD argument to not crash.

This argument is only useful if you have a fast memory block merged from two memory types where one is faster and one is slower, very uncommon. Can happen with say A2630 plus a Zorro2 memory card as the A2630 puts its memory into Zorro2 space. This head argument then lets you control if the rom image should end up in one or the other block.

Could it perhaps have anything todo with the wonky end address of the TF536 RAM of $44000007? Perhaps @Thomas Richter can give some insight?

Originally Posted by StompinSteve

By the way, the result of setting all DMA Mask values to 0xFFFFFFFE on all 4 partitions: same speed as before. No difference. Still 720-isch KB/s.
The previous value was 0x7FFFFFFE on all 4 partitions. Both values result in the same performance in SysInfo.

Those are effectively the same, 0x7FFFFFFE limits the address space to first 2GB and even addresses (the E at the end). 0xFFFFFFFE would be the entire 4GB and even addresses. I would prefer the latter, just posted the former as it is the default and Amigas do not have memory above 2GB.

Originally Posted by StompinSteve

Can my GVP's ROM v4.13 have anything to with it? A bug? 4.15 release-notes speaks of "fixing problems with accelerators".

Did you read the calculation in my previous post?

If the SCSI disk you have manages 1MB/sec with the original 68000, that will be the maximum speed the data from that device can be DMA'ed to chipram or GVP-ram. When you then add the TF536 accelerator, gvpscsi.device additionally has to copy the data from chipram or GVP-ram using the CPU over the Zorro2-bus at a theoretical max of 3.5MB/sec.

Say you have 5MB data to read. It will then take 5/1 + 5/3.5 = 6.43s. This gives a theoretical max speed of 5/6.43 = 0.78MB/sec for your setup.

Note that the biggest bottleneck (biggest contributor of time) in the above calculation is the 1MB/sec SCSI disk.

It is really slow for being modern - as a comparison I have the same GVP on an A500+ and it does double that with an old 2GB seagate. Most gain will be had from improving that bottleneck.

[thebajaguy]

The 4.15 version (vs earlier) fixes a 'bug' with some A3000/A4000 accelerators (not applicable to the Z2 machines) where Z2 DMA into ChipRAM can hang the bus. The driver effectively treats the ChipRAM on those machines as not DMA-able, and uses the Z2 FastRAM buffering solution also used for address targets >16MB RAM.

I want to actually clarify that bug: The A3000/A4000 Z2 DMA bug comes from the load that some accelerators may place on some Amiga CPU slot bus signals, and results in the SuperGary/Buster timing for that DMA into ChipRAM becoming a bit off. It can affect the A2091, GVP Series II (and PhonePak), or the Micobotics HardFrame - all Z2 busmaster/DMA controllers. It was actually discovered by the PhonePak interactions, as the card DMA's audio in small but frequent bursts, and can target a buffer in ChipRAM for audio playback.

The Mask of 0xFFFFFE = means the 24 bit address space.
The Mask of 0xFFFFFFFE = the 32-bit address space. Always use this with the GVP Series II (DPRC) interfaces, or you end up with the FFS solution for buffering to non-DMA-able addresses, which has horrible performance.

Always use the MaxTransfer of 0x7FFFFFFF - this is equal to 2GB. The driver handles everything fine. It's not brain-dead like the A1200/A4000 IDE interface driver.

From observations, ZuluSCSI should pull similar to SCSI2SD v5, the latter which tops out at 1.1MB/sec. If you want to test this with the RSCP benchmark, initially don't add the TF (high, 32-bit) memory and just run with the GVP 2-8MB FastRAM. Test to the FastRAM ($200000-9FFFFF) and you will have your best-case performance mark. Anything off that (later) to the 32-bit memory addresses is linked to CPU overhead and Amiga Z2 bus limitations.

[StompinSteve]

"initially don't add the TF (high, 32-bit) memory and just run with the GVP 2-8MB FastRAM. Test to the FastRAM ($200000-9FFFFF)"

Dumb question: how do I do that?

[thebajaguy]

I don't own one, but I assume there is a means to.

In any event, skip that - this is a slightly newer version of RSCP with a 24-bit DMA memory target selection setting button.

https://www.dropbox.com/s/lojdvk0ymr...-1.14.zip?dl=0

I've never updated the AmiNet version, but it's safe to use and pass around.

[StompinSteve]

"From observations, ZuluSCSI should pull similar to SCSI2SD v5, the latter which tops out at 1.1MB/sec"

ZuluSCSI is reported (on several websites) to be much faster. For example in this Blog, they use a stock A3000, replaced the HDD with a ScsiZulu v1.1 and it reads with 4.4 MB/s in SysInfo.
"On a stock A3000/030, where BlueSCSI was showing around 1MB/sec, the ZuluSCSI will more than quadruple that at 4.4MB/sec. That’s also faster than the 1.3MB/sec SCSI2SD v5.2 we tested."
Source: https://www.pureamiga.co.uk/2022/05/20/zuluscsi-review/

I downloaded your RSCP. I'll get to work with it after work.