firewire drives...does it really work ?

[flohri]

Hi there,

i plan to get an external firewire
audiodrive...
is it really better ( faster ) than an ide-drive ?
if yes, any idea, what would be the best drive ?

thanks

[Allen Hallada]

I would think that with the same hard drive the firewire would outperform the IDE in most situations. I would get the WD 80GB 8MB cache or IBM 180GXP 120GB 8MB cache drive and put it in either an external or internal firewire enclosure like the ADS Pyro drive enclosure I listed on the "Best System for PTLE" thread.
Allen [img]images/icons/wink.gif[/img]

[where02190]

Internal IDE/ATA drives are faser than firewire. A firewire drive is an IDE/ATA drive in a firewire enclosure.

Firewire drives do perform very well with Protools. we hav ebeen using this very nice hfiresire dock system, which allows multiple drives to use one set of fw electronics. Infinitely expandable, very economical, and max efficiency.

Hope this is helpful.

[Allen Hallada]

Originally posted by where02190:
Internal IDE/ATA drives are faser than firewire. A firewire drive is an IDE/ATA drive in a firewire enclosure.

Firewire drives do perform very well with Protools. we hav ebeen using this very nice hfiresire dock system, which allows multiple drives to use one set of fw electronics. Infinitely expandable, very economical, and max efficiency.

<font size="2" face="Verdana, Arial">Where,
Are you sure about this? We have had a few PC users get much better track counts using the external firewire enclosures.
Allen [img]images/icons/wink.gif[/img]

[jacko32]

would it be worth it to look into getting a firewire drive that was faster than 7200 rpm?

[kCmCg]

If you find a FW drive faster than 7200 I would like to get one for myself. In fact BOTH IDE (100/133) and 1394 are faster than any standard HDD physically is. the transfer speeds on FW are higher than IDE, true.. but in both of these the HDD itself becomes the bottle neck. Perhaps people are getting better track counts on ext. 1394 cuz its on a dedicated channel? Duno..could just be speaking out of my arse.

[timtraynor]

Yes
[img]images/icons/shocked.gif[/img] [img]images/icons/rolleyes.gif[/img] [img]images/icons/smile.gif[/img] [img]images/icons/grin.gif[/img]

[Barhab]

Maxtor has made an IDE-drive with 8 mb cache. Maybe not as convenient as firewire, but 8 mb cache should not be a reason to go for a firewire drive.

[Allen Hallada]

If I were putting together an external firewire enclosure I'd get the WD 80GB 8MB cache drive and stick it in one of those ADS Pyro drive enclosures I have listed on the "Best System" thread. I wish I knew the answer to why we are getting better track counts with certain firewire drive setups, but I don't know why. It has to be something with the controller efficiency as both firewire and IDE operate off the southbridge controller and we all know how bad the VIA southbridge controllers have performed in the past. Just look at what adding a seperate Promise controller card has done.
Would I operate my audio drive off a sole external firewire drive? Only if I backed my sessions up to the system drive or another hard drive after every session. The best part is you have all your session with you where ever you take your drive.
Allen [img]images/icons/wink.gif[/img]

[Allen Hallada]

Ok, I got an answer to the 1394 vs. IDE issue from the hard drive guru of the DUC. (Name to be witheld from public disclosure but the old timers will know who it is) Enjoy!

IDE disks do not support queuing, meaning they can only handle one command
at a time. This means while you are seeking across the disk to read one
block of data, you cannot even tell the IDE drive what the next block is you
want to read. They just go in the command order with EIDE. So for EIDE
systems, it has to completely finish getting the first little bit of audio
before it can tell the drive about the second bit of audio that it needs.

With 1394, command queuing is supported. The PC can send multiple commands
(8 with the Oxford chip?) to the 1394 drive. The 1394 drive can then decide
which one it can get first, and what order to go get the data. This queuing
allows the Firewire bus to be sending data while the drive is seeking for
the next block. The data can be sent back out-of-order, but actually sooner.

HOWEVER!!! Remember that 400Mb 1394 reaches a normal limit on 1394 bus speed
of about 40-44MB/S best case. I own a WD 80GB 8MB cache drive in my Linux
recording system and get 45MB/S from Linux's disk tests, so in RAW speed,
EIDE will look faster, but with command queuing and random seekign around
the drive 1394 can be faster.

Command queuing is the main reason SCSI drives are 'faster' than IDE, even
when you normalize for rotationaly speeds, etc.

Also, don't forget that most of us early 1394 guys (Basstard, myself and
others) knew we could get more effeciency by using larger block sizes. (32K
instead of 4K) This could effect different people doing a dave_c test if
they are not careful to compare apples to apples.

<font size="2" face="Verdana, Arial">Well there you have it folks.

Allen [img]images/icons/grin.gif[/img]