Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: fishy_fiz on February 25, 2011, 12:04:32 AM
-
Firstly, Im wondering what the maximum speed obtainable on the internal ide interface of an a1200 is ? On my 40mhz '040 system + old 10gig drive the speed leaves a lot to be desired. Maybe I'd just adjusted to using an external scsi card, or using my amithlon box, but things seems to be slower than I remembered. Does 1MBps (give or take a few hundred KB) seem excessively slow ? I know it's never going to be fast, but I have a sneaking suspicion my drive is a bit on the crap side. Im getting a larger drive soon, but Im interested to find out any info in regards to the internal interface before I do so as to help shape what I purchase. Also, is it possible to run multiple devices off of it ? I vaguely recall that it is, but it's recomended not to be done ?
-
I get about 1.5MBs on my A1200. There is supposed to be a lib hack that will enable 3MBs.
-
It's PIO0 (programmed IO mode 0) and so the speed is proportional to the speed of your CPU and your memory. Plus the optimisation of your hardware driver & filesystem. Maybe a little bit the speed of the drive but doubtful.
Cosmos recently re-worked the scsi.device driver to include lots of optimisations.
http://eab.abime.net/showthread.php?t=57419
SFS or PFS file systems both offer significant speed increases over standard FFS.
http://strohmayer.org/
So patch your scsi.device, upgrade to SFS (both free) and you'll see significant speed increase. (2x?)
-
I would say that 2.5MB/s is the maximum speed available for the standart A1200 IDE port. It will be dependant on the storage media (hdd), scsi.device and filesystem in use, and the timing scheme your accelerator uses to interface the Amiga bus.
-
if I remember right last time I checked it the speed was at 2 MB/S. Thats with compact flash instead of a physical hard drive
-
DriveSpeed reports the following figures for both FFS & SFS HDs...
Using FastATA MKIII Buffered interface...
5,487,263 Bytes Per Second
Using 4xEIDE Buffered interface...
2,547,512 Bytes Per Second
You can run two 2.5" HDs on the Amigas motherboard IDE connector but you have to keep the cables to about 2 to 3 cm at most (but I don't recommend it)... :)
Finding the FastATA MKIII or the 4xEDIE can be tricky though, just bought another 4xEIDE board on eBay last week cost £27.50 and a FastATA MKII sold for £47... :)
-
Yep as a rough rule of thumb the MAX is:
FastATA: > 8 MB/s
Ide FixExpress > 5 MB/S
Standard > 2.5 MB/S
SpeedyIDE is a good utility to try out BTW.
-
Does 1MBps (give or take a few hundred KB) seem excessively slow ?
Based on what I'm getting with my ACA1230/28 (about 2.4M/s)and what the others have said, I'd think your 68040 should do better than 1M/s.
I'm using CF as well, but just the "standard" drivers that come with ClassicWB Full (I'm assuming that uses standard drivers, I haven't checked).
desiv
-
Here's my numbers...
2GB CF card.
Standard scsi.device and ffs
Accelerator is 030 28mhz
Standard: 1.36 M/s
Accelerated: 2.4 M/s
Standard + IDE Fix: 1.5 M/s
Accelerated + IDE Fix: 3.7 M/s
-
With my FastATA MK3, I can't get PIO4 with a 133x CF Kingston. Why ? Only PIO3 !
-
Cosmos my friend, FastATA works per case sadly.
It worked on PIO4 ONLY with a speciffic HD of mine (in the past) and with every other HD or CF, PIO3 was the cap. (You can find a detailed thread of mine over EAB).
I never managed to go beyond PIO3 and that's why I decided to replace it with Idefix Express that's easier, and more compatible with all OSes.
-
Cosmos my friend, FastATA works per case sadly.
It worked on PIO4 ONLY with a speciffic HD of mine (in the past) and with every other HD or CF, PIO3 was the cap. (You can find a detailed thread of mine over EAB).
I never managed to go beyond PIO3 and that's why I decided to replace it with Idefix Express that's easier, and more compatible with all OSes.
Using FastATA MKII and ATA3.driver Ver8.x, every drive I have tested (various sizes and manufacturers) up to 500GB all work perfectly at PIO4... :)
With my 060 boards you can even put them to PIO5 and they read & write fine but I do prefer to stay at PIO4 to be on the safe side... :)
(CD/DVD Burners run fine at PIO5 too and I've never had any problems burning discs at PIO5... :)
-
Me and Zetr0 done some testing recently with an 040 based accelerater and these seem to have a negative effect on the A1200's IDE, With an Apollo 1240 and Falcon 1240 we were seeing speeds of just about 1.2mb/sec with SFS formatted CF card. Whereas on an 030/060 they were 1.8-2mb/sec.
We also found that the speed from FastATA was slower with a 1240, speed dropped from 4.7mbsec (on the 060 to about 3.7mb/sec on the Falcon 1240)
I think IDE speed is very closely tied to the accelerator and the way it has access to the custom chips, the new ACA accelerators bring huge gains to the IDE, for example on my A600 the ACA630 took my IDE speed from 1.2mb/sec to 2.5mb/sec :)
To get any decent speed from the 1240 I suggest an IDEFix Express adapter of FastATA, even so as we found it probably wont be as quick as the 030/060 based cards but it will be better.
Steve.
-
Using FastATA MKII and ATA3.driver Ver8.x, every drive I have tested (various sizes and manufacturers) up to 500GB all work perfectly at PIO4... :)
With my 060 boards you can even put them to PIO5 and they read & write fine but I do prefer to stay at PIO4 to be on the safe side... :)
(CD/DVD Burners run fine at PIO5 too and I've never had any problems burning discs at PIO5... :)
Yep, that's why I said... PER CASE!
You're a lucky man Franko if everything works just fine for you.
I used my former FastATA in both 040 and BPPC 060 with the results I previously said.
The driver was the last available and tested it with many HDs and CFs.
FastATA is a nice piece of hardware (although too unstable for my taste).
-
Yep, that's why I said... PER CASE!
You're a lucky man Franko if everything works just fine for you.
I used my former FastATA in both 040 and BPPC 060 with the results I previously said.
The driver was the last available and tested it with many HDs and CFs.
FastATA is a nice piece of hardware (although too unstable for my taste).
Never tried the FastATA on an 040 but on various 30s & 060s I've honestly never came across any problems with it... :)
Whereas with the 4xEIDE board on various set ups I've had quite a few problems trying to get them to recognise HDs bigger than 60GBs... :)
As you say it seems to be a "Per case" situation when it comes to adding bigger HDs on the Amiga especially I find with the 2.5" type... :)
-
Thanks for all the responses everyone, there's some good info. amongst all that. I'll definately look into some alternate ide interface in the future when money allows, but I was wondering if for a temporary solution it'd be possible to connect both a 3.5 inch ide drive and a dvdrom from the internal ide interface + 2.5 inch to 3.5 inch convertor? (given a power source of course)
-
1MB/sec is perfectly quick enough for me!! Reading more than a whole floppy disk in a second!! Who could want any more than that !! :)
-
I tried my FastATA MK3 with a new Sandisk 8 Gb UltraDMA 45 Mb/s = still many crashs in PIO4...
Why ????
-
1MB/sec is perfectly quick enough for me!! Reading more than a whole floppy disk in a second!! Who could want any more than that !! :)
Tension:
I agree. And with an 030 it sounds like the original IDE interface does 2MB/sec plus. So, it's more than a high density floppy per second! Sounds good enough to me.
-
The thing is though it's not like a harddrive is constantly reading one area of a disk, so 1-2 meg is quite painful a lot of the time. Extracting/compressing large files can be quite torturous.
-
The thing is though it's not like a harddrive is constantly reading one area of a disk, so 1-2 meg is quite painful a lot of the time. Extracting/compressing large files can be quite torturous.
You're right it's not like the HD is constantly reading from the disk when extracting or compressing large archives. Because with compressed files, I think it's CPU cycle intensive a lot more than dependent on a particularly fast IDE interface. Even when extracting, but especially when compressing, CPU speed is a lot more relevant than IDE and HD speed. My experience is even when compressing files, with a utility like LZX, it is rather fast to HD. That is, as long as it's not set to the highest compression level, which compresses to the max., at the full expense of CPU time. Any other setting is fast on compression (though still very efficient). And extraction is very fast.
-
Asfair A1200 internal is P-ATA.Then why the involvment of scsi.device ..?
-
You're right it's not like the HD is constantly reading from the disk when extracting or compressing large archives. Because with compressed files, I think it's CPU cycle intensive a lot more than dependent on a particularly fast IDE interface. Even when extracting, but especially when compressing, CPU speed is a lot more relevant than IDE and HD speed. My experience is even when compressing files, with a utility like LZX, it is rather fast to HD. That is, as long as it's not set to the highest compression level, which compresses to the max., at the full expense of CPU time. Any other setting is fast on compression (though still very efficient). And extraction is very fast.
That's pretty innacurate though. When extracting/compressing there's both reading and writing happening at te same time with shifts back and forward on the disk platters. That's a big part of why its so slow. Extracting to RAM proves this. Extracting even a 50 meg file is painfully slow, let alone things like isos. Yes cpu makes a difference, but harddrive speeds are a bottleneck.
-
That's pretty innacurate though. When extracting/compressing there's both reading and writing happening at te same time with shifts back and forward on the disk platters. That's a big part of why its so slow. Extracting to RAM proves this. Extracting even a 50 meg file is painfully slow, let alone things like isos. Yes cpu makes a difference, but harddrive speeds are a bottleneck.
No quite true, when using the FastATA MKIII (PIO 4) extracting a large archived file to RAM: from HD is actually faster than extracting from RAM: to RAM: ... :)
(especially on an 030 or higher...:))
@freqmax
The scsi.device is a bit of a misnomer, most likely named by CBM as at that time IDE was not popular and scsi was used by CBM instead... :)
Without going into too much technical detail, all call/functions go through the scsi.device even if you have an IDE, EIDE , ATA, P-ATA drive. They all use SCSI commands at their core the only real main difference between IDE & SCSI are the physical connecters used ... :)
-
The scsi.device is a bit of a misnomer, most likely named by CBM as at that time IDE was not popular and scsi was used by CBM instead... :)
IDE drives appear as "scsi" in Win7 even today.
-
That's pretty innacurate though. When extracting/compressing there's both reading and writing happening at te same time with shifts back and forward on the disk platters. That's a big part of why its so slow. Extracting to RAM proves this. Extracting even a 50 meg file is painfully slow, let alone things like isos. Yes cpu makes a difference, but harddrive speeds are a bottleneck.
I dunno about this. Seek times will always be a bit of an issue, but transfer speeds aren't that big a deal. Last night I was extracting some lha files from one partition to another on my 030/50 A1200. The hard drive LED spent more time off than on, showing a short burst of flickering followed by a longer idle time. This points at the number crunching throughput rather than drive speed. I think though that compression level could swing that dramatically the other way - those archives used high compression, I'd imagine you could be stuck for IDE throughput with an archive that uses low or no compression...
-
I guess my perspective was more for a faster system. An '030 I guess is still slow enough for the cpu to be as much of an issue is the interfaces throughput. Using a real scsi drive or RAM is much faster for compression/decompression than the internal ide interface, even on the same machine, which shows that cpu isnt as much of a bottleneck as the interface itself.
-
fishy fiz:
Actually it's quite accurate, for an 030 system, that I mentioned. It's sounds like you're talking about extracting and compressing both from and to the HD. I usually extract to RAM, then copy the contents to disk. In addition to a speed increase over HD, though not huge, I usually do it that way because the destination path is more manageable to control with LZX. I haven't regularly worked with archives of 50MB+. I guess that depends how fast you expect it to still be with archives that huge. But I can tell you LZX is significantly faster than something like UnArc (from OS3.9). CPU time is the slower factor with any decent amount of compression, and that's with an 030@40 and 882@50. I don't know what CPU you're using, 060, PPC?
Franko:
I was wondering that about the SCSI.device too. Interesting :-).
-
The scsi.device is a bit of a misnomer, most likely named by CBM as at that time IDE was not popular and scsi was used by CBM instead... :)
scsi.device was named scsi.device for software, such as HDToolBox that by default assumes hard drives are using scsi.device.
Without going into too much technical detail, all call/functions go through the scsi.device even if you have an IDE, EIDE , ATA, P-ATA drive. They all use SCSI commands at their core the only real main difference between IDE & SCSI are the physical connecters used ... :)
Not true. IDE hard drives don't use SCSI commands at all. ATAPI devices such as optical drives use SCSI commands.
-
Not true. IDE hard drives don't use SCSI commands at all. ATAPI devices such as optical drives use SCSI commands.
I was about to say I've only ever written utils for ATAPI/EIDE DVD & CD drives which of course use SCSI (even though they are connect to the IDE port) commands and then say you are of course correct... :)
But, I have also written one piece of software for EIDE/IDE HDs for reading and writing the RDB block and this uses SCSI commands, so now I'll have to say your incorrect... :)
-
Get a 7200 RPM HDD with a reasonable cache and it will help the standard IDE.
-
I was about to say I've only ever written utils for ATAPI/EIDE DVD & CD drives which of course use SCSI (even though they are connect to the IDE port) commands and then say you are of course correct... :)
But, I have also written one piece of software for EIDE/IDE HDs for reading and writing the RDB block and this uses SCSI commands, so now I'll have to say your incorrect... :)
Nope. scsi.device includes limited emulation of some SCSI commands, so even though your program might be using SCSI commands, the hard drive isn't.
-
Nope. scsi.device includes limited emulation of some SCSI commands, so even though your program might be using SCSI commands, the hard drive isn't.
True... but the point is you still write the code using SCSI commands that the driver basically interprets into the correct hex values to send to the device. Also the later scsi.device Ver50+ covers virtually all the scsi commands needed for HD/Optical media and can hardly be called limited... :)
-
Get a 7200 RPM HDD with a reasonable cache and it will help the standard IDE.
How does a 5400RPM 8MB cache drive sound for that?
Though I'm not sure it would matter how fast of an HD it is, on my system. I seem to be getting only around 190KB/sec (502MB in somewhere around 45min.). An 030 should be getting around 2MB/sec. plus is what was said earlier in this thread. I don't think this is anything new with this HD though. I seem to remember my previous HD getting something around that poor of a speed too, I just didn't time it really or know what speed it should be getting. 2MB/sec. seems plenty fast to me, but 190KB/sec. sure doesn't. I wonder what could be slowing things down so much?