Recent Features
| |||||||||||||
How creaky is Ethernet the spec?How creaky is Ethernet the spec?Posted Oct 29, 2009 3:58 UTC (Thu) by felixfix (subscriber, #242)Parent article: JLS2009: Generic receive offload
Back when Token Ring and Ethernet were battling it out, I was amazed at the sloppiness of the Ethernet protocol with collision detection at its heart. It seemed so clunky, and some reports said Ethernet collisions with even a few nodes slowed it down to Token RIng's 4Mbps. I never quite understood why Token Ring lost out ... but I didn't envision the big networks that came down the pike where Token Ring would have been lost. Switches made a huge difference compared to hubs, too.
Have there been any attempts to replace Ethernet that have actually gone anywhere? I suppose if there had been, I wouldn't be asking. But the idea of looking for collisions on so many dinky packets seems even clunkier to me now. What kind of real thruput do 10Gbps networks actually achieve today?
(Log in to post comments)
How creaky is Ethernet the spec? Posted Oct 29, 2009 4:11 UTC (Thu) by agrover (subscriber, #55381) [Link]
All 1Gb and above Ethernet is full duplex, point to point, no hubs (only switches) and therefore collisions are not an issue. 10Gbps networks can hit wire speed, taking header overhead and interframe gap into account. Like the article says, the big problem really is that the Ethernet packet has not scaled with the enormous throughput increase.
How creaky is Ethernet the spec? Posted Oct 29, 2009 4:57 UTC (Thu) by felixfix (subscriber, #242) [Link]
Makes sense ... hadn't thought of it that way. If there are no more collisions, is there any reason to keep collision detection in the spec? I seem to recall the packet preamble had to be long enough to cover the collision detection. Would it add anything to get rid of that?
It's funny how the old cable strung from one node to the next has stuck in my mind even tho I haven't seen that kind of install in ages.
How creaky is Ethernet the spec? Posted Oct 29, 2009 11:08 UTC (Thu) by epa (subscriber, #39769) [Link] All 1Gb and above Ethernet is full duplex, point to point, no hubs (only switches) and therefore collisions are not an issue.So it doesn't really make sense to call it Ethernet any more; mostly just a marketing name.
How creaky is Ethernet the spec? Posted Oct 29, 2009 14:01 UTC (Thu) by SEJeff (subscriber, #51588) [Link]
Doesn't make sense to call it CSMACD if there won't ever be collisions at the
very least.
How creaky is Ethernet the spec? Posted Oct 30, 2009 15:47 UTC (Fri) by giraffedata (subscriber, #1954) [Link] There appears to be interoperability that justifies calling the new protocol Ethernet. You can replace one link of an existing Ethernet network with a 10G one and it all still works -- and not by simply negotiating down to the old protocol. My understanding is that is what makes the 1500 byte MTU a constraint on 10GE. Also: Can you replace a 1G ethernet card in a computer with a 10G and now talk at full speed (to a 10G peer) without replacing the device driver or anything else in the computer?
How creaky is Ethernet the spec? Posted Oct 30, 2009 20:59 UTC (Fri) by nix (subscriber, #2304) [Link]
There are lots of 10G cards that also do 1G, but I don't think you'll find
any device drivers for 1G-only cards that work with the quite different hardware that does 10G :))
Fundamentally though most of the hardware (as in the physical components
How creaky is Ethernet the spec? Posted Oct 29, 2009 16:50 UTC (Thu) by Shewmaker (subscriber, #1126) [Link] Collisions are not an issue ... data is not lost immediately, but contention at a transmit port of a switch is a problem. When that happens, one packet gets transmitted while the other is placed on a queue. That queue may be in memory shared by all ports, a subset of ports (a blade in the switch, for instance), and some switches allow you to set aside dedicated memory for a port's queue.I've got a simple illustration in this presentation. Packet loss occurs when the queue overflows, and TCP uses that as a signal to slow down. It has worked remarkably well over the years, but switches have been making it work partly be increasing the amount of memory for the queues. Large queues cause large variations in delay and mean that TCP will have increasingly more packets in flight before it knows that it needs to slow down. Infiniband has a reliable (connected) mode that allows packets with an MTU of 64k, which is quite nice for high performance storage networks and parallel file systems that are IP based. There are new Ethernet standards coming out that have equivalents to Infiniband's features, but I don't know how much longer until products are out. Data Center Ethernet and Converged Enhanced Ethernet Incidentally, my research is focused on providing performance guarantees even on current inexpensive Ethernet hardware (LAN, not WAN). I expect it will also be beneficial on the reliable (i.e. lossless) network technologies as it allows arbitrary guarantees (unfairness) that are more flexible than priority based QoS schemes.
How creaky is Ethernet the spec? Posted Oct 29, 2009 19:41 UTC (Thu) by mebrown (subscriber, #7960) [Link]
"All 1Gb and above Ethernet is full duplex, point to point"
Actually not true. When 1Gb Ethernet first came out, you could buy actual hubs which had actual collisions and the wonderful-ness (or lack thereof) that entailed (meaning half-duplex-only). They were very quickly obsolete when almost all vendors switched to using switches exclusively and I dont think you could actually buy a hub anymore.
How creaky is Ethernet the spec? Posted Oct 30, 2009 2:46 UTC (Fri) by smoogen (subscriber, #97) [Link]
I was told that if you sent a flood of ICMP traffic to certain 1GB switches they would 'fail' into a hub-like mode.
The collision detection is still needed because they are still possible on a pure switch.. usually they happen with certain traffic patterns or if the network gets saturated. However they occur a LOT less than they did on hubs.
How creaky is Ethernet the spec? Posted Oct 29, 2009 20:03 UTC (Thu) by bronson (subscriber, #4806) [Link]
From my perspective, it was the star topology that brought Ethernet's big win.
I remember trying to wrestle thick cable around corners without causing network issues and fighting endlessly with vampire taps (and SCSI terminators, but that's unrelated). Token ring was definitely better than this mess.
Then thin cable brought Ethernet competitive with token ring. Now the biggest problem with both systems was employees rolling their chairs over the cable under their desks and bringing the entire network down. And the occasional NIC that loses its mind and goes into a retransmit flood. And sometimes terminators. But, overall, it was OK.
Then 10baseT and cheap switches came along and allowed Ethernet to use an inexpensive star topology. This is what absoulutely murdered token ring. Twisted-pair star setups were so much faster to set up and more reliable to keep working that nobody looked back.
Funny how admins at the time would look at the neck-thick bundle of wires slamming into 80-port switches in the server closet and think, "Good lord, I'd never want to try to keep all that mess working." It didn't take them much time adminning a twisted pair ethernet network for them to grow to love it though.
Fun times.
|
|||||||||||||