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!
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.
Oh, you are going to get so flamed for this. Just comparing FireWire and Gig E in this way means that you must fundamentally misunderstand one or both of them.
Your life would have been so much easier if you'd just said:
"I'm not a hardware guy, but at first glance it would seem more efficient to eliminate Firewire altogether and equip peripherals with Fibre Channel ports, ultimately moving all wired communication to a unified standard. Am I missing something?"
Then we could have an intelligent discussion about crosstalk and carrying power and data on the same cable. As it is, you're just going to get things thrown at you.
So very close.
1) Applications. Ethernet was designed as a shared medium to support arbitrary contentious traffic framed in a simple data link layer, sent between relatively distinct systems. It is intentionally a small, simple spec. Firewire was designed to provide connectivity to high-bandwidth, real-time traffic in a local environmment. Firewire therefore supports notions of bandwidth reservation, and was initially geared to short-haul distances (i.e. on the desktop, or in a small equipment rack). It is a more detailed and involved spec because of an intended techno-ignorant consumer audience -- plug things in and they work.
2) Power. While PoE (Power over Ethernet) is gaining steam, driven mostly by the notions of IP telephones and other networked devices without local power, ethernet generally does not carry power. Firewire can, to simplify cabling.
3) Bleedingedgeedness. Firewire was bleeding edge. In order to be cost-effective at some level, compromises were made. Initial distance limitations (on copper) were severe. It was bandwidth at all costs. Even today, firewire does not strike me as effective for long distances (need for fibre vs. copper). GigE took longer to develop because of the need to work at extended distances (100m being the traditional ethernet radius), with a copper physical plant, and the lack of comsumer device pull. It also had legacy inertia to deal with.
In my mind, the biggest difference, though, is the nature of the intended traffic: Firewire addresses bandwidth reservation, and ethernet doesn't. To be sure, one can layer the necessary protocols over ethernet to do this, but then ALL the traffic has to be managed outside the ethernet spec. to honour those protocols. Firewire has the promise to be a micro-local, cheap, real-time networking solution. Ethernet addresses longer distance needs with a diversity of traffic types.
You could've hired me.
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"
If the trojan machine is sitting on the local network, it can do all kinds of bad things anyway - such as flooding the network with random data. In general, it is impossible to guard against "bad" hosts on the local network.
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.
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.
The painful reassembly part is generally a higher-level protocol function, done by IP, as in "fragment reassembly". Of course, even these reassembled packets may need further aggregation as part of a stream of data... enter TCP (which provides retransmission for lost packets as well).
You could've hired me.