This many standards is dumb: Decoding 25Gb Ethernet and beyond The 25 and 50Gb switching standards have finally been ratified. Switches from various manufacturers have been available for some time, but now there's a better than average chance they'll interoperate with one another. While more speed is generally good, the 25 and 50Gb standards will complicate things for data centre …
Thank you.
And in Mage Towers we still wonder why only some 1Gbps Ethernet computer ports work with the cheap 3com 8-port switches. Most don't. Some work if you set them manually to Master or 10Mbps in windows! I don't know how to do that on Linux, so I use the WiFi. Nor have I sussed out why one Airport is 54Mbps and another is 250Mbps, probably g and n standards.
Yes, I love the XKCD.
Great article.
Some work if you set them manually to Master or 10Mbps in windows! I don't know how to do that on Linux,
man ethtool
Assuming of course that the port is not using one of these PHY chips which fell off the back of the truck and is documented on a pack of fags in the back pocket of a local pizza delivery guy in Harbin.
Once upon a time...
The vendors supplied 40Gbps and there was little demand.
The cloud providers demanded 25Gbps and started building lots of servers with 25Gbps links and using 25Gbps top-of-rack switches.
On the desktop we are seeing a similar battle for 2.5Gbps and 5Gbps where support for the higher speeds over Cat5E may see them become the new standards.
And the battle was over...
From http://www.datacenterdynamics.com/content-tracks/colo-cloud/aws-how-to-manage-mega-growth/97431.fullarticle
"A few years back, AWS made the decision to go with 25Gbps Ethernet (25GbE) at a time when the industry was moving towards 10GbE and 40GbE. Hamilton said 40GbE is essentially four lanes of 10GbE, while 25GbE future-proofed the AWS network, allowing a switch to 50GbE (2x 25GbE) which would deliver more bandwidth at lower complexity.
To drive this network, AWS now makes its own custom silicon for server network interface cards (NICs) thanks to its acquisition of Israel-based chipmaker Annapurna for $350m last year.
The new Amazon Annapurna ASIC supports 25GbE, and will enable even faster innovation, as it gives the cloud giant control over both software and hardware down to the silicon level, Hamilton said: “Every server we deploy has at least one of these in it.”"
While it's clear that the Author knows what he's talking about, the way the article is written is very confusing.
Phrases like:
"10GBase-T ports use more power than it typically provided by SFP+ ports and thus until very recently 10Gbase-T modules to plug into SFP+ ports have been difficult to find and expensive"
and this:
"What people actually buying networking want is the most possible networking with the lowest cost and the least hassle."
are confusing to understand. Also, it would help if the article clearly outlined the 4 standards of 10Gb internet, maybe in different paragraphs or in bullets as an introduction. I had to go back and forth to understand which 4 standards are being mentioned.
While it's clear that the Author knows what he's talking about, the way the article is written is very confusing.
I think part of the problem is down to the rise of industry consortiums, taking over what previously would have been delivered by a task force working for an IEEE working group. (The main purpose of this approach was to enable smaller groups to work more rapidly towards a working standard without the delays and overhead inherent in the more formal IEEE standards development process.) So it is even less clear what are vendor standards and/or implementations of draft standards, which are Consortium standards and which are fully fledged IEEE Standards. So to me what is missing is some linkage of the various industry labels to a standardisation framework.
We had similar problems with 802.3 over twisted-pair and particularly with the 100Mbps implementation, with many competing names being banded around by vendors as they firstly vied to get their implementation adopted as the standard, then implementing their version of a draft standard before finally producing products that actually implemented the final ratified Standard.
So a question has to be whether the 25G Consortium's ratified standard is going to be submitted to IEEE 802.3 for formal adoption as an Internation Standard and thus be assigned an 802.3xx designation and thus enable those outside of the Consortium to more easily draw up specifications and identify suitable products.
"you can terminate a cable with any compatible connector you want"
Not necessarily. There are variances in the RJ-45 types you can attach, if the trusty RJ-45 is your choice. Certainly anything with a conductor can be your "connector." While at lower speeds any type of RJ-45 is fine, when you start to approach the the upper operating range, in terms of signal strength vs radio noise, the "cheapness" of your connector may come into play. That's why some RJ-45s are full metal, grounded shrouds, and others are the normal clear plastic with variations on the pins and the pin metal content and spacing, etc. One size does not fit all, in other words. Even more so with cables, and I've not been making connectors for several decades. Shielded vs unshielded, plenum and other special coated cables and the CAT type. So many to choose from!
"10Gb vendors have been quite happy to abuse the SFP+ vendor ID to try to create lock in, driving up complexity and cost."
You mean create profits! :)
OK, unless I've completely misunderstood this (a distinct possibility!), 40Gb and 100Gb are NOT ACTUALLY 40Gb or 100Gb speeds? If I had a single TCP connection between 2 servers using 40GbE, say doing an rsync or scp or similar, and assuming I wanted to keep the frames in order (so no round-robin'ing of the packets between interfaces/aggregations), the maximum speed (ignoring any overheads) I could get would actually be the ~10Gb of a single lane (or ~25Gb if using that with 100GbE)?
This doesn't sound like the previous (10GbE and lesser) standards where the name referred to the throughput you could get in ANY situation (single connections/multiple connections etc). "40GbE" or "100GbE" to me sounds like a method of multiplexing multiple 10GbE streams through a single port (and hence cable) to a single port at the other end, saving on port counts and cable runs between say clusters of computers or core switches, as opposed to actual increases in individual source-to-destination communication bandwidths.
I understand completely why, as per theblackhand's post, AWS went with a TRUE 25Gb solution rather than these bodgy link aggregation/multiplexing solutions.
Sorry, not quite correct. You're confusing layers of the OSI model.
Standards with multiple lanes - which includes the 4-lane 10GbE standards - split the signals at the physical layer and then reconstitute them at the physical layer.
Say, for example, that you had 10Gbit of data coming into your XAUI-based 10GbE NIC. The 10GbE silicon would split the data stream (which it sees as a stream of 1s and 0s, not at packets) into 4 lanes of traffic and fire them out to the interface.
The interface would then either dump the signals onto copper as radio waves (each lane being it's own chunk of spectrum) or forward these to an optical transceiver. If sent via copper then the interface and silicon on the receiving end need to be able speak the same number of lanes with the same kind of encoding. So if you are using XAUI you are probably using 10Gbase-CX4 as your copper medium, for example, and you'll need some silicon somewhere in there that can pick up the 4 lanes of traffic emitted and put that back into a single 10Gbit stream that gets dumped onto the PCIe bus.
If, however, there are optical transceivers in play this is different again. The optical transceiver will take the data stream it gets (4 lane, 10 lane or just one lane) and convert that into light according to the standard it is designed for. This may mean that a 10Gbit stream from the application layer is broken into 4 2.5Gbit streams at the NIC silicon then reconstituted into a single 10Gbit optical stream that then goes through the same process in reverse.
It's also equally possible that your single 10Gbit stream goes from application layer all the way to the transceiver as a single 10Gbit stream, but the transceiver then cuts it into 100 different colours before firing down the fiber.
When optical transceivers are involved the general rule of thumb (that doesn't always apply, but let's ignore that for a moment) is that if you have two optical transceivers that speak the same optical standard they can communicate with one another, regardless of the underlying silicon/copper signal architecture. If, however, you are trying to connect using copper (I.E. forgoing the use of expensive transceiver hardware) then you can only connect up nodes if the underlying silicon can understand one another.
Hope that helps.
Let's see if I remember this correctly. I think the previous poster is referring to the problem in iSCSI when you either have MPIO on the host aggregating multiple links or when you setup LACP on the host to a switch. In both cases, the host is exposing those as a single logical path even though the underlying paths are still separate below that level. Take a 20g LACP of two 10g paths. Any one iSCSI session can only actually get 10g of bandwidth because the aggregation doesn't actually bond the physical layer (or was it Layer 2?) to give you a 20g path. It only gives you a single logical path that masks the two separate 10g paths. That single iSCSI stream will saturate the chosen path at 10g. LACP and MPIO do that for good reasons and generally behave like a 20g path except in some cases like iSCSI sessions.
The new 100g and 40g solutions they describe do not evidence that behavior because that single iSCSI session would be multiplexed across all those individual channels and recomposed at the other end unbeknownst to the iSCSI protocol. They will act as a single path with their combined speeds.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
