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?"

Comments

Well...

[jpt.d]

Google found this:
http://www.unibrain.com/products/ieee-1394/fw_vs _g bit.htm

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

Re:Well...

[Paranoid]

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.

Firewire and USB both have the option of powering their peripheral devices. I'm not sure about USB, but with firewire, this is not a requirement. I've yet to find a firewire CardBus card which does supply power. I know the iPod requires a power supply to actually realize its plugged into a host, though.

Ethernet isn't designed to power anything. I imagine it only carries enough power to carry the signal for the distances involved.

There are also standards for providing power over ethernet. But thats 10BaseT and 100BaseTX. It works by providing power over another set of wires, since those two standards only use 4 of the 8 conductors in CAT5. 1000BaseT makes full use of all 8 conductors, making this unfeasable.

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.

Ethernet hubs don't have to care about anything, they just rebroadcast. Ethernet switches don't care about anything past the MAC addresses in the frame header. Only IP routers care about IP addresses, subnets, etc. Thats OSI layer 3. Hubs and switches operate below all of that, which is why you can run things like IPv6 and IPX on your network without having to go buy a new hub.

Firewire hubs act like ethernet switches do, they route information between firewire hosts based on firewire addresses. They're similarly uncomplicated.

If gigabit ethernet is becoming common in consumer devices, this is great, because prices will finally come down. Gigabit has typically been non-cost-effective. Firewire has been a consumer product all along, and although its mostly had its market stolen away by USB (for the same reason 10BaseT devices are still common: performance is "good enough" and the price blows the competition away), it still has a lower price point than gigabit has in the past. I hope this changes, but I think its still a bit overrated given that most commodity OS's I've seen can't even come up with enough raw data to come anywhere near filling this big a pipe.

Ethernet != IP

[john@iastate.edu]

With ethernet you must worry about ip addresses and routing all that information.

IP is just the most popular protocol layered on top of ethernet -- if you were using ethernet to talk to disk drives for example, there is no reason you would *have* to use IP -- you could just talk to them directly via their MAC-addresses or layer some other protocol on top of ethernet.

On the other hand, ARP, IP, UDP, and DHCP are all well-understood protocols so you might well decide to do it that way.

Collisions

[duffbeer703]

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)

Couple other reasons

[Xunker]

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).

Firewire vs. GigE

[renehollan]

While the prospect of a single universal physical network layer is appealing, here are some realities that interfere with this.

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.

Fundemental differences in design criteria!

[depeche]

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.

Re:Contention

[renehollan]

It's built into ethernet as in 10BaseT and 100BaseT, but not GigE (1000baseT).

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".

Re:You mean "FireWire or Fibre Channel," right?

[foobar104]

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.