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.
I think one of the important points is how much clue is required for the setup of the two systems.
With firewire, you just plug the device in, and the firewire protocol details to broadcast, service announcements etc. As a user, no setup, no extra services required, the firewire devices work it all out for themselves.
With ethernet, presumably you're also going to use TCP/IP to address things, shift your data around etc. So, now you either need a dhcp server somewhere, or some manual configuration. Otherwise, how will this new device know what address space to talk on? Also, you then have issues with device discovery.
The result - end user stuff gets firewire, as you plug it into one machine and "it just works(tm)". Don't ask about sharing it though.. Meanwhile, your business oriented products come with ethernet and a proper IP stack, an IT guy with "some clue(tm)" configures it (as needed), and several people can use it at once.
So, whats missing for home use of ethernet and TCP/IP in all the devices? A standard, flexible resource discovery system (I know of a few in the works, none finished), and every home to have a NATing DHCPing DSL / cable modem router, so any boxes the user plugs in will be given an IP in the correct address space.
This post will enter the public domain 70 years after my death, unless Disney buys another extension.
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.
Try any recent pro-level macintosh, including the portables. They run 1000BaseT, and they use normal ethernet cables to do it.
Care about electronic freedom? Consider donating to the EFF!
Firewire and Ethernet have two very different applications and are designed accordingly. Do you want to give your external hard drives, digital cameras, and iPods IP addresses? Do you want to have to worry about firewalling & routing for you iPod? How would you coordinate the caches of two different machines using the same disk? If you don't want to do that, do you want to worry about some sort of locking mechanism for the disk, to prevent concurrent access?
Most importantly, just grow up. Silly benchmarks like bandwidth, clock speed, etc., are just useful for comparing objects IN THE SAME CLASS. Maybe /. will one day grow out of their "bandwidth/clockrate == penis size" mentality and actually worry about getting USEFUL PERFORMANCE out of their systems. Sheesh.
Care about electronic freedom? Consider donating to the EFF!
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.
There are similar stateless autoconfiguration stuff for IPv4, such as the Universal Plug-and-Play system that was being used by both Microsoft and Apple and is not being standardized by the zeroconf IETF working group.
The problem with IPv4 is of course that NAT or proxying still is needed for global connectivity.
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.
But the cisco phones don't use Gigabit ethernet(if they do thats a BIG waste, even if they had video). of the 8 wires in a cat5 cable, Giga uses all 8, whilst 100/10baseT use 4. So the phone uses other wires for power. With Gigabit, you woulnd't be able to do that.
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"
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.
Is contention negotiation (or whatever the correct term is) "built-in" to ethernet, or is it just a feature of a higher level protocol, like IP? What I'm talking about is the fact that ethernet is shared, and when multiple requests go out at the same time, each party "stands off" for some random amount of time before resending. I would think that this would absolutely KILL IO performance, as you don't want all your devices competing for the shared data channel. How is Firewire/USB/SCSI, etc in this respect?
It's 10 PM. Do you know if you're un-American?
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.
This feature is called CSMA/CD - Carrier Sense Multiple Access / Collision Detection. It is implemented at Layer 2 of the OSI model. This is not such a bad thing. It is used only when 3 or more nodes share the same physical cable - such as Thinnet. It was an efficient way to allow multiple machines to participate on a single wire. The other alternative at the time was token ring - which uses a multi station access unit (MSAU) to act as a "trafic light". While token ring worked well on larger networks (at 4-16mbps), csma/cd worked better in *looser* ethernet environments at 10 mbps. Today it is more common to wire each machine into a switch - this way there is no need for collision detection at all.
X
Latency is generally overwhelmingly caused by buffering of bits and far less by medium propagation delay. Of course, wire-speed latency matters in the design of CSMA/CD networks with regard to their maximum radius. However, as data rates go up, capacitive effects on NeXT and FeXT (near and far end cross-talk, basically not hearing the weak attentuated signal because your local transmission is so much STRONGER) appear to be the primary distance limiter.
You could've hired me.
Yes. A clue.
Gigabit ethernet has no way of powering external devices. Firewire does.
Firewire was designed for high-speed peripheral communication. Gigabit ethernet was designed for high-speed network communications. The only thing the two have in common is the modifier "high-speed". Another standard would need to be developed for peripheral communications over GigE (unless you want to add an IP stack to every digital camera and removeable CD-R drive out there, in which case you are smoking crack.)
Firewire is available on most new PCs now. Gigabit ethernet is not (please do not muddy the waters here, Mac users.)
Firewire is cheap. Gigabit ethernet is expensive.
Firewire peripherals are here in abundance. Gigabit ethernet peripherals exist in your head.
It seems that all you're talking about is putting an RJ45 port onto a machine for peripherals instead of a Firewire port. All this will do is cause people to plug their networking equipment into the wrong port.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Most new Cat5 cables is Cat5e, so it really doesn't apply, but you are right. Considering how picky I am I should have noticed that. Thanks ;-)