|
|
|
Lashiec
|
 |
« Reply #1 on: December 17, 2007, 06:43:10 PM » |
|
Actually, IEEE 1394 new standard is late, as the USB 3.0 was announced in Intel's last IDF. And it's set to achieve even faster speeds than the new FireWire. Which poses the question as if the HDDs can keep up with this or, more precisely, if everything will be wasted bandwidth, considering that the eSATA can achieve theoretical speeds closer to those of SATA II HDDs. I'm sure the new specifications will be used for some bandwidth-demanding applications (like HD video). (already mentioned by Carol, gosh!  ) |
|
|
|
« Last Edit: December 17, 2007, 06:52:41 PM by Lashiec »
|
Logged
|
|
|
|
|
f0dder
|
|
« Reply #2 on: December 17, 2007, 06:50:13 PM » |
|
* f0dder yawns. Anyway, from everything I've seen, firewire has an advantage over USB in that it's better able to dedicate bandwidth to one high-speed device; so firewire-400 beats usb2-480. Btw, individual disks still can't even saturate SATA-150, so SATA-300 speed only matters once you go RAID... and even then, it's only for the controller, not the individual drives, that it matters. |
|
|
|
|
Logged
|
 - carpe noctem |
|
|
|
|
Carol Haynes
|
|
« Reply #3 on: December 18, 2007, 02:48:35 AM » |
|
The other advantage of Firewire is that it can supply more power to devices directly.
|
|
|
|
|
Logged
|
|
|
|
|
tomos
|
|
« Reply #4 on: December 18, 2007, 03:19:18 AM » |
|
but over the last couple of years I've read again and again (but where  ) that firewire is not as dependable as USB |
|
|
|
|
Logged
|
|
|
|
|
f0dder
|
|
« Reply #5 on: December 18, 2007, 06:36:36 AM » |
|
but over the last couple of years I've read again and again (but where ) that firewire is not as dependable as USB Hm, never heard anything like that... the only firewire problem that I know of (and have been bitten by!) is that some bridge chips used in external HDD enclosures were buggy, and would report it's own max transfer size instead of asking the harddrive and returning the smaller of the two, ultimately resulting in "Delay Write Failures" and data corruption. Google for "firewire filter driver". |
|
|
|
|
Logged
|
- carpe noctem |
|
|
|
tomos
|
|
« Reply #6 on: December 18, 2007, 06:42:40 AM » |
|
... ultimately resulting in "Delay Write Failures" and data corruption. Google for "firewire filter driver". it *was* in connection with external drives that I read it and the words "data corruption" were used so maybe same problem - it was enough to put me off at the time (never did get an external HDD enclosure anyways so...) |
|
|
|
|
Logged
|
|
|
|
|
f0dder
|
|
« Reply #7 on: December 18, 2007, 06:48:14 AM » |
|
... ultimately resulting in "Delay Write Failures" and data corruption. Google for "firewire filter driver". it *was* in connection with external drives that I read it and the words "data corruption" were used so maybe same problem - it was enough to put me off at the time (never did get an external HDD enclosure anyways so...) Yeah well, that wasn't the fault of FireWire itself but some lame bridging chips, and can be solved with the help of a filter driver (I even think MS ended up providing one?). FireWire-400 was faster (even on my enclosure with buggy bridging chip + filter driver) than USB2-480. |
|
|
|
|
Logged
|
- carpe noctem |
|
|
|
Ralf Maximus
|
|
« Reply #8 on: December 18, 2007, 08:42:09 AM » |
|
I've heard the primary reason Firewire beats USB on these tests is that USB incurs more overhead per data packet. When copying files this translates into a clear win for big files over Firewire, but similar performance when copying zillions of tiny files.
Any truth to this?
|
|
|
|
|
Logged
|
|
|
|
|
f0dder
|
|
« Reply #9 on: December 18, 2007, 08:55:10 AM » |
|
No idea, haven't tested it  |
|
|
|
|
Logged
|
- carpe noctem |
|
|
|
Ralf Maximus
|
|
« Reply #10 on: December 18, 2007, 09:11:47 AM » |
|
I've got a firewire/usb drive cage with a 100GB drive in it I use for fixing computers, and I have noticed that firewire transfers large disk images significantly faster than usb.
But -- all things are not equal. The target machines are not evenly matched, and so I don't consider this a good test. Nor do I have the patience to transfer 50 GB files around with a stopwatch just to see if it really is 25% faster or whatever.
|
|
|
|
|
Logged
|
|
|
|
|
