Talk:2.5GBASE-T and 5GBASE-T

Article name

Since "NBASE-T" is a marketing term coined before standardization started we should consider renaming the article to something more appropriate. In extreme, devices sold as NBASE-T compatible (or MGBASE-T for that matter) might not be compatible with the final standard. 2.5 and 5 Gigabit Ethernet? 2.5G/5GBASE-T? --Zac67 (talk) 11:08, 1 May 2016 (UTC)

I was thinking the same thing: The article needs another name. I vote for 2.5G/5GBASE-T of the two you wrote, because it is simple and more precise. Maybe 2.5GBASE-T and 5GBASE-T is even better. --CableCat (talk) 18:52, 1 May 2016 (UTC)

Yes, 2.5GBASE-T and 5GBASE-T is fine. --Zac67 (talk) 20:53, 4 May 2016 (UTC)

5BASE-T at Cat 5e, the math does not add up

I have written that 5BASE-T is guaranteed to work with Cat 5e at 55 m. Just like 10BASE-T is guaranteed to work with Cat 6 at 55 m (well know fact).

I got this info from a sales seminar from Cisco, and at the time it made sense. But now I see that the math does not add up.

For 10BASE-T at Cat 6 = ${\tfrac {400Mhz}{250Mhz}}=1.6$ =

For 5BASE-T at Cat 5e = ${\tfrac {200Mhz}{100Mhz}}=2.0$ = 100% more Mhz when cable is reduced to 55 m

I have removed the claim that 5GBASE-T is guaranteed to work with Cat 5e at cable lengths of 55 m. I would be great to know what the maximum guaranteed cable length is. --CableCat (talk) 06:10, 17 May 2016 (UTC)

I don't think your math proves anything either way. Reducing the length will increase the usable bandwidth but not nessacerally in the same ratio for all cable types. Also the usable bandwidth depends not just on the cable type but on how good the electronics are at compensating for non-flat frequency response, inter-pair crosstalk and so-on. Plugwash (talk) 10:54, 16 September 2016 (UTC)

The "math" don't really add up to much – you can't just apply the ratio of the frequencies to the lengths. As a rule of thumb it might get you somewhere, but that's it. While the coding schemes of 10/5/2.5GBASE-T are identical, the cable characteristics are not just shifted up/down from the lower/higher spec; attenuation is only one side of the medal, NEXT, FEXT, and AXT are others. --Zac67 (talk) 17:10, 16 September 2016 (UTC)

Comparison of twisted pair based ethernet technologies

Regarding baudrates and used pairs, please see Gigabit ethernet page:

In a departure from both 10BASE-T and 100BASE-TX, 1000BASE-T uses all four cable pairs for simultaneous transmission in both directions through the use of adaptive equalization and a five-level pulse amplitude modulation (PAM-5) technique. The symbol rate is identical to that of 100BASE-TX (125 megabaud) and the noise immunity of the five-level signaling is also identical to that of the three-level signaling in 100BASE-TX, since 1000BASE-T uses four-dimensional trellis coded modulation (TCM) to achieve a 6 dB coding gain across the four pairs. Since negotiation takes place on only two pairs, if two gigabit devices are connected through a cable with only two pairs, the devices will successfully choose 'gigabit' as the highest common denominator (HCD), but the link will never come up. Most gigabit physical devices have a specific register to diagnose this behaviour. Some drivers offer an "Ethernet@Wirespeed" option where this situation leads to a slower yet functional connection.[14] The data is transmitted over four copper pairs, eight bits at a time. First, eight bits of data are expanded into four three-bit symbols through a non-trivial scrambling procedure based on a linear feedback shift register; this is similar to what is done in 100BASE-T2, but uses different parameters. The three-bit symbols are then mapped to voltage levels which vary continuously during transmission.

To calculate 100Base-TX bitrate.

• 1 Pair per direction
• 125MSymb/s
• 4B5B binary encoding
• Total: 125*4/5 = 100Mbps full duplex (or 200Mbps in both directions, using 2 pairs)

To calculate 1000Base-T bitrate.

• 2 Pair per direction << You failed to read your own citation /CableCat
• 125MSymb/s
• PAM-5 modulation (5 bits per symbol)
• 4/5 FEC (trellis)
• Total: 125*5*4/5*2 = 1000Mbps (or 2000Mbps in both directions, using 4 pairs)

Tafinho (talk) 22:10, 30 April 2016 (UTC)

You have misunderstood a few thing:

• PAM-5 = 5 power levels, not 5 bits.
• Nyquist frequency is half of the symbol rate, expect for 10Base-t where it is equal.

Please also see the refernce:

• Cisco Live BRKCRS-3900, slide 41, time 57:40
• Direct link to the slide

--CableCat (talk) 17:51, 1 May 2016 (UTC)

To follow up here is the correct calculation for 1000Base-T:

• 4 Pairs per direction (channels)
• 125MSymb/s (62.5Mhz Nyquist frequency)
• PAM-5 modulation (5 different values for each symbol)
• 4/5 FEC (trellis)
• Total: 4(channels) * 125M(symbolrate) * 2(PAM-5 + 4/5 FEC) = 1000Mbps

I wanted to keep the table simple, and just include the effective bitrate per herz after error correction.

PAM-5 + 4/5 FEC has an effective encoding of 2 bits per symbol, since there are 2 symbols per herz. Bits per Herz is 2*2=4.

--CableCat (talk) 18:25, 1 May 2016 (UTC)

Let's start with the number of pairs:

Fast Ethernet uses 1 pair per direction, therefore TX and RX, corresponding to the orange and green pairs. One pair per direction. Can we agree on this ?

Then, total bitrate is by definition

Symbol rate * modulation * FEC

Which on fast ethernet is:

125 MSymb/s * 1 * 4/5 = 100 Mbps.

Then , efective bit per symbol is 1 .

--Tafinho (talk) 20:15, 1 May 2016 (UTC)

The table shows effective bits per Herz. Not bits per symbol before encoding. At each Herz, 2 symbols are send. For each 5 symbols, one is used to sync the signal. So the effective bits per Herz becomes 2 * 4/5 = 1.6. --CableCat (talk) 22:36, 1 May 2016 (UTC)

By definition you cannot carry more symbols than Hz. Please check Shannon–Hartley theorem. That's why using Nyqvist isn't really useful in this case. You should use total bandwidth. Also, it makes no sense to encode non-integer modulations (and also, odd modulations are also never recommended).

If you wan't to use bits per symbol, you need to take into account any FEC, otherwise the calculations won't add up. Tafinho (talk) 14:49, 2 May 2016 (UTC)

You can easily carry more symbols than Hz, for instance with MLT-3 encoding. --Zac67 (talk) 17:56, 2 May 2016 (UTC)

You can carry 2 symbols per Herz. One at the top, and one at the bottom of the curve. The table does intentional not go into details of power levels, signal sync and error correction. It is shows the final efficiency of those, so they can easily be compared side by side.

Without any knowledge of how the signal is encoded, one can calculate the efficiency like this:

${\tfrac {SymbolsPerSecond}{2}}=NyquistFrequency$ (except 10BASE-T because it uses Manchester code)

${\tfrac {EndUserBandwidth}{NyquistFrequency}}=EncodingEfficiency$

If you want the efficiency per channel, divide the result by the number of channels.

--CableCat (talk) 21:50, 2 May 2016 (UTC)

I assume that by "it makes no sense to encode non-integer modulations", you mean that bits per symbol before error correction and signal sync, must be an integer. Consider the following thought experiment: You have 2 channels, each have have 3 volt levels: +1V, 0V -1V. How many bits per symbol can you send?

Channel A	Channel B	Bit pattern
+1	+1	010
+1	0	001
+1	-1	000
0	+1	011
0	0	no transmit
0	-1	100
-1	+1	111
-1	0	110
-1	-1	101

As you see it is possible to send 3 bits over 2 channels with 3 volt levels. Meaning that bits per symbol per channel is 1.5 – a non-integer value. --CableCat (talk) 09:10, 3 May 2016 (UTC)

Frequency

The frequency discussed at 2.5GBASE-T_and_5GBASE-T#Comparison_of_twisted_pair_based_ethernet_technologies is about the frequency of the waveform. Nyquist frequency is about the sampling frequency. The sampling rate necessary for 100BASE-TX is 125 Mega samples per second however the last encoding step is to use an NRZI encoding to half the frequency of the waveform to 31.25 MHz. Fast_Ethernet#100BASE-TX This waveform frequency seems to be more appropriately labeled as "apparent" or "effective" since it makes transitions from +1 to -1 and back no faster than 31.25 MHz and is seen at codepoints 3/4 on 4B5B encoding table. The remainder of the time, the frequency appears lower. GeneC1 (talk) 10:06, 16 June 2016 (UTC)

Imho, this article should stop using the term "Nyquist frequency". It is used in the context of time-discrete samplings of a signal and nothing of that is done when transmitting stuff through a cable. The cable is time-continuus. The interesting thing would be the "Signal bandwidth". This is the highest frequency at which the cable attenuation matters. --93.199.251.49 (talk) 14:35, 13 August 2016 (UTC)

I agree with you, we better "keep it simple and straightforward". --109.228.198.62 (talk) 19:02, 14 August 2016 (UTC)

