A500 SCSI interface speed comparison

[Photon]

This is for Amiga 500. I tested on Kick 2.05, FFS.

My SCSI interface is connected via the Vesalia SCSI-to-IDE-converter, to an IDE-CF adapter from Hong Kong, to a SanDisk Extreme III 2GB (2x 980MB partitions).

Measured with the latest Sysinfo.

I'm starting off with two interfaces. I've measured using 20 buffers in the bootrecord, so that it will influence the results as little as possible:

Trumpcard 500 Professional
- SCSI 2
- non-DMA-based
- no fastmem board installed.

Test results:
68000, no fastmem: 903944 bytes/sec
68040, 4MB onboard zip fastmem: 1705926 bytes/sec


GVP Impact Series II A500-HD+ (Rev 3 board, Omni ROM v3.5)
68000, 2MB fastmem on the GVP: 1975959 bytes/sec!
68040, total 6MB fastmem: 907072 bytes/sec

Apart from posting your awesome A500 rigs, could someone tell me the reason for the 68040 slowdown with GVP?

I can think of a couple reasons:
- Burning a bootrom V7.0 will fix it? (It already autoboots the 980MB partition fine in 040 mode)
- it or the libs uses the GVP ram<->68040 board ram, which results in shuffling data or other slowdown? How to fix?
- My 68040 board interferes with the GVP ram (why then does Avail show 6MB fast?)
- My 68040 board has trouble accessing the GVP ram via the 68000 socket (how to fix?)

[alexh]

Originally Posted by Photon

could someone tell me the reason for the 68040 slowdown with GVP?

If I were a guessing man, I'd say it had something to do with transferring data between non DMA capable 32-bit RAM on the 68040 card.

You could maybe change the RAM priorities, but that would adversely affect raw data processing speed.

Originally Posted by Photon

- Burning a bootrom V7.0 will fix it? (It already autoboots the 980MB partition fine in 040 mode)

I think you are getting confused with A590/A2091. There is no bootrom V7.0 for GVP devices, the last one was v4.15.

http://babel.de/amiga.html

A GVP Guru ROM (omniscsi) v6.14 would be the best, if you could get one. Do you already have one? Is Omni ROM the same as a GURU ROM? Pretty easy to tell, there is a little PCB below the ROM

[Jope]

Originally Posted by alexh

If I were a guessing man, I'd say it had something to do with transferring data between non DMA capable 32-bit RAM on the 68040 card.

You could maybe change the RAM priorities, but that would adversely affect raw data processing speed.

Sorta. You need to limit the mask so that the driver doesn't try to DMA to RAM it can't see.

Messing with mem block priorities will lead to slowdowns elsewhere.

[Photon]

Yes, it must be a DMA issue with the accelerator ram. I change the mask in the "MBR"?

And yes, I also got an A590 here which I'll try later today... translate "ROM 7.0" into "latest ROM version", whatever that is and where I can find it

I'll give the mask a go and possibly the gvpscsi.device could be old.

[prowler]

Originally Posted by Photon

... translate "ROM 7.0" into "latest ROM version", whatever that is and where I can find it

...possibly the gvpscsi.device could be old.

alexh linked to it above:
http://babel.de/amiga.html
(version 4.15)

[Photon]

Yeah, um, should have said I downloaded all the babel stuff yesterday, but I was in too big of a rush.

I'll post back results/resolution.

[Toni Wilen]

ROM updates or mask isn't going to help. It is 24-bit DMA restriction, no A500 compatible DMA controller can DMA to accelerator fast RAM which is outside of 24-bit area (over 16M "border")

Most controllers fall back to PIO if memory is not DMA capable. (and because they are mainly DMA controllers, PIO mode won't be optimized for speed like in non-DMA controllers..)

[rkauer]

A small hint: if you run Sysinfo you'll see the SCSI controller driver in the upper left window when you select "devices".

There you'll find the current version of the controller.

[Photon]

Toni, can I tell the driver to use the "other" fastram (on the controller) instead of the accelerator memory, in some way?

It's pretty strange, since the accelerator fastram isn't visible (at least to AmigaOS/"Avail") until I invoke the Init040 addmem command..?

The scsi driver should have been loaded at boot and thus not see it, right?

[Toni Wilen]

Originally Posted by Photon

Toni, can I tell the driver to use the "other" fastram (on the controller) instead of the accelerator memory, in some way?

It's pretty strange, since the accelerator fastram isn't visible (at least to AmigaOS/"Avail") until I invoke the Init040 addmem command..?

The scsi driver should have been loaded at boot and thus not see it, right?

You mean even without 68040 RAM expansion enabled transfer rates (to 24-bit Fast) are slow? What happens if you try with chip ram only?

[Photon]

Test results: (GVP install disk from amiga.resource.cx installed, patched to latest (Babel) version afterwards.)

With 68040 RAM uninitialized, speed is 1913 KB/s, as expected. With 68040 ram on, I get 980 KB/s like before.

I wasn't thinking. The dilemma is that I want to load "any app" into 68040 ram for fast execution, but all apps will ofc (if they load something from dh0) load the data to anywhere they want in any ram.

So I don't want to use the slow ram on the SCSI controller first, because processing it will be slower with the 68040. But I do want to use the SCSI controller RAM first, because loading is faster.

There was a "SCSImaskfix" on the install disk, and it toggles the mask from ffffff <-> ffffffff. (What does it do? What is mask for? I think I need a link to "harddisk values explanation and theory :P)

It needs:
- board number (GVPinfo & sysinfo shows 3 board... is the middle board board # '2'?)
- LUN (what is this? Same as Unit in info for the cylinders etc?)
- SCSI id (I * think* this is 5... how do I check. Can't find it in above programs.


But I think the only solution is reserving a big buffer in SCSI controller RAM and hack the driver to copy with the 68040 from there while DMA is transferring...? Then you could get near the max of the 1900 KB/s DMA speed. (It must already do this ofc, but I wonder why it's 1MB/s with an 040 compared to a few MHz of DMA...)

Because CPU speed in Sysinfo is TERRIBLE with 68040 ram off. (0.55 x A3000)

[rkauer]

Modify the HD partitions mask from 0x0fffffff to 0x00fffffc on all partitions. This will stop the controller to reserve DMA memory on the accelerator RAM and will use the 24-bit on the board itself.

Also remember to use the rightmost Zorro slot for the SCSI controller.

[Photon]

At any rate I wonder why it's much slower than my Trumpcard non-DMA interface using the same 68040?

Unless it REALLY CAN dma to expansion mem on the 68040 board, but at half speed or so.

However it is, I'm quite far from the promised 3.5MB/s maximum. I know some people set 1000 buffers, well sure. As long as I can put them in GVP card's ram. If the buffers are the direct target of DMA, that is.

Too much theory with too little info. Some guru needs to tell it like it is I'm off to look for info in the meanwhile. But I think the info I need is pretty much a 'how to build a DMA-based SCSI interface'. So sources could be scarce :P

[Damion]

Originally Posted by Photon

Unless it REALLY CAN dma to expansion mem on the 68040 board, but at half speed or so.

I'm no expert, but found a few comments on this in Ralph Babel's Guru-Rom book:

Some accelerator cards, such as the Commodore expansions "A2620" and "A2630", also configure up to 4 MB of their 32-bit RAM in the Zorro-II region. Therefore, this memory is also accessible by the Series-II host adapter via Zorro-II DMA.

and

On the other hand, it is never possible to transfer data via DMA into the memory of a separate accelerator card if they configure their memory in the upper memory areas -- outside the Zorro-II DMAable region -- starting at 0x01000000 or have no connection to the Zorro-II bus -- like some accelerators for the A500/A500+. The omniscsi.device recognizes the former and chooses a different transfer method depending on what is appropriate at the time.

He goes on to say that there are some (buggy) accelerators which do configure 4 MB in the Z2 space, but don't make the memory reachable by DMA.

However it is, I'm quite far from the promised 3.5MB/s maximum.

I don't think that speed is possible, 2.3 MB/s DMA into Z2 RAM is the max (also according to Ralph's book)... though finding a Guru-ROM and/or using a better filesystem might help a little.

One other random possibility... some cheaper CF adapters don't support DMA. Apparently this shouldn't make any difference (someone here mentioned a while back, may have been Toni, that the SCSI -> IDE adapter handles DMA on its own, regardless of the CF adapter). However, I either get slow transfers, or no boot whatsoever if I disable the DMA jumpers on my CF adapters, when used with DMA SCSI controllers. (No difference with the A1200 which is obviously non-DMA.)

[rkauer]

@Photon: did you test the modification of the mask value on one of the partitions?

As said before, using mask=0x0FFFFFFF the Workbench will try to use 32bit Fast RAM as DMA (will try to use the accelerator's memory), creating a bottleneck trying transfer the Zorro-II controller's DMA to the accelerator slot, asking room on the 32-bit memory.

Setting the value to mask=0x00FFFFFC will allocate 24-bit memory (memory on the SCSI controller itself), facilitating the controller's "life".

[Photon]

Originally Posted by Damion

I'm no expert, but found a few comments on this in Ralph Babel's Guru-Rom book:

and

He goes on to say that there are some (buggy) accelerators which do configure 4 MB in the Z2 space, but don't make the memory reachable by DMA.

I don't think that speed is possible, 2.3 MB/s DMA into Z2 RAM is the max (also according to Ralph's book)... though finding a Guru-ROM and/or using a better filesystem might help a little.

One other random possibility... some cheaper CF adapters don't support DMA. Apparently this shouldn't make any difference (someone here mentioned a while back, may have been Toni, that the SCSI -> IDE adapter handles DMA on its own, regardless of the CF adapter). However, I either get slow transfers, or no boot whatsoever if I disable the DMA jumpers on my CF adapters, when used with DMA SCSI controllers. (No difference with the A1200 which is obviously non-DMA.)

Heh. I was hovering with my mouse pointer over the Buy button for that book just a couple hours ago.

I think the speeds are proof that DMA is indeed taking place with the SCSI-IDE adapter from Vesalia to an A500 expansion port. My CF-IDE adapter cost $1.97 or similar from a Hong Kong seller on eBay and has no DMA on/off jumper.

My SCSI ram is at $200000 and 68040 ram at $800000, so within Z2 range.

And I don't mind the speed, I just wonder what rig/benchmark they had when they wrote that figure????

I have no omniscsi.device... just gvpscsi.device, which must be in the Omni 3.5 rom chip, since it's not on the GVP install disk. Can I make it use some never .device file by a startup-sequence command maybe?

Thx, now I know some more!

[Photon]

Originally Posted by rkauer

@Photon: did you test the modification of the mask value on one of the partitions?

As said before, using mask=0x0FFFFFFF the Workbench will try to use 32bit Fast RAM as DMA (will try to use the accelerator's memory), creating a bottleneck trying transfer the Zorro-II controller's DMA to the accelerator slot, asking room on the 32-bit memory.

Setting the value to mask=0x00FFFFFC will allocate 24-bit memory (memory on the SCSI controller itself), facilitating the controller's "life".

Not that it's likely to happen, but... won't this mean that whatever I load will be executed slowly by the 68040? (Deja vu from another thread)

I'd much rather it switched to non-DMA if I have a CPU that does things faster than DMA. Any way of doing this? New ROM chip fixes all?

Is addbuffers EXACTLY the same as changing buffers in RDB? I'll try addbuffers and see if it has any effect at all.

[rkauer]

Originally Posted by Photon

Not that it's likely to happen, but... won't this mean that whatever I load will be executed slowly by the 68040? (Deja vu from another thread)

Nope, just the controller behaviour.

I'd much rather it switched to non-DMA if I have a CPU that does things faster than DMA. Any way of doing this? New ROM chip fixes all?

Don't know in this exactly case, but polled I/O transfers (non-DMA) are completely CPU-dependent (speed-wise).

Is addbuffers EXACTLY the same as changing buffers in RDB? I'll try addbuffers and see if it has any effect at all.

Yes, just you need a line on startup-sequence for each partition you want to modify. Notice that more buffers you have, more Fast RAM will becoming unavailable for programs/games.

[Photon]

But doesn't setting the mask to ....FC mean no data can ever be transferred to the 68040 RAM? Oh well, I'll give it a try. HDinsttools, or Faaastprep, or what? Cos the FastPrep on the GVP disk thought my CF was 195MB, so I'm not sure I want to use that. :P

Nothing magical about putting addbuffers in the S-S I take it. Well, addbuffers 980 did absolutely nothing on the speed.

ROM update doesn't help, Toni said that. I should read more carefully.


Anyway, I'll change some values in the RDB and try.

And the omniscsi.device vs gvpscsi.device thing?

I'm using the WB 2.05 binddrivers btw, don't think it has anything to do with anything tho.

[rkauer]

Originally Posted by Photon

But doesn't setting the mask to ....FC mean no data can ever be transferred to the 68040 RAM? Oh well, I'll give it a try.

I didn't said that! Just the DMA buffer will be allocated to controller's RAM.

HDinsttools, or Faaastprep, or what? Cos the FastPrep on the GVP disk thought my CF was 195MB, so I'm not sure I want to use that. :P

Plain HDToolBox or HDinstTools. As far as I know, modifying the mask value will not destroy any data on the affected partition.

Big <SNIP>
And the omniscsi.device vs gvpscsi.device thing?

OmniSCSI.device is the masterpiece of the SCSI ROM for GVP units and A2091/590. It milks a rock, as we say here. Excellent performance boost from the mentioned controllers. Too bad the device is rare and expensive.

I'm using the WB 2.05 binddrivers btw, don't think it has anything to do with anything tho.

So go to the mask value, boy!