Mike wrote: > I thought that the UDMA/100 IDE interface was good for up > to 100MB/s which according to reviews is much faster than > the speed of the data coming off of the physical platters > within the disk drives Yes, the peak transfer rate of UDMA100 is 100MB/s. > (and that even the older UDMA/66 is fast enough (66 MB/s) > to be faster than the physical disk speed). Even UDMA33 is more than enough for 5400rpm drives. > To get faster, I've read that one just needs to get > faster (spin) disks with faster track access times > to get the overall speed up, so it's not the IDE > interface that's limiting factor, but the disk > "underneath". In terms of sustained transfer rates and not taking into account other factors like multitasking and CPU load, and provided that your computer really is running UDMA33(or 66 or 100) correctly. I did some research at http://www.storagereview.com and this appears to be true. > Because high-end systems use SCSI, the high end > fast-spin (> 7200 rpm) and fast access time disks > (< 8ms )are SCSI ones. So for really fast speed > one does need SCSI disks, but not because of the interface. Used to be true, but not any more. The seek times certainly seem generally shorter for SCSI drives, and the CPU utilisation of SCSI is lower than for IDE, but there's now 7200 and 10K rpm IDE drives. > There are some other theoretical advantages to SCSI > in a multi-user server application but I don't know > if they apply to the users in this newsgroup (not me anyway :-). Not just theoretical. SCSI multitasks better - and that would apply to single user multitasking as well as multi-user multitasking. There's other advantages in SCSI drive design which I don't fully understand myself - such as the ability to do multiple reads on a single disk rotation. In any case for the best speed, have your operating system on one physical drive and your data on a different physical drive (not just different logical partitions on the same physical drive). >P.S - Magazines like P.C. Magazine has done benchmarking of > servers using IDE vs SCSI disks, and I recall their > conclusions to be that they were very surprised to find > that it didn't make much difference in the actual system > performance. I'd have to read how they did the actual testing. It depends completely on the application. I look after an NT server which has the OS and applications on a mere 5400rpm IDE drive and the machine runs just fine - because it has heaps of RAM, and the disk intensive operations are no SCSI hard drives and CDROM drives. All our servers which support many users are built using SCSI RAID arrays for hot swap reliability. The arrays are also striped for speed. To try to bring this back to some relevence to film scanning, the only reason I'm talking about drive performance at all is that film scanners generate really big files which can't be cached by either the drive or the OS. Consequently it's the sustained transfer rate of the drive which will determine how long you have to twiddle your thumbs waiting for scans to load and save from apps like Photoshop or PSP. The bottom line is - for the fastest sustained transfer rates from an IDE drive, get the fastest rpm drive you can, and put it on a bus mastering interface preferably without any other device on the same cable. Use one physical drive for the OS and another for the data - that way the background operations of the OS won't interfere with the data transfer. If a single spindle doesn't give a fast enough transfer rate, only a striped RAID array will go faster (hence why I mentioned IDE RAID arrays elsewhere). Rob Rob Geraghty [EMAIL PROTECTED] http://wordweb.com