In a earlier version I used to term "signal bandwidth". We should use the term that best reflect the cable requirement. If it is possible to run a 100BASE-TX connection trough a cable that can only handle 31.25 MHz (I don't know if it is possible), then that is the number and term we should list. CableCat (talk) 10:11, 17 August 2016 (UTC)

I don't think Nyquist frequency is the appropriate subject here. "Signal bandwidth" has the problem of being misinterpreted most of the time, so maybe we should use "spectral bandwidth" here as it's about the cable requirements.

It generally is possible to run 100BASE-TX over Cat.3 cable which only "supports 16 MHz" – on short runs. I've done this on ca. 10m myself, probably 1000BASE-T would also work. A low grade cable will propagate a high frequency signal, but with a very high level of attenuation. The cable grade guarantees that a signal of x MHz will we propagated with an attenuation of y dB (or less) for a specified length of cable. So, higher frequency, less reach. --Zac67 (talk) 21:35, 17 August 2016 (UTC)

It is my experience that when using cables beyond 100 m. Then the connection sometimes work with 100BASE-TX and not 1000BASE-T. Suggesting the the cable requirements are greater for 1000BASE-T. CableCat (talk) 07:32, 19 August 2016 (UTC)

I have change Nyquist frequency to spectral bandwidth in the article, and included a short explanation. See refernce D. --CableCat (talk) 10:49, 19 August 2016 (UTC)

Fair enough. Thanks! --37.130.64.180 (talk) 13:33, 20 August 2016 (UTC)

Illustration of twisted pair based ethernet technologies

I am working on this illustration (now in SVG):

--CableCat (talk) 18:33, 21 August 2016 (UTC)

Amazing! Thanks! --37.130.64.180 (talk) 05:52, 21 August 2016 (UTC)

Impressive - you'll definitely want to add that to Ethernet over twisted pair, too! --Zac67 (talk) 19:18, 21 August 2016 (UTC)

Done :-) --CableCat (talk) 19:45, 21 August 2016 (UTC)

The only concern I have is it makes the frequency limit for cables look like a hard limit. It's not, what in fact happens is that the cables performance gets worse as frequency goes up. That is why you can use lower-spec cable on short runs than on long runs. 130.88.240.74 (talk) 10:43, 16 September 2016 (UTC)

You are right, they better indicate the distance for cable spec column. --46.1.214.44 (talk) 16:55, 20 September 2016 (UTC)

I have addressed this in note [e]. Lets keep the SVG file simple CableCat (talk) 20:10, 16 October 2016 (UTC)

Fair enough. Thanks! --46.1.232.234 (talk) 07:14, 18 October 2016 (UTC)

CableCat, I wonder if you would be willing to update the illustration to include the 25GBASE-T, 40GBASE-T and Cat 8 standards as well? The data table is already updated over at Ethernet over twisted pair. --Gnuish (talk) 08:45, 6 February 2021 (UTC)

I can't make sense oft the "Bits per hertz" axis label. If you consider the number of bits unit-less, than that axis is in units of ${\frac {1}{\text{Hz}}}={\text{s}}$ ("bit seconds"). A volume in the figure then is in ${\text{MHz}}\cdot {\text{s}}=10^{6}$, i.e. unit-less, which is particularly not a speed. The "Bits per hertz" axis probably is just "bits", isn't it? Then a unit of volume is "$1_{\text{bits}}\times 1_{\text{lanes}}\times MHz_{\text{sbw}}$", so essentially "bits per second" – a speed. — χenoΛntares ⌘ 14:40, 14 June 2024 (UTC)

It's about frequency efficiency. 10BASE-T uses Manchester code which does a full cycle per bit ≙ 1 bit/Hz. 100BASE-TX uses 4b5b with MLT-3 which requires four transitions for a full cycle. 4/5 * 4 = 3.2 bit/Hz. --Zac67 (talk) 17:44, 14 June 2024 (UTC)

I understand phase encoding but the mentioning of Manchester Code does not explain – at least not to me right now – how a factor of "bit per frequency" multiplied by an other frequency shall yield a notion of "speed".

"Bit per hertz" (= "bit·seconds") constitutes kind of energy/work (think of man·hours or Watt·hours). That may make some sense e.g. in the table in the second paragraph of this lemma, but not in the illustration. Not, if volume of the blocks should really represent "speed".

— χenoΛntares ⌘ 17:47, 14 June 2024 (UTC)

You are way overthinking this. It's not about how a factor of "bit per frequency" multiplied by an other frequency shall yield a notion of "speed". It's about dividing the target speed by that frequency-efficiency value to derive the cycle frequency of the encoded signal. --Zac67 (talk) 20:14, 14 June 2024 (UTC)