Mfrhtyj

Different types of Ethernet (standard Ethernet, Fast Ethernet, Gigabit Ethernet) have different speed of data transfer (10 Mbit, 100 Mbit, 1 Gbit). Why is that?

On the physical layer, the speed of electrical signals (voltage change) stays the same. The cable (twisted pair) is also the same (I think). So why does the maximum bandwidth differ? If the reason is that in the past, we didn't have so much processing power in network cards, why doesn't the protocol allow for bandwidth negotiation (that would suit both devices that communicate)?

Different types of Ethernet (standard Ethernet, Fast Ethernet, Gigabit Ethernet) have different speed of data transfer (10 Mbit, 100 Mbit, 1 Gbit). Why is that?

Progress - technology advances.

On the physical layer, the speed of electrical signals (voltage change) stays the same.

The wave propagation speed depends on the medium. Cat-3 is slightly slower than the Cat-5 and fiber, and coax (from ancient 10BASE5) and Cat-7/8 are the fastest - they're all very close though, 60% to 80% c0.

However, the frequencies that pass over the medium differ considerably - from 10 MHz for 10BASEx to ca. 1.6 GHz for 40GBASE-T. Of course, higher frequency means faster voltage change. On fiber, the current generation runs 50 Gbit/s per lane.

The cable (twisted pair) is also the same (I think).

No. Cat-3 only supports 10 Mbit/s, Cat-5e up to 1 Gbit/s, 10 Gbit/s requires Cat-6A, and 25/40 Gbit/s require Cat-8 cable rated at 2 GHz. The cable is only the same (Cat-5e) for 100BASE-TX and 1000BASE-T due to a leap in encoding technology.

So why does the maximum bandwidth differ? If the reason is that in the past, we didn't have so much processing power in network cards, why doesn't the protocol allow for bandwidth negotiation (that would suit both devices that communicate)?

Yes. Faster data rates mean faster processing and more elaborate encoding using more silicon (=transistors). Also, back in the 80s and early 90s, computers lacked the internal bandwidth to make use of faster data rates - they even struggled with 10 Mbit/s for a while. Literally nobody would have had a use for 10+ Gbit/s back then.

Ethernet does allow for speed negotiation on twisted pair - faster (and some intermediate) rates have been added for a while:

• 10 Mbit/s (1990)


• 100 Mbit/s (1995)


• 1000 Mbit/s (1999)


• 2500 Mbit/s (2016)


• 5 Gbit/s (2016)


• 10 Git/s (2006)


• 25 Gbit/s (2016)


• 40 Gbit/s (2016, most likely the final speed for twisted pair)


• fiber currently adds 50, 100, 200, and 400 Gbit/s (2017)

Well, most devices that support 1000Base-T will also negotiate to 100Base-TX and 10Base-T.

Older devices that are 10Base-T cannot negotiate to 100Base-TX or 1000Base-T, nor can devices that are 100Base-TX do 1000Base-T (although they can probably do 10Base-T), because those standards did not exist when the older devices were built.

There is a lot more to this than just the speed. For example, the encoding used by each is different. It is fairly simple to put in backwards compatibility, but how would you propose to build in for a standard that does not yet exist?

The cable (twisted pair) is also the same (I think).

There are actually different cable categories. The currently registered cable categories are 3, 5e, 6, 6a and 8 (new). Each category can handle up to a certain frequency that determines the bandwidth you can get for ethernet.

• Category-3 cable will work for 10Base-T, but faster speeds will not
  work.


• Category 5e will work for 10Base-T, 100Base-TX, and 1000Base-T.


• Category-6 will work for 10Base-T, 100Base-TX, and 1000Base-T. It will
  also handle 10GBase-T for a shorter distance.


• Category-6a will work for 10Base-T, 100Base-TX, 1000Base-T, and
  10GBase-T.


• Category-8 is newly registered for 25GBase-T and 40GBase-T, but it
  has limitations, and the distance is less than 1/3 of the distance
  (30 meters vs. 100 meters).

Processing power and hardware capabilities are exactly the reason.

10MBit standards are from the early 1980s. At that time, it would have been:

• very, very expensive to build circuitry able to do anything intelligent with serialized digital data at 100MBit/s - even with the actual clock being around 32MHz, you would likely have needed low-integration S-TTL circuitry, or even worse, ECL circuitry. This costs a lot, consumes power like hell, and in case of ECL, is tricky to adapt to 5V TTL signalling prevalent in computer systems back then. High integration, fast CMOS was only beginning to find a foothold, the 33Mhz 80386 CPU was considered bleeding edge technology in 1989.




• unusual to find a computer that could usefully serve or consume data at more than a megabyte a second - an ESDI hard drive capable of delivering 16 mbit/s was considered pretty fast back then.

There is auto-negotiation alright, under the condition that you are:

• using twisted-pair ethernet (at any speed), or one of the fibre-based styles that can (not all can!).

The coaxial systems had no concept of an established link at layer 1 and 2 - the network didn't know something was on it until it started talking or responding. Also, while the coaxial cable used for 10base2 and 10base5 would have electrically supported far faster speeds (bet you could push 10GBit through an RG58 if you optimized your transceivers for it!) if used as a point to point link, these systems abused it as a bridge-tapped common circuit that could never had supported 100mbit links anyway, leaving no reason to implement an autonegotiation facility. Also, exactly that bridge tapped, high power, often installed sloppily, circuit would probably become an EMI nightmare if you attempted to put any signal at the electrical bandwith required for 100MBit on it (you are in shortwave territory here. Shortwave noise propagates nasty far, and most installations you saw back then would have made an awesome shortwave antenna).

• You actually allow your devices to autonegotiate - with many devices (eg switches), a port preset to a certain link speed and duplex style will no longer cooperate with the autonegotiation protocols, and will only properly work talking to a port preset exactly the same way.