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?"
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.
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.
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
---blockquoth
/. will one day grow out of their "bandwidth/clockrate == penis size" mentality and actually worry about getting USEFUL PERFORMANCE out of their systems. Sheesh.
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?
---snip
Just a quick question, but why would you assume TCP to be the layer 3 protocol of choice?
The question was "why not Ethernet instead of Firewire", not "let's use TCP/IP". Besides that, even the "problems" you show would not be hard to fix.
---snip
Most importantly, just grow up. Silly benchmarks like bandwidth, clock speed, etc., are just useful for comparing objects IN THE SAME CLASS. Maybe
---snip
whoa, calm down. _Point to Point_ Gigabit Ethernet in the real world is significantly faster than the current latest addition to ieee 1394, and that performance would be useful to me right now, and I'm sure others. In the near future, this extra speed will be useful performance to many more people (HDTV video capture from a camera and back out to an external drive perhaps?).
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.
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