Slashdot Mirror
Firewire or Gigabit Ethernet?
schvenk
asks: "Firewire (IEEE 1394) has been accepted as a standard for
peripherals, from hard drives to CD-RW drives to digital video cameras. It's
a 400 Mbps technology. At the same time, many machines are shipping
with Gigabit Ethernet, a 1000 Mbps equivalent of an more widely accepted
standard. I'm not a hardware guy, but at first glance it would seem more
efficient to eliminate Firewire altogether and equip peripherals with Ethernet
ports, ultimately moving all wired communication to a unified standard. Am I
missing something?"
Google found this:s _g bit.htm
http://www.unibrain.com/products/ieee-1394/fw_v
I would also like to point out the connectors. I would assume firewire was made partly as competition to usb. Thus it would be relatively easy to assume that firewire carries more current to power some lower powered devices.
Ethernet isn't designed to power anything. I imagine it only carries enough power to carry the signal for the distances involved.
Also comes into the cost of making hubs. With ethernet you must worry about ip addresses and routing all that information. I do not believe firewire would require this information to be dealt with in such a complicated matter.
So firewire is probably lower cost.
Regards,
Jeffrey Drake
What we see depends on mainly what we look for. -- John Lubbock Now search for that bug slave!
All of Apple's G4 towers ship with Gigabit ethernet. They've been coming this way for the past year and a half. Unfortunately, I've never had the opportunity to use mine.. It _does_ run over standard Cat-5, though.
"I'll say it again for the logic-impaired." -- Larry Wall.
IEEE 1394/FireWire/i.Link is a sucessor to serial connections and is prmarily designed for comminucation between devices and a single host. It has mechanisms to guarentee bandwith to individual devices but is generaly for one transfer at a time. Ethernet is a network primarily designed for communication between different hosts. It is designed so that multiple hosts can be communicating simultaniously. It would be possible to create devices that talk Ethernet, iSCSI springs to mind, but it would take some setup, a DHCP srever or fixed IP address etc. Firewire is plug'n'pray. Spirit
I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.....my life is my own.
Although Gigabit Ethernet is 1000Mbps in theory, in practice you don't usually get that kind of throughput -- so Firewire might not be all _that_ disadvantaged.
The basic reality is that you can _get_ cameras, hard drives, etc. with firewire ports while gigabit ports aren't readily available (if at all) on these sorts of 'consumer' devices. Will Gigabit supplant firewire? Maybe -- but why deprive yourself of the advantages of firewire for the next few years until it does (or doesn't) happen?
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
On the other hand, ARP, IP, UDP, and DHCP are all well-understood protocols so you might well decide to do it that way.
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
Ethernet cannot utilize nearly as much of it's available bandwith as SCSI (Firewire is essentially a serialized SCSI interface)
When ethernet utilization hits 50%, performance starts to crumble. SCSI can run up to the limit with little trouble.
This is why you see more large scale SAN's networked by Fibre Channel & SCSI rather than Ethernet (although ethernet models are appearing as well)
Conformity is the jailer of freedom and enemy of growth. -JFK
Another reason, besides all those already metnioned are that fiber is still kinda expensive (couple of quid per foot), and Gigabit over Cat-5 is a hack -- it has to use all 4 strands and send a parallel signal. And Cat-7... costlier then fiber.
Another reason is that Gigabit doesn't support QoS out of the box; you need a router type device to do that -- Firewire has that built into the protocol to make sure that your CD-R drive doesn't get an under-run even though you're editing video.
Still one more reason is comaring the cost of Firewire hubs versus Gigabit hubs. A 4+1 IEEE 1394 hub will run you about $45 USD, while a 5+1 Gigabit ethernet port (over cat-5) will run well over $100 (according the minimal research I've done).
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
You could have the rest of the bandwidth allocated to asynchronous communication that could experience congestion while you're watching hiccup-free video through the guaranteed part.
Ethernet doesn't have a guaranteed throughput, so eventually as traffic builds up you'll get glitches in delivery rates, which you will have to compensate for by big buffers and hence bufferLength/rate delays. If I were writing a video editing app, I think I'd rather be able to assume guaranteed synchronous delivery over the links. For the same reasons, you want a real-time capable OS, to make things easier in that part of the problem. Again, though, if you crank up the speed, like with gigabit ethernet, a non-real-time OS can do pretty well (especially if you dedicate the machine while running the one app), even though it's not really guaranteeing throughput.
Gigabit Ethernet doesn't just run over Fiber, it runs over CAT5 as well. Gigabit ethernet is a layer 2 standard, so it can theoretically go over any transmission medium, but I don't think it would be practical to use it over anything but cat 5 and fiber
Actually, Ethernet is now being revised to provide power over two of Cat 5's four pairs. It's called 802.3af and you can find information about it here
Currently, Cisco is making wireless 802.11b hubs with Inline Power over the Ethernet cable. The wireless hub will need only one physical wire cable to provide both power and network connectivity.
I believe that main issue with GEthernet is that the FireWire protocol was meant to control devices and so does bus arbitration and such, and that the Ethernet protocol (with its CSMA/CD for dealing with collisions of packets, collisions being something you wouldn't want in FireWire) deals more with non-deterministic network access.
Now a token-based FireWire would be something else. Deterministic access that could scale. One of my favorite networking quotes is, "Ethernet works in practice, but not in theory"
The reason that FireWire was developed (and I believe it was begun before USB development was begun) was a need for a simple, hot-swapable bus which would allow different kinds of digital devices to connect together with a trivial 'plug it in an forget it' user operation. The team behind the development included Apple, which had for years used a high speed serial bus for networking (AppleTalk over LocalTalk) and a lower speed serial bus (Apple Desktop Bus) for connecting a variety of peripherals, including keyboards and mice. The original use for firewire on Apple computers was (I believe) going to replace all serial devices with this one bus. Then a second team, lead I believe by IBM developed USB as a replacement for the serial ports and the PS2 style keyboard/mouse interfaces. USB does not have the device density per port that FireWire has. The system was NOT intended to allow high speed transfer of large volumes of information. FireWire was targeted at DV cameras, Digital Cameras, consumer electronics, etc. USB was going to connect low-bandwith serial devices. FireWire can string an extremely large number of devices on one serial chain. FireWire was intended to be universal.
Then USB took off becuase of the marketing muscle of the consortium behind it, the lower cost and the inclusion of USB on most PC motherboards. Apple decided not to release a FireWire only set of machines and instead began using USB for keybords and mice (cost savings, compatibility) and to allow for access to the increasing number of USB consumer devices. But, USB was still 40 times slower than FireWire (which is the IEEE 1394 standard) and so FireWire (or iLink as Sony branded it) was included for uses that Apples had relied on SCSI for like connecting scanners, removeable media and other devices which you may add or remove from time to time and require reasonoble bandwidth. It still wanted FireWire for connecting to FireWire consumer devices too. SCSI still has a place as well, but not everybody needs SCSI now that IDE has been improved (it was really lousy to begin with) and that FireWire could be used for expansion of capacity for average users. SCSI still has much higher bandwidth capacities and burst capacities. Servers and video editors will still use SCSI. Likewise, Ethernet was intented for asyncronise networking. Yet a different purpose. Ethernet uses a convoluted (but useful for its purpose) networking model in the common TCP/IP application with at least hardware, protocol and session layers which must be negotiated and maintained. Normally, you only see about 60% of the theoritical maximum capacity. So while Gigabit ethernet is good for networking, it is not necessarily appropriate for the purposes FireWire was intended. Think: what is the intended purpose for BlueTooth versus 802.11b? Design criteria matter: e.g. BlueTooth uses many times less power but is intended for short small communications needs; FireWire can provide power to devices (like my iPod) and Gigbit Ethernet cannot. In most cases, having too few standards and too few options is just as bad as having too many options and no standards. Choose the standard which makes sense for your application.
ethernet sends things in tiny unreliable frames meant to be dropped on the floor every now and again, needing to be painfully reassembled into larger useful blocks of data at each end.
firewire is a bus meant to reliably transfer large amounts of data at a time directly between devices and system memory with very low overhead. 'nuf said.
(and to the person who suggests that power supply is the only reason, there are power over cat5+ ethernet solutions using the other two unused pairs of cable)
As for "killing performance", random transmissions with a truncated exponential random backoff time (collsision? wait a random time within an interval, try again... collision? wait a random time within double the interval, try again...) approaches 67% line utilization as the number of transmitters grows to infinity. Without collision detection, you get half that.
So, yeah, it kills performance, but only in the sense that you're trying to saturate the pipe anyway.
All this is really moot today, because so much ethernet, even 100BaseT, is switched and not just "hubbed".
You could've hired me.
Yeah, that's a pretty common situation: manage a bunch of servers and their storage with a SAN and use NFS or SMB or AppleShare to get the data to the desktop.
The big problem with SANs is scalability. Fibre Channel ports on an FC switch are very expensive compared to Ethernet ports on a network switch. Also, if you have 10 clients hitting the same storage system, it tends to thrash pretty inefficiently. Connecting the same storage system to one server means all access to that storage goes through the server's I/O buffers.
This, of course, doesn't even get in to the problems of SAN token passing and file access arbitration. Computers on a SAN act as a tightly coupled cluster; daemons on each server communicate with all the others to prevent any two servers from trying to write to the same disk blocks at the same time. Extending that architecture to dozens or hundreds (or more!) clients is challenging, to say the least.
So running FC straight to the desktop wouldn't be a great idea in most cases.
Taking Ethernet to the storage is a different idea entirely. The idea is called iSCSI, and it involves running SCSI protocols on top of TCP, so clients can access disks over the low-cost Ethernet network. It requires special drivers for your OS that present the iSCSI interface to the OS like a SCSI device, and that encapsulate the SCSI commands sent by the OS and user space programs inside a TCP connection to a storage device on the other end.
iSCSI storage systems must have some kind of a computer (usually embedded) that control them; in the case of IBM's iSCSI product, it's a Pentium III running Linux. In this way, iSCSI devices aren't very different from NAS devices; only the protocol for communicating with the client is different.
The thing that's great about servers, though, is that they can do more than just provide file services. They can provide storage management and backup, and run applications. When compared with a big enterprise-wide server cluster that provides databases and file services and backup and HSM and whatever else, iSCSI appliances seem kinda primitive.
There's more info on iSCSI on IBM's web site.
So, to sum up, it sounds like the way things are in your network is a pretty good way of doing things.