SCSI madness

[Damion]

S: I always run in PIO4 on the Amiga and even on reading/writing 8GB DVD ISO files there is no great slowdown in the performance of the Amigas multi tasking... (I can even got upto PIO5 with the DVD burners but they then become prone to errors when writing...

Interesting. What kind of results to you get with the FastATA running the RSCP benchmark? My TekMagic for example approaches 10MB/s while leaving 98-99% CPU free.

[Franko]

Interesting. What kind of results to you get with the FastATA running the RSCP benchmark? My TekMagic for example approaches 10MB/s while leaving 98-99% CPU free.

Never heard of RSCP but I'll download it and see what results it gives...

It won't be anywhere near the results of using a SCSI drive (FastATA even on my 060 can only manage about 5.6MB/s) but that's fast enough for me and I't doesn't seem to hold me up from doing other things at the same time...

I'll run some tests with RSCP and let you know the results...

[Damion]

Thanks Franko, no rush. I have an IDE-Fix Express in my A1200, it's true with the '060 you really don't notice the slowdown as much. I've never had a FastATA but IIRC the raw transfer rate is something like twice the IDE Express.

[Darrin]

Thanks Franko, no rush. I have an IDE-Fix Express in my A1200, it's true with the '060 you really don't notice the slowdown as much. I've never had a FastATA but IIRC the raw transfer rate is something like twice the IDE Express.

The question is, does your typical Amiga user notice this huge transfer rate difference when loading/moving/saving less than half a meg of data?

The answer is... no.

So, unless you're doing some serious stuff, a cheapo IDE adapter with cheapo IDE drives works wonders.  

[freqmax]

Besides even if there's no more SCSI/IDE drives to get hold of. One can replace them the same way as has done with the floppy. Besides there's always the possibility to use a unix machine (PC) as a fileserver.

It's also possible to create a SCSI <-> S-ATA bridge with an FPGA like Spartan-6, even in their low-end versions.

In the end it's all about how the communication link is done. What kind of hardware assitance it uses (DMA) and time slots. Like idle priority, fast mem only, chip mem etc.. If one reads the technical specification it becomes obvious that U160 still beats S-ATA in reliability.

[paul1981]

Hello all,

I tried out the RSCP benchmark tool on my system and got these results using the default test settings:

Transfer rate : 7876 K/sec
Dhry/sec Idle : 62658

I'm running an Apollo1260/66/32MB with FastATA Mk-III in PIO5 on a IBM-DKLA-23240 (an old 3.25GB 2.5")
I know I'd get better results with a more modern drive...because it's such an old noisy drive - need to change it!

The other results from the test didn't work for me unfortunately (busy/idle and Dhry/sec busy) - I got empty readings of ZERO.  I suppose the speed of the system confused it somewhat, it is after all a 20 year old program.

I've used this setup though with Audio Evolution 3 with 12 stereo tracks and 5 mono tracks (mostly playing back together, 17 in all, all tracks 16bit 44KHz - just checked my last project) and this is also being mixed via AHI in 16bit through to the clockport Prelude.  If the FastATA was such a CPU eater then I doubt I'd be able to do the above, so I'm pretty sure the FastATA can't be too CPU hungry.  Oh, I have to thank SFS too...poor old FFS was pretty much useless for this task.  Thank you ELBOX, thank you Smart Filesystem.

[Franko]

I've used this setup though with Audio Evolution 3 with 12 stereo tracks and 5 mono tracks (mostly playing back together, 17 in all, all tracks 16bit 44KHz - just checked my last project) and this is also being mixed via AHI in 16bit through to the clockport Prelude.  If the FastATA was such a CPU eater then I doubt I'd be able to do the above, so I'm pretty sure the FastATA can't be too CPU hungry.  Oh, I have to thank SFS too...poor old FFS was pretty much useless for this task.  Thank you ELBOX, thank you Smart Filesystem.

I haven't run the test myself yet but I do agree with you that folk claiming that FastATA is CPU hungry are way of the mark...

Been using FastATA for years now and working on big 4 to 8GB single file sizes and I've never had any bother with it slowing my Amiga down on either an 030 or 060...

SFS is the best Amiga file system for large HDs and large files too in my opinion...

[Damion]

The "0" only indicates there is no free CPU during the transfer - as expected with the FastATA, since the CPU must shovel all the data around itself.

[paul1981]

The "0" only indicates there is no free CPU during the transfer - as expected with the FastATA, since the CPU must shovel all the data around itself.

I seriously doubt that the ZERO is a valid result though, because if that was the case, if it was truly ZERO, then the whole system would freeze whilst it was performing the test. ie mouse pointer would freeze, Workbench would freeze...I wouldn't be able to open windows or do anything whilst running the test.  If it was ZERO then even navigating my drawers on Workbench whilst playing an aiff song would show a slow down in Workbench everytime it had to buffer....and I've never noticed any such slowdown.

Then again, I might be totally wrong...even so, the FastATA enabled me to use Audio Evolution to it's full on the 68k, as did SFS.

I'd like to see more results from a variety of systems, and some results with 030 and 040 CPU's.

BTW, I used to copy scsi hard drives one to the other using squirrelscsi and it wasn't all that bad....it was quite good!  I do like SCSI! :laughing:

I would have liked to have used the blizzard1260 and it's scsi but I found the blizzard runs too hot to be in a standard desktop case due to it's underside mounted CPU, and I don't have the room to setup a towered amiga.  Also the Prelude connects to the little backplate where the scsikit connection would be.

[Damion]

I seriously doubt that the ZERO is a valid result though, because if that was the case, if it was truly ZERO, then the whole system would freeze whilst it was performing the test. ie mouse pointer would freeze, Workbench would freeze...I wouldn't be able to open windows or do anything whilst running the test.  If it was ZERO then even navigating my drawers on Workbench whilst playing an aiff song would show a slow down in Workbench everytime it had to buffer....and I've never noticed any such slowdown.

It actually is close enough to zero. Another test, watch the Executive meter while copying a large file between partitions. On native A4K IDE, it eats nearly 99% CPU during the transfer. FastATA is no different, there's no controller chip with DMA access to accelerator fastram.

The system doesn't slow to a crawl because the OS can multitask. (This is why the RSCP benchmark mentions mouse movement - it will steal CPU time and might alter the result.) But to transfer continuously at it's maximum rate, it will utilize almost all CPU time. It has to, because the CPU is doing all the work of transferring! A good DMA SCSI controller will do the same while utilizing much less CPU, because the data transfer is handled by a dedicated processor which has direct access to fastram. (The CPU sets the parameters of the transfer, but doesn't do the work.)

BTW, I used to copy scsi hard drives one to the other using squirrelscsi and it wasn't all that bad....it was quite good!  I do like SCSI! :laughing:

The Surf Squirrel doesn't count, AFAIK there is no DMA path from the PCMCIA port to accelerator fastram. So it's PIO only and equally CPU-intensive.

[paul1981]

The Surf Squirrel doesn't count, AFAIK there is no DMA path from the PCMCIA port to accelerator fastram. So it's PIO only and equally CPU-intensive.

Yes, that's true - but still a great little piece of kit.  Used my 1200 with a scsi cd-rom drive via the squirrel and back in those days it was the best option unless you had a blizzard scsi.  I never had the Surf Squirrel - mine was the standard (without the serial port).

A piece of hardware I really would like to see again is the clockport expander for the 1200/600.  I hope that Jens is reading this... LOL. :lol: