Talk:Fast Ethernet/Archive 1

The Merge
I merged in 100BASE-TX, 100BASE-T, 100BASE-SX, and 100BASE-FX into this collective article. It still needs a lot of work. KelleyCook 18:44, 14 June 2006 (UTC)


 * I've pulled in some items from the Ethernet physical layer page. That page says that 100BASE-TX uses NRZI, not MLT-3; the talk page for that page says


 * Not in a single place in a standard MLT-3 is mentioned. I allowed myself to edit that article to reflect this. In fact, 100BASE-T4 uses very different scheme from that mentioned in MLT-3 patent (not to speak of 100BASE-TX).


 * MLT-3 is used by FDDI, but that's mostly it.


 * I'll check my copy of the 802.3 standard and update this page as appropriate. Guy Harris 22:34, 14 June 2006 (UTC)
 * I fixed the MLT-3 stuff.oakad 07:49, 16 June 2006 (UTC)

Cat5 wiring
utp cat5 consists of 4 twisted pairs instead of 2 —The preceding unsigned comment was added by 81.241.228.203 (talk • contribs) 05:19, 29 June 2006 (UTC).
 * It is true that standard cat5 cables have 4 pairs and the standard connectors have 8 positions but the dominant fast ethernet standard (100baseTX) still only uses two pairs (1000baseT uses all 4 though). Plugwash 16:51, 11 October 2006 (UTC)

misc
Note that today I modified the 100base-FX section to include support for both multimode and single-mode fiber. 100base-FX is called 100base-FX despite what physical media it travels over. You can have 100base-FX over mm OR 100base-FX over single-mode. The only real difference (besides the media itself) is that maximum (and sometimes minimum, research saturation etc) distance you can run. The spec specifically calls out 2km as the maximum distance of multimode for 100base-fx (also 10base-fl), but in the case of single-mode, the distance is entirely based on your optical fiber budget calculated by subtracting rx sensitivity from tx power. Normal SM optical transceivers support at least 10km, and can range up to 110km. Note that you always have to run full duplex over the 412m 100mbps limitation no matter what type of media you employ.

Support for my contention that 100base-fx supports both mm and sm can be verified by looking at Spurgeon's "Ethernet: the definitive guide" page 149. (besides the fact that I have 12+ yrs industry experience, and there are thousands of products on the market that support both mm and sm under the 100base-FX protocol) Kmwiki (talk) 21:17, 15 January 2008 (UTC)

Connectors for FX
I've put in the connectors list from 802.3 but it appears there may be other connectors in use, does anyone have any sources for what if any unofficial connectors are common? Plugwash 01:47, 22 March 2007 (UTC)

Plugwash --- I'm not sure about sources, I could probably scrounge some up if necessary.

In the industry, the most common connectors for 100base-FX are either ST or SC, with SC being the most popular. MT-RJ connectors are also used when you are looking for high-density. So, when you need, say (24) 100base-FX ports in a 1U switch, it's almost imperative that a smaller form factor connector be used. With the popularity of gigabit fiber, some 100base-FX devices are even being shipped with LC connectors, the common choice for SFP-based gig fiber solutions. Kmwiki (talk) 21:05, 15 January 2008 (UTC)

One other thing --- although I didn't remove this, MIC connectors on ethernet devices are pretty rare. Unless you get into some goofy industrial proprietary market, you are unlikely to find a MIC connector on a true ethernet device. Check Nortel, 3Com, Cisco, and you won't find a single vendor putting a MIC connector on an ethernet device. Kmwiki (talk) 21:23, 15 January 2008 (UTC)

wiring diagram
Hi. Is there any good reason why the wiring diagram shows the legacy (non-preferred according to the TIA/EIA-568-B standard) T568B wiring configuration, instead of the recommended T568A configuration? --- Joe. —Preceding unsigned comment added by 61.8.13.206 (talk) 00:26, 23 January 2008 (UTC)
 * TIA/EIA-568-B replaced and rendered obsolete TIA/EIA-568-A. TIA/EIA-568-B specified two wiring conventions, one of which is shown in the article as T568B and is valid. The other convention is T568A and is equally valid but is not shown. Picking up a handful of cables I notice that they all follow the T568B convention. I would say that this is the more commonly practised of the two conventions, which is probably why it was chosen for the article. 83.104.249.240 (talk) 18:50, 1 March 2009 (UTC)

4 bits/second?
It is very easy to understand the transmit speed 100Mbps comes from 4 bits at a time, 25 Mhz per second. But, can somebody please tell me, how does a single twisted pair wire transmit four bits at a time (for one direction)? —The preceding unsigned comment was added by 221.169.12.48 (talk) 16:11, 9 April 2007 (UTC).
 * It doesn't, the bits are clocked at that rate over the paralell MII interface to the transceiver, in the transceiver they undergo 4B5B encoding, and are clocked out serially at 125mhz over the wire using a weired 3 level encoding to better match them to the line characteristics. Plugwash 18:01, 27 April 2007 (UTC)

Hi, I have been looking for books talking about ethernet physical layer. Now I know the parallel signals in 4 bit wide 25MHz go through a 4B5B encoding before they are serialized and transmmited to PMA sublayer. There is still one thing that confuses me. In the page of wiki talking about CAT 5 cable, it says: "Currently unrecognized by TIA/EIA. Provided performance of up to 100 MHz...". But the PMA sublayer is clocked at 125MHz, how does a CAT 5 cable designed to carry "up to" 100 MHz actually carrying 125Mhz signal in 100BASE-TX ethernet? Is there anything wrong with the page of wiki? Or the signal is actually not transmitted at 125Mhz over the wire? Or is there anything wrong with my understanding?

My understanding is that it actually is transmitted at 125 symbols/s, but the MLT-3 encoding of those symbols makes the worst-case "fundamental frequency" only 31.25 MHz. And that MLT encoding ... somehow ... avoids the bandwidth limitation of CAT 5 cable. If you ever find a good explaination, please put it in the article, OK? --75.37.227.177 21:52, 31 July 2007 (UTC)
 * There's an explanation in the MLT-3 article itself: "MLT-3 cycles through the voltage levels -1, 0, +1, and 0. It moves to the next state to transmit a 1 bit, and stays in the same state to transmit a 0 bit. Similar to simple NRZ encoding, MLT-3 has a coding efficiency of 1 bit/baud, however it requires four transitions (baud) to complete a full cycle (from low-to-middle, middle-to-high, high-to-middle, middle-to-low). Thus, the maximum fundamental frequency is reduced to one fourth of the baud rate. This makes signal transmission more amenable to copper wires." Essentially, it's a trade-off between frequency and the ability to resolve different voltage levels. With ternary systems you have to detect reliably three different levels, which makes it more susceptible to noise than binary. MegaPedant (talk) 11:56, 26 November 2009 (UTC)

What does the TX in 100base-TX stand for?
What does the TX in 100base-TX stand for? —Preceding unsigned comment added by Panarchy (talk • contribs) 03:58, 26 February 2008 (UTC)

T = twisted pair - not sure what if anything the x stands for here but it does distinguish it from 100Base-T4 Qureus1 (talk) 07:03, 7 February 2009 (UTC)
 * While wikipedia groups the standards by thier physical medium type (which probablly makes sense given our intended audience) that isn't how the actual standard is structured. There is a lot of stuff that is common between 100BASE-TX and 100BASE-FX and this common stuff is called 100BASE-X by the standard. 100BASE-X covers the encoding of the signal into a 125MHz bitstream etc. The individual TX and FX sublayers then convert that to the form used for encoding on the wire/fiber. Plugwash (talk) 01:02, 27 November 2009 (UTC)

no half duplex FX?!
in http://en.wikipedia.org/w/index.php?title=Fast_Ethernet&diff=next&oldid=111062033 soccerman58 claims that there is no such thing as half duplex 100BASE-FX as there is no "need for it". This seems to be contradicted by the relavent section in 802.3 (confusingly they have a general X section which applies to both TX and FX) which explicitly talks about half duplex and is nonsensical (TX and FX both have seperate transmit and receive pairs but both need to be able to run in half duplex mode to support hubs). Plugwash 01:23, 22 March 2007 (UTC)

Just as confirmation, there is most certainly 100base-FX half duplex. You can end up with a duplex mismatch between two ethernet switches, for instance, where one is set to full and the other to half. The Full side would intermittently step on the half side, causing serious performance problems on the link. It's a common task for admins to check the duplex setting on the ethernet switches involved to ensure they are both set to full. Kmwiki (talk) 20:58, 15 January 2008 (UTC)

My text, Network+ Guide to Networks, explains that in half-duplex mode one strand is used for transmission only and the other for reception only while full-duplex mode uses both the fibers to send and receive data. This text claims that the segment length is limited to 412 meters in half-duplex mode while if used in full-duplex mode the same cable can be 2000 meters. If true, why would the mode affect the segment length like this? Qureus1 (talk) 07:02, 7 February 2009 (UTC)
 * That must be a misunderstanding. The two fibres always work in duplex mode, i.e. one sends and the other receives due to the fact that one end of one fibre can either have an optical transmitter (a light source) or an optical receiver (a photo-transistor) but not both (unless you want to go to a great expense). In full-duplex mode both paths are used simultaneously, i.e. the station sends and receives at the same time. In half-duplex mode the two paths are used alternately, i.e. the station can only send or receive at any one time. Contrast this half-duplex mode (using two uni-directional media) with simplex mode (which uses a single bi-directional medium). Now, the question I have is: if cable length is limited to 400m in half-duplex mode because collisions must not go undetected (I'm guessing that the propagation delay must be 4 times greater in copper as compared with fibre), how can full-duplex mode allow the maximum cable length to be increased to 2km while still catching any collisions? 83.104.249.240 (talk) 04:47, 17 February 2009 (UTC)
 * "I'm guessing that the propagation delay must be 4 times greater in copper as compared with fibre" <-- I don't think so, I think it's more that the copper unlike the fiber is limited by things other than propogation delay.
 * "how can full-duplex mode allow the maximum cable length to be increased to 2km while still catching any collisions?" <-- in full duplex mode collisions can't happen so there is no need to catch them. -- Plugwash (talk) 14:25, 7 December 2009 (UTC)

Maximum LAN sizes
What are the maximum physical and logical sizes of 100Base-TX LANs?

If one segment can be 100m, then two endpoints can be 200m apart, via one switch. But switches can be chained/cascaded, so the maximum distance could be increased. What is the limit?

(Note also the difference between theory and reality. Some equipment works better over real cable segments, some worse.  So the 100m segment limit is fuzzy.  Some equipment may auto-negotiate down to lower speeds when there are cable problems, but still function somewhat.)-96.237.78.13 (talk) 02:46, 25 August 2010 (UTC)
 * If using hubs there is a limit imposed by the need for a collision to be detected everywhere, iirc it's officially two hubs for fast ethernet (though in practice you may get away with more due to shorter than required delays in the hubs) but hardly anyone uses hubs anymore so this is largely irrelevent in modern network design. Switches either seperate collision domains or eliminate them entirely so this isn't a problem on a switch based network. Eventually the delays would build up to the point where higher level protocols started to time out but the network would have to get huge for that to happen with most protocols.
 * Practically there are several other troublesome factors. One is that switches rely on storing the mac addresses of every machine on the lan to decide where to send packets. If there are too many machines for the switches to store the switches will "fail open" and end up broadcasting traffic they don't know where to send to the whole network. Furthermore being a tree network a lot of traffic will tend to cluster on the center of the tree (the impact of this can be reduced by making those parts of the network higher speed or by using techniques like port trunking). Also even in the absense of switches failing open the ammount of broadcast traffic will increase with LAN size and would eventually reach the point where it overwhelmed the nodes in the network. Plugwash (talk) 15:21, 26 August 2010 (UTC)
 * As each switch port is a separate collision domain, distance is measured only in the same port. So each port can have a cable wich spans up to 1024m, using up to 4 repeaters (probably only at 10Mbps). But there is no limits related to 2 separate ports. Broadcasts are still a problem; a switch defaults to place all ports in the same broadcast domain. This can be solved using VLANs, which are logical division of the broadcast domains. Switches doesn't allow a frame originated from a port assigned to one VLAN to be sent to another port assigned to a different VLAN. When frames cross from one switch to other, VLAN trunks carry the VLAN id information using 802.1q tagging (or ISL encapsulation, in old Cisco Switches). Inter-VLAN communication is done with router elements, which should have a port in each VLAN (physical or logical). This can be done with real routers, or L3 Switches.Zekkerj (talk) 13:57, 22 November 2012 (UTC)

LX
As part of the same edit mentioned about a mention of single mode fiber was added to the FX standard, later a bracketed 100BASE-LX was added after this. Is this an unoffical standard? an unofficial name for using a fiber type that is out of spec but works? something else? Plugwash 01:47, 22 March 2007 (UTC)

Plugwash, if its any consolation, I've never heard of 100base-LX, now 1000base-LX is a different story.

The common ethernet standards are currently (beginning 2008):

(10mbps finally being phased out at the chip level due to ROHS european elimination of lead-based stuff)

10base-5, aka 10mbps Thicknet

10base-2, aka 10mbps Thinnet

10base-T, aka 10mbps Twisted-pair

100base-TX, aka 100mbps twisted-pair

100base-FX, aka 100mbps over fiber

100base-SX, UNPOPULAR 100mbps over mm fiber only standard, 300m maximum, cheaper 850nm optics.

1000base-SX aka gigabit over mm

1000base-LX/LH aka gigabit over SM (usually, unless you use a mode-conditioning patch cable on both sides and run it over mm)

1000base-ZX aka gigabit over sm super long haul.

Don't ask me about 10gig yet. :)

Kmwiki (talk) 21:34, 15 January 2008 (UTC)


 * "10mbps finally being phased out at the chip level due to ROHS european elimination of lead-based stuff"
 * I don't see why the elimination of lead would pose a problem for 10mbps ethernet controllers, the only thing that could be an issue is chips that are no longer manufactured but still in large stock becoming unusuable for products that must be rohs compliant. Indeed microchip introduced a new ethernet controller not so long ago which afaict has only ever been produced in rohs compliant packaging. Plugwash (talk) 23:18, 17 January 2008 (UTC)

User:A_aberdeen
 * "100Base-LX10" is detailed in IEEE802.3 2005 but is missing from this article. I was going to add some details but wanted to check there wasn’t a reason for this. Biffa 13:04, 28 April 2009 (UTC)

100BASE-LX10 is described here now, along with 100BASE-BX10; yes, that's what IEEE 802.3-2012 calls it, even though both can, apparently, run over distances > 10 km - the spec says "The 100BASE-LX10 and 100BASE-BX10 PMD sublayers provide point-to-point 100 Mb/s Ethernet links over a pair of single-mode fibers or an individual single-mode fiber, respectively, up to at least 10 km." (emphasis mine), and some Googling finds references to 100BASE-{B,L}X20 and so on. Guy Harris (talk) 18:27, 17 April 2014 (UTC)