English Amiga Board - View Single Post

Zetr0 · 26 July 2010, 13:58

For me the only selling point for PFS is the support for the basic 68000 cpu, thus my A500+ with 2MB CHIP and 8MB FAST (via the GVP HC8+) could have a good 20GB SCSI drive without stupid ammounts of partitions! =D

I have been using SFS for a fair while and it impresses me, and yeah it does use a bit more CPU time but I ask what else is an 030, 040 or 060 suposed to do other than sit there, suck juice and look good?

I took a few days to do some serious testing with controllers and formats and here are some of my results using (RSCP) Raw System Speed Test with Smart File System (SFS)

(A4000 Cyberstorm Mk2 060@50 / Samsung SpoinPoint UDMA ATA133 8MB cache 20GB )
Native IDE - 2.7MB per second 100% CPU usage*

*Now i personally believe that the program used only has a small test write/read chunk as set I think most (if not all of it) was sitting in the HDD Cache as 2.7MB is theoretical not possible from the onboard IDE controller

to contrast this information, an A1200 with Falcon 040@25 MHz achieves only 2.1MB per second via the Native Onboard IDE (100% CPU time)

Now Back to the A4000
(CyberSCSI2 Fast SCSI2 + 18.1GB 2MB Cache 10kRPM Cheeta SCSI2*)
CyberSCSI2 *async mode* - 4.4MB per second 38% CPU usage / 62% idle*
CyberSCSI2 *sync mode* - 6.2MB per second 38% CPU usage / 62% idle*

This results I think are skewed duer to the age/use of the HardDisk, the unit comes from a second industry user background so its had a hard life - I was hoping to try the 20GB HDD that was originally used on the Native IDE but this time with a SCSI-IDE bridge alas I dont have any - anymore - and the price of them is an outrage

A little more for contrast

BlizzardPPC 330eplus + 68060@60 (Fast SCSI2) + SCSI-IDE bridge + 40pin IDE to 1.8" ZIF adapter - Hitachi 40GB (from dead IPOD)

Async mode = 4.7MB with 36% CPU usage / 64% idle*

*Now the 40GB 1.8" ZIF (IPOD) drives are very slow spinners and have little or NO cache onboard them, alas I never tried sync mode to see if it is any faster.

All the tests were conducted on SFS formatted drives under ClassicWorkbench OS3.9 with exception to the first A1200 / 040 test as that was using ClassicWorkbench Advanced (later replaced for CW39)

Now lets flip this lot on it head and see what Fast File System (FFS) can do

Using Samsung Spin Point UDMA ATA133 20GB 8MB Cache

Unit: A1200 + Falcon 040@25 - Native IDE - Speed 1.2MB per second 100% CPU time
Unit: A4000 + CybeSMk2 060 - Natvie IDE - Speed 2.1MB per second 100% CPU time

In contrast - an A500+ with SCSI controller
Unit: A500+ (2MB Chip) 8MB Fast - GVP HC8+ FastSCSI2 - SCSI-IDE Bridge - 1.67MB 12% CPU time (88% Idle)

I have a combo 040 to test the above controller with SFS.

All in all there are two lynch pins in any Amiga setup - the Device Controller (DMA or not DMA) and the Format of the unit

I can honestly Say that on the A4000 loading Quake from the SCSI Disk takes only a 3rd of the time compared to the Native IDE, which is pretty much down to the CPU having a more time to process what it fetches.

26 July 2010, 13:58	#18
Zetr0 Ya' like it Retr0? Join Date: Jul 2005 Location: United Kingdom Age: 49 Posts: 9,768	For me the only selling point for PFS is the support for the basic 68000 cpu, thus my A500+ with 2MB CHIP and 8MB FAST (via the GVP HC8+) could have a good 20GB SCSI drive without stupid ammounts of partitions! =D I have been using SFS for a fair while and it impresses me, and yeah it does use a bit more CPU time but I ask what else is an 030, 040 or 060 suposed to do other than sit there, suck juice and look good? I took a few days to do some serious testing with controllers and formats and here are some of my results using (RSCP) Raw System Speed Test with Smart File System (SFS) (A4000 Cyberstorm Mk2 060@50 / Samsung SpoinPoint UDMA ATA133 8MB cache 20GB ) Native IDE - 2.7MB per second 100% CPU usage* Now i personally believe that the program used only has a small test write/read chunk as set I think most (if not all of it) was sitting in the HDD Cache as 2.7MB is theoretical not possible from the onboard IDE controller to contrast this information, an A1200 with Falcon 040@25 MHz achieves only 2.1MB per second via the Native Onboard IDE (100% CPU time) Now Back to the A4000* (CyberSCSI2 Fast SCSI2 + 18.1GB 2MB Cache 10kRPM Cheeta SCSI2)* CyberSCSI2 async mode - 4.4MB per second 38% CPU usage / 62% idle* CyberSCSI2 sync mode - 6.2MB per second 38% CPU usage / 62% idle* This results I think are skewed duer to the age/use of the HardDisk, the unit comes from a second industry user background so its had a hard life - I was hoping to try the 20GB HDD that was originally used on the Native IDE but this time with a SCSI-IDE bridge alas I dont have any - anymore - and the price of them is an outrage A little more for contrast BlizzardPPC 330eplus + 68060@60 (Fast SCSI2) + SCSI-IDE bridge + 40pin IDE to 1.8" ZIF adapter - Hitachi 40GB (from dead IPOD) Async mode = 4.7MB with 36% CPU usage / 64% idle* Now the 40GB 1.8" ZIF (IPOD) drives are very slow spinners and have little or NO cache onboard them, alas I never tried sync mode to see if it is any faster. All the tests were conducted on SFS formatted drives under ClassicWorkbench OS3.9 with exception to the first A1200 / 040 test as that was using ClassicWorkbench Advanced (later replaced for CW39) Now lets flip this lot on it head and see what Fast File System (FFS)* can do Using Samsung Spin Point UDMA ATA133 20GB 8MB Cache Unit: A1200 + Falcon 040@25 - Native IDE - Speed 1.2MB per second 100% CPU time Unit: A4000 + CybeSMk2 060 - Natvie IDE - Speed 2.1MB per second 100% CPU time In contrast - an A500+ with SCSI controller Unit: A500+ (2MB Chip) 8MB Fast - GVP HC8+ FastSCSI2 - SCSI-IDE Bridge - 1.67MB 12% CPU time (88% Idle) I have a combo 040 to test the above controller with SFS. All in all there are two lynch pins in any Amiga setup - the Device Controller (DMA or not DMA) and the Format of the unit I can honestly Say that on the A4000 loading Quake from the SCSI Disk takes only a 3rd of the time compared to the Native IDE, which is pretty much down to the CPU having a more time to process what it fetches.