Slashdot Mirror
Corporate Data Centers As Ethernet's Next Frontier
alphadogg writes with a story that's about the possibilities for the next generation(s) of Ethernet, stuff far beyond 10base-T: "Ethernet has conquered much of the network world and is now headed deep into the data center to handle everything from storage to LAN to high-performance computing applications. Cisco, IBM and other big names are behind standards efforts, and while there is some dispute over exactly what to call this technology, vendors seem to be moving ahead with it, and it's already showing up in pre-standard products. 'I don't see any show-stoppers here — it's just time,' says one network equipment-maker rep. 'This is just another evolutionary step. Ethernet worked great for mundane or typical applications — now we're getting to time-sensitive applications and we need to have a little bit more congestion control in there.'"
"Ethernet has conquered much of the network world and is now headed deep into the data center to handle everything from storage to LAN to high-performance computing applications."
Ethernet? Used for LAN? Jeepers, who'd ever have though of using Ethernet for THAT! I bet it'll be much faster than my 300-baud modem! And we can even connect storage devices to it!
And to make it easy we could call it "TokenRing".
Or maybe a token passing bus! Maybe call it "ARCnet".
Seriously, if there are problems with Ethernet ... for the usage you envision ... don't try to change Ethernet.
You take the parts you want from Ethernet and you create a NEW standard with the other features you want.
But you leave Ethernet as Ethernet. That way there is no confusion.
No.
Ethernet uses collision detection and resending to to manage packets.
Well it used to anyway. I am not sure about Giga-E
The way Ethernet used to work is that a sender would listen to see if the line was clear and then send a packet and listen at the same time. If the packet was damaged by a collision the sender would wait a random amount of time and then try to resend.
This system really bugged a lot of people but it was cheap and it worked.
This is the actually physical layer and not TCP/IP.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
No, they want Ethernet as a transport to contain a lot of the features of TCP so that they can lay their own protocols on top of it while being able to assume it's a reliable transport. That will increase the cost of ethernet by including that intelligence down the stack. Basically the cost of ethernet ports is plummeting compared to things like fiberchannel due to economies of scale and so cash strapped datacenters are trying to use it for everything, but it's not ideally designed to handle those other protocols so the other technology areas are trying to mold ethernet to meet their needs. Basically the way I see it if the industry does what is right there will be no 100Gbit Fiberchannel, there will be 100Gbit FCOE adapters.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
There's a draft of Firewire that hasn't hit yet that uses standard Ethernet cables. The port is supposed to be able to use either Firewire OR Ethernet and be able to switch between them depending on what it's plugged into. This sounds ideal to me.
The preceding post was not a Slashvertisement.
Ethernet is more of a generic name than a specific thing. It's more like "soup" than it is like "VHS".
Ethernet started as a daisy-chained garden-hose-size coax cable with vampire taps. Then RG-58 with BNC connectors, then twisted pairs to a hub, then switching hubs, then wireless... Not much stayed the same, not speed, media, topology,... except maybe carrier-sense. It's basically a comforting name, with the Ethernet-of-the-day varying at the chef's whim.
Keeping the name while tossing out the last remaining bit of commonality is a bit bizarre.
Fibre Channel over Ethernet has real promise, but these new requirements are a real stumbling block.
What many of the posters here may not realize is that storage traffic (and the "standard" SCSI it uses) is extremely intolerant of dropped frames. A link that in the TCP/IP world would be specatacular is wholly unsuited for block-level storage, which is too latency sensitive to have time to recover from dropped data.
Since the most common cause of dropped frames within a data center is congestion, FCoE requires your Ethernet to implement frame-based flow control, which prevents the congestion from occuring, along with the resulting frame loss.
SirWired
Ethernet already has flow control at the link-level - they're called stop frames (and since all modern switches give you dedicated links to end workstations and have some amount of hardware buffering, collisions/overrun aren't an issue). Now, since the world really runs on IP (doing raw ethernet would only ever work in the most local of LAN applications which is rather pointless in most deployments), and IP has TOS bits (which every real modern router can classify, queue, and throttle per-queue all in the hardware fast-path with no additional latency), I'm failing to see what they're proposing to solve since the problem is already solved. 1G/10G switches are used all over data centers and in HPC situations today (and have been for years)...
You realise "no more different connector types" was the reasoning with USB?
Extreme Programming - Redundant Array of Inexpensive Developers
And sadly, you'd see the same issues it with this standard too, because an ethernet RJ-45 plug isn't appropriate to plug into a cell phone, digital camera or mp3 player, but a 5-pin mini-connector isn't appropriate to run 25 feet to a switch/router either.