Slashdot Log In
Corporate Data Centers As Ethernet's Next Frontier
Posted by
timothy
on Tue Oct 21, 2008 10:26 AM
from the build-me-a-beowulf-cluster dept.
from the build-me-a-beowulf-cluster dept.
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.'"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Umm (Score:2)
Re: (Score:3, Insightful)
You probably don't have a storage area network, running over some proprietary fiber protocol, or some hight performance proprietary cluster, or a supercomputer around, do you? All those things are fading out as Ethernet evolves to do those kinds of jobs, but they didn't disapear yet.
what am I missing with this article? (Score:3, Insightful)
FTA: "But in its current state, Ethernet is not optimized to provide the service required for storage and high-performance computing traffic -- speed alone won't cut it, vendors say. Ethernet, which drops packets when traffic congestion occurs, needs to evolve into a low latency, "lossless" transport technology with congestion management and flow control features, CEE and DCE backers say."
If I understand right, they're trying to change Ethernet because of TCP/IP? Isn't that kinda, backwards as a concept?
We could add a "token" and make it a "ring"! (Score:5, Interesting)
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.
Parent
Re:We could add a "token" and make it a "ring"! (Score:4, Funny)
I agree. I don't want any of this "doesn't drop packets" Ethernet either. Packet loss is critical to a number of my in-house applications.
Parent
Re: (Score:3, Insightful)
People will deal with confusion. They deal with it all the time. Its the only way they know to deal with the walrus.
Re:We could add a "token" and make it a "ring"! (Score:4, Funny)
"Uber-fiber hyper gylde"
Combination personal lubricant and laxative?
Parent
Re:what am I missing with this article? (Score:5, Informative)
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.
Parent
Re: (Score:2)
Ahh thank you. I don't know that much with regards to networking, but I would imagine well before this standards issue haven't there been many forms of this already implemented, say as routing ethernet connections to switches? I mean only one true "Sender" is on each ethernet line, right?
Re: (Score:3, Informative)
So technically you could argue that there was not really a "collision" but the computer that didn't get its packet through is still told there was one so that it retransmits.
No. Switches don't notify the source that the packet was dropped. TCP's retransmit works without explicit notification.
Collisions are a thing of the past. Dropped packets aren't.
Re:what am I missing with this article? (Score:4, Informative)
Wrong. There is no "collision detection", the only way to tell that you had a collision is if the packet didn't get there. If two devices transmit at the same time, you get a mangled packet that won't pass CRC and gets dropped.
What they're really looking for is token ring - which was (and still is) a superior protocol - for Ethernet, as you increase the bandwidth utilization beyond 10%, you get so many collisions that your throughput goes through the floor, while for token ring, the throughput degradation is much more gradual. For bandwidth utilization above 10%, token ring is far superior to Ethernet.
Why Ethernet was adopted over token ring has more to do with religious issues and who can scream the loudest and bully their way through technical issues with emotion than it has to do with technical superiority.
Parent
Re: (Score:3, Informative)
I think it had a lot more to do with cost. :)
Ethernet was available first and had more hardware suppliers so the cost went down.
Token ring was really popular with IBM. It was almost a standard for IBM systems. I have a few microchanel Token Ring adapters if you need them
FDDI is Token Ring on fiber.
Re: (Score:3, Informative)
Haha, thanks for the offer but I don't have anything that will take MCA boards ... that was an interesting attempt by IBM to retake the PC market they lost. Oh, well.
As to Ethernet being first, I thought it was the other way around?
Re: (Score:3, Informative)
Re:what am I missing with this article? (Score:4, Informative)
Collisions occur when there are more than one sender on a collision domain, they don't have to be sending to the same host. Imagine you have four computers on a hub. Computer A sends a message to B while C simultaneously sends a message to D -- this is a collision.
We are really just talking about how collisions occur on a switch. Technically, they CAN'T occur on a full duplex switched network. The collision domain is the switch port and the PC port, and both can talk at once (full duplex).
Hypothetically though, if you set aside buffering, a 'collision like' conflict occurs when multiple PCs try to talk to a single port, except that one gets through and the rest are 'blocked' which is what I was trying to say. Of course, due to buffering, this is 'handled' and the conflict is actually pushed back to when the buffer overflows instead.
And yes, switches do have outbound buffers for each port so that if two sources try to send to the same host they can be done in sequence rather than causing an outbound collision on the destination port's collision domain. I am not sure what happens if this buffer becomes full, I had always assumed the switch would just begin dropping the packets (as indicated by this Cisco document).
http://www.webopedia.com/TERM/B/backpressure.html [webopedia.com]
Dropping packets is one option. The other is to use 'back pressure' to signal to the PC to back off a bit. This can be done by sending 'fake collisions' or via 802.3x Flow Control 'pause' signals. Many switches support these modes including those from intel and cisco.
Its often better to just dropping the packets and let tcp deal with it, but in some cases you can get better performance by using flow control/back pressure features.
Parent
Re: (Score:3, Informative)
Re: (Score:2)
Re:what am I missing with this article? (Score:4, Interesting)
t is possible to have IP on some other network, like token ring or FDDI, bother of which actually achieves higher throughput than ethernet for a given bandwidth.
Nope, both of which have higher overhead than full-duplex ethernet. They have better throughput than half-duplex ethernet, which is about as useful as being better than avian carriers. Half-duplex ethernet should just be banned entirely. Maybe that would make Linksys wake up.
Parent
Half duplex corresponds to wireless. (Score:3, Informative)
Nope, both of which have higher overhead than full-duplex ethernet. They have better throughput than half-duplex ethernet, which is about as useful as being better than avian carriers. Half-duplex ethernet should just be banned entirely. Maybe that would make Linksys wake up.
Half-duplex ethernet corresponds to the way things work on a shared peer-to-peer radio channel. Like WiFi. (Which uses the Ethernet MAC and collision/backoff algorithms - though I think the collision detection is inferred rather than
Re:what am I missing with this article? (Score:5, Interesting)
Parent
Re: (Score:3, Interesting)
Re: (Score:2)
This article sucks donkey nuts.
"Ethernet, which drops packets"
Ethernet switches Frames. It does not route packets. That's like saying a railroad track can drop a car because it doesn't like the passengers on it.
"they're trying to change Ethernet because of TCP/IP"
Your question just confuses things more because TCP segments are l4, as opposed to packets (l3) and frames (l2).
Re: (Score:2)
I guess the basic answer is:
I got it wrong, and so is the concept?
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
For a high-performance system with a large number of nodes, the cost of the actual network to connect everything together can cost more than the CPU's and servers themselves. To get high performance from this network, everything has to be tied so tightly together, that is is considered a component in itself, the network fabric. Also, the actual communication through the network cables is the slowest part of the system. So this price/performance ratio is what customers will be considering when buying a syste
Ethernet.. (Score:2, Funny)
The derivation of "ethernet" is quite interesting.
Ether - from the chemical compound Diethyl Ether, an anaesthetic.
Net - meaning 'full of holes'.
I think that's right.
Re: (Score:2, Informative)
I always thought it had more to do with "Aether" - a concept, historically, used in science (as a medium).
Definition from wikipedia - http://en.wikipedia.org/wiki/Aether [wikipedia.org]
Welcome to 1980! (Score:5, Funny)
"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!
So Ethernet's Next Frontier isn't Audio? (Score:2)
Why did I buy this http://www.usa.denon.com/ProductDetails/3429.asp [denon.com] then? >
Re: (Score:3, Funny)
Network Vendors (Score:4, Interesting)
This seems like a total kludge being put together by networking equipment vendors to find a way to differentiate their products and return to the days where a 10 Base-T hub was $1000.
Network gear is now mostly a commodity, except at the super high end.
The vendors hate that - so they are trying to push the host's functionality into the LAN gear instead. They don't want to provide "dumb pipes" any longer, they want to monkey around with the traffic and protocols, and provide virtual servers and such in their boxes.
Really, it's just an attempt to make the servers the commodity and their gear the expensive part.
Except... you already can implement this yourself with existing equipment and software, with much better control and no vendor lock-in. For low-end solutions, a Linux cluster works great behind an UltraMonkey front end. For higher-end ones, well, that's what IBM z-series mainframes are for.
What a great solution in search of a problem.
Quiz Time (Score:2, Funny)
"Ethernet is not optimized to provide the service required for storage and high-performance computing traffic -- speed alone won't cut it, vendors say. Ethernet, which drops packets when traffic congestion occurs, needs to evolve into a low latency, "lossless" transport technology with congestion management and flow control"
Q: Packet loss and traffic congestion are to Ethernet as:
A) blue screens are to Windows
B) registers are to assembly
C) mustard is to sausages
Combo Firewire/Ethernet port (Score:5, Interesting)
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.
Re: (Score:3, Informative)
If anyone is interested, there's info here [ieee.org] on that.
Think of "Ethernet" as "Soup" (Score:5, Informative)
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.
Nope, Carrier Sense is gone too... (Score:4, Informative)
Nope, the CSMA/CA part of Ethernet is gone also. Specs for a GigE hub exist in the standards, but nobody ever implemented them. (Switching got to be too cheap for anybody to bother.)
Obviously it didn't even get specc'd out with 10Gb Ethernet.
Oh, the frame format is still more-or-less the same from Classic Ethernet. Not identical, but still pretty close.
SirWired
Parent
Ethernet has had its day (Score:2)
Why do we still use ethernet? Ethernet was designed to work with multiple access cables in 10B2 and 10B5 layouts with backoff algorithms and all the other stuff that goes with detecting and avoiding collisions. With 10BT all that stuff is irrelevant now - what 10 base T is effectively is a highly complex serial cable carrying just one machines data to a router or switch. All the overhead of frame encoding and decoding and the collision system should be ditched and something more appropriate to a 1 -> 1 c
SAN over Ethernet has real promise, but... (Score:5, Interesting)
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
Re: (Score:3, Interesting)
Fibre Channel over Ethernet has real promise, but these new requirements are a real stumbling block.
Something to note is that the Ethernet in FCoE is really not the same Ethernet we use today. The acronym really confuses things. The article offers some better names for the new Ethernet standard, "Converged Enhanced Ethernet (CEE)", "Data Center Ethernet (DCE)." It really is the convergence of Fibre Channel and Ethernet, NOT Fibre Channel glued to the back of Ether. Think of it more like a gigantic leap for Ethernet (and IP/TCP eventually, as functionality is pushed down a few layers), not so much a do
This is FUD... (Score:4, Interesting)
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)...
USB (Score:4, Informative)
Re:Hmm... (Score:4, Interesting)
Connect your new keyboard and mouse via ethernet.
Connect your new HDD* via ethernet.
Connect your new video card via ethernet.
Connect your new scanner via ethernet.
Connect your new CD/DVD/BR via ethernet.
Connect your new printer* via ethernet.
Connect your new webcam* via ethernet.
No more USB cables with a million different connector types. No more PATA or SATA cables. No more serial or parallel cables. No more trying to figure out where to plug a given device in on a motherboard or looking for spare PCI/whatever slots - Just one type of cable and they all plug into a switch-like section of the motherboard.
Now, some devices (video cards as the most obvious) will still require extra power, but most devices could probably manage with a variant on PoE, meaning the inside of your case goes from rats-nets of assorted cable types, to a half-dozen or so tidy round cables.
* Yes, you can already get network enabled versions of these, but they count as a real full-fledged network endpoint, not as a slave device "local" to a particular computer.
Parent
Re:Hmm... (Score:5, Insightful)
You realise "no more different connector types" was the reasoning with USB?
Parent
Re:Hmm... (Score:5, Insightful)
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.
Parent
Re: (Score:3, Informative)
I really loved my old motorola phone with the mini-usb connector, now my LG phone doesn't share it's connector with any other device I own.
Re: (Score:3, Insightful)
Re:Hmm... (Score:4, Interesting)
Parent
Re: (Score:3, Interesting)
The design of RJacks specifically RJ-45, try and mitgate this as much as possible.
If its properly crimped, wiggling the cable, even pulling it should have no effect on either the cable contact or the jack contact.
i.e. it has no importance in real life by design.
Re: (Score:3, Informative)
* Yes, you can already get network enabled versions of these, but they count as a real full-fledged network endpoint, not as a slave device "local" to a particular computer.
You can with protocols like iSCSI or ATAoE. A lot of enterprise gear uses iSCSI, which makes a remote device appear like a local SCSI device, and some consumer-grade NAS devices running Linux can act as ATAoE devices, which does the same thing but with ATA instead of SCSI and over raw Ethernet frames rather than over IP.
Re:Hmm... (Score:4, Insightful)
Ethernet has nothing to do with the connector type. It is a layer 2 protocol that sits on top of the physical transport medium. There is a little bit of overlap with things like wiring specs for distances and attenuation, but it ethernet itself doesn't really care what plugs or wires you use. even if connectors were in the spect, it would still likely be extended to allow for new connector types to fit the appropriate devices (mobile phones, mp3 players, etc).
thus, for the consumer world you probably wouldn't see much difference on the user end. developers, on the other hand, would have to start pushing their device drivers into the network stack in order to get them working. say hello to firewalls and IDS/IPS on your HDD and video card.
Parent