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!
I haven't seen a machine with a gigabit port, unless you're referring to some of the larger scale servers that are out there that require that amount of bandwidth capacity. As for why not just transition to gigabit and skip the firewire, I believe it comes down to cost. The gigabit setup is quite expensive. Go to radio shack to buy an optical cable and it'll run you $20 dollars. Gigabit ethernet uses the same media as optical cable. I'm sure there's a price issue even in the hardware that connects it all together as well.
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.
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.
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.
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.
While what you say is some what accurate it is not entirely correct. The fact is that most ethernet applications today are switched. This in combination with Full-Duplex eliminates collisions, at least in theory. In any case, a switched 1000-BaseT installation will far out pace firewire and equal the highest SCSI speeds. This assumes that your motherboard architecture is capable of driving these speeds, in the first place.
In properly configured Gig-Ethernet installations the links can easily run at near 100% utilization. The thing that sets it appart from SCSI is the distance. 1000-BaseT is good for 100 meters, 1000-BaseLX is good for 10 - 100Kilometers.
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.
QOS and traffic shaping are used to provide the guarantees that you refer to over Ethernet. They allow for the dynamic allocation of bandwidth to the specified applications. Therefore, you do get uninterrupted video and voice feeds even if the pipe is shared with http or ftp or, god help us all, NetBeui/NetBios.
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.
I believe 1394b allows up to 800Mbs over their standard cable. Obviously it depends on the ability of the hosts. I also seem to remember something about 3.2Gbs firewire over fiber. With that sort of rate and guarunteed bandwith for transfers firewire is much more suitable for consumer applications that 1000baseT
There have been a number of insightful or informative posts on this thread such as firewire roughly being serialized SCSI (true)or bandwidth management of Ethernet being poor compared to Ethernet. There was a sub post about firewire and USB being able to power devices where Ethernet can't. This is partly true but Power-over-Ethernet is a reality as well since Lucent and Symbol offer it in some access points.
There also is a clustering technology for SMTP from an Italian university( the name and link escape me) that uses a modified IP stack for the nodes to communicate on using standard Ethernet equipment. The controlling node also has a NIC the uses "real" IP on Ethernet to talk to the world/Internet. Using something like the modified IP stack would allow you to control and manage devices for storage, etc., without having to manage firewalling separate from how you do it otherwise(another post talked about the horrors of, say, assigning an IP to your iPod) since it isn't capable of talking to the world.
There would probably be a need for a slight alteration to talk this modified IP (maybe not) for dhcpd to manage devices. Use some of your own paramaters to pass to the clients (storage devices, etc.) for setting up arrays or what have you or use some mod of SNMP for management or both.
Power the devices with the aforementioned Power-over-Ethernet from the Ethernet switch. This switch would not be your usual off the shelf switch but if a vendor were selling this sort of offering, naturally they have them made up.
So what if the bandwidth management isn't as good as serialized SCSI -- there should be less effort to repurposing existing work and in some cases probably not having to reengineer any software.
Before someone says, "hey, look, here's another Linux geek wanting to install it on his toaster", stop and think about it. Embedded software on remote devices communicating over Ethernet and passing data that cannot be DOS'd (use multiple gateways plus the storage network stays up since it isn't directly attacked) but can be managed by any PC you want: add another NIC to it, bind it to the modified IP stack, feed it unpowered Ethernet and uses your management apps/edit .conf files.
Like my subject, I think this is a potentially elegant solution.
This looks really doable
First, a number of posters seem to be confusing Ethernet (a Layer 2 technology - datalink) with TCP/IP (a layer 3+ technology). IP CAN run over Ethernet, just as ATM, Appletalk, IPX, and many other protocols can. .... as that's a whole 'nother story ;)
Second, as has been mentioned, 1000BaseTX/FX doesn't really mean you GET 1000Mbps...a rule of thumb with any ethernet device is you get approx. 1/4 of the available bandwith. Now, something to consider is the fact that this rule of thumb and common practice is for NETWORKS, with multiple people on one segment (even if it's switched, blah blah blah). If you have a dedicated transciever pair of 1000BaseX transmitters, talking over a dedicated cable, you could probably get as close to the 1Gbps that the PCI bus would allow.
Another poster (the top rated one ATM) mentioned the voltages carried over the bus. Unfortunately, he's off on that one....Ethernet can easily carry more voltage..in fact, whole product lines are devoted to PoE (Power over Ethernet). Just look at any business IP telephone...they grab their operating voltage straight off the network cable. The only issue with this, is any switch you have in a rack that services these PoE devices needs a PoE converter on it (to enable a standard ethernet switch to handle more than 12V DC). So even sending power over it is just great.
But when it all comes down to it...Ethernet is not the answer for dedicated connections...one of the big reasons behind ethernet's popularity is CSMA/CD (Which is kinda obsolete in a Dual-Simplex/Full duplex world). This allows many, many devices to automatically share a line, and transmit...while making sure everything eventually gets thru. There is a lot of overhead involved in these kinds of transmissions that are totally pointless on a PCI bus extension (where everything has it's own channel anyway).
Now, I don't see why they can't just make a 1Gbps firewire transciever
Firewire has advantages that make it more suitable for the applications it was designed for. It uses a pair of wires up to 14 feet in length. This is much thinner that an 8 wire cat-5 cable -which 1000base-t requires. It also supports isosyncronous mode - which enables the quality of the data stream to be adjusted to ensure that the data is delivered on time.
There seems to be some confusion about Gigabit Ethernet in some of the posts here. Gigabit Ethernet is a datalink layer protocol(OSI layer 2). It specifies how data should be sent accross the physical layer(OSI layer 1). There are several different standards for Gigabit ethernet depending on the physical media it is to be used with. Cat-5 describes the implementation of the 8 wire cable used.
When making a point to point connection (with 100base-t) the throughput actually doubles to 200Mbps! This is becuase there is no need for collision detction and then the devices can connect in full-duplex mode.
For Cat-5 cabeling to be utilized as suggested, one need not implement the layer 2 implementation verbatim - a streamlined media access layer could be designed for this purpose. Also, IP(internet protocol - OSI layer 3) would not be implemented at all as it is not necessary since we are going from point to point.
X
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.
For Macintosh users, this is not an either/or choice.
Each and every single Power Macintosh G4 (towers) have had 1000Base-T ethernet standard out of the box since JULY 2000. Bottom-feeder models as well as top-of-the line.
Gigabit Ethernet has been standard on all Titanium PowerBook laptops since they were first introduced.
Each and every single Apple ---portable, desktop, or MP3 player--- has FireWire (IEEE 1394), and most machines feature two or more FireWire ports. My December 1999 G4 has three FireWire ports.
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?
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)
I've thought about this before, and the main problem I keep coming up with is the cost issue. So I ask this as a question: how much does it cost to have hardware perform ethernet layer 2 vs. firewire layer 2? I would imagine ethernet is more expensive, due to its intended use in machines with processors, but it's just a total guess (I'm also not a hardware guy).
Otherwise I'd say go for it. Gigabit ethernet can surely support just about any add-on other than monitors and ram. I'd love to be able to just plug in anything I buy for my computer to my ethernet switch. For those consumers too scared to open their machines it's an even better accomplishment.
Besided all the Technical differences between GigaBit eathernet and Firewire. It is also makes it easier for people to visualize where to install hardware. There is a GigaBit Eathernet Card. And it is still the same size and shape as a 10/100mbs Eathernet slot. In my mind that is soposed to be used for Computer Networking. The VGA Monitor plug 3 rows of pins and female connector on the system. It tells me that is where the monitor goes. Serial is a male connector and Parallel is a Female Connector. Plug external modem into the Serial and Printer into Parallel. USB are those flat slots and firewire is that funny inverted house shape. If they had all the inputs as a Ethernet connection it would become more difficult to plug you system in. Port 1 is for network Port 2 is for Scanner, Port 3 is for Monitor, etc. It makes it harder to remember where to put things in. I always confuse wich port I Plug in the speaker and the Mic in. And programming/configing a system with 1 universal protocal can get trickier. Espectly with eathernet which is a old protocal just faster. Even if everything did work. I like concept of plugging in the right program for the right spot.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Anyone have specs on the latency of firewire vs. ethernet? I'd imagine firewire has a lower latency, since the maximum distances are shorter.
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
... Ethernet's just a method for sending packets between two nodes, given that you know their MAC addresses. That's all the protocol provides you with, everything else has to be layered on top
/constant/ data rate between two points. Ethernet and even TCP/IP just doesnt have that. I'm no great expert on firewire but firewire's firewire and ethernet's ethernet. Both have relative merits.
On the other hand, Firewire has some USB-like features like device identification, device power supply, and is also better than USB because you dont need a computer in there to drive the system (you could hook a printer directly to a camera without any proprietary interfaces) and the actual protocol is different... for instance there's an isochronous transfer mode which guarantees a
Anyone remember the story about Gibson guitars using Ethernet cable? This is a similar step towards unification, and shows that the idea is valid even in non-computer-related areas.
Given two computers, each with a firewire port, neither with a NIC, how feasible is it to share files between the two computers?
Also, while we're on the topic of CAT5 cable, what is this new garbage I see at the stores called CAT6, and should anyone waste their money on it, considering the 1000BaseT runs over Cat5e?
Firewire vs GigE is not realy a very usefull comparison. They are targeted at very different markets. Firewire (IEEE 1394, iLink, whatever you call it) has gained ground in the consumer electonics and digital video market. The one area where the two overlap is in storage. Currently there are several Firewire storage devices available (external hard drives). Ethernet is going to gain some of that market with iSCSI.
Firewire and USB 2.0 are going to fight it out on the desktop. They both have about the same speed and both have a strong install base (Firewire with Apple and Sony products and USB with legacy 1.0 devices). Firewire is going to hold on to its nitch in the audio-visual market and some high speed apps with its IEEE 1394b speed boost. USB is going to remain king of keybord and mouse type devices due to lower cost.
The integration outlook is better in the data networking space. GigE and 10GigE are looking to replace the gaggle of layer1/layer2 solutions out there. That would include ATM, Frame Relay, Fiber Channel, Packet over SONET, etc.
... for Macintosh users.
Every single G4 tower since July 2000 are Gigabit Ethernet. All Titanium PowerBooks are Gigabit Ethernet since these were first introduced.
All Apple devices ---desktops, laptops, MP3 players--- feature two, one, or three FireWire ports.
After reading the many posts this has generated - I am amazed at the amount of misleading or just plain wrong information. There is lots of very good info too.
One thing I had not seen discussed was how FireWire and USB allow you to reserve bandwidth - and I'm not talking RSVP here but actual real to god ok it is your time slot to use the bus - no one will interupt you.
It is doable and currently for my summer job between college semesters I installed ID card access door locks. There we used Cat 5 ethernet cables, 2 to power the card reader, 3 to transmit data to the box reciever, and 2 more the power the bolt lock to release.
Also current network 10 base T cards don't even use all 8 wires of the Cat 5, they only use/need 4 (if you ever bought a Linksys Card with included cable, the cable only has 4 wires). Now I'm not sure if Gigabit Ether is the same way (being 4 wires only) but if needed, cards or new standards could be created to incoorperated a current to be transmitted thru the cable.
Ethernet is an unarbitrated broadcast-type link-layer. Its ideal for running packetised networks that dont have concrete service levels and can accommodate packetloss and collisions.
IEEE1394 is an arbitrated, virtual channel (either fixed, or on demand) link layer that has its own integrated protocols for data transport. It can also provide power on the same lead, and is ideal for devices that need to arbitrate a fixed bandwidth connection to specific host devices. Great for peripherals.
Google, is a very popular and efficient search engine that can find you most any information on the internet rapidly. Clueless people are not a bad thing per-se, as long as they accept that one should use the right tool, for the right job, and that the ability to educate yourself without whining to people on forums for help is a handy ability to have on the internet nowdays. Yet another "cant use Google" Ask Slashdot. (Go on, burn my lousy 1 karma for saying the truth.)
Anyone who considers arithmetical methods of producing random numbers is, of course, in a state of sin.-John von Neumann
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?"
I haven't done it myself but you can hook them up through a firewire hub. Probably even directly via a firewire cable. No need for a "crossover" since IEEE 1394 is self-negotiating. Windows XP sees an IEEE 1394 port as a network connection. It works pretty well, I'm told. I don't know how Win9x/ME handle this though. To answer your question about CAT6, it's just the successor to CAT5. CAT5e was developed to bridge the gap between CAT5 and CAT6, which wasn't quite ready yet. Kind of like this 2.5G stuff for cell phones we're hearing about because they can't get 3G out the door yet.
I prefer a void in conversation to a vacuous one.