Talk:Ethernet/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Netware and Ethernet

I added the Netware References and Link to the frame type section. the whole text is a bit confusing - suggestions for improvement ? Wefa 22:45, 9 Jul 2004 (UTC)

I finally got around clearing that one up (about 18 months later :-) ) I moved the usenet link to references and added another reference entry for the collision/throughput paper by Boggs & al. Apparently nobody found serious issues with the rest of the section, so I leave it alone Wefa 05:16, 4 January 2006 (UTC)

Duplex

This isn't a full-blown networking textbook, I suppose, but I'd like to see more mention of duplex. It is supposed to be automatic but causes us nothing but trouble. Sorry, I don't feel qualified to contribute that part. --Kbh3rd 02:55, 30 Sep 2004 (UTC)

I've added some stuff, the main thing to remember with duplex is that if an endpoint with auto-negotiation disabled (or not supported) is connected to one with it enabled the one with auto-negotiation enabled will detect half-duplex. Plugwash 00:49, 15 June 2006 (UTC)

Duplicating information to other pages

I'm unaware of any etiquette/procedure for doing this, but is there any way that your description of Ethernet's tranceiver protocol could be duplicated on the page describing CSMA/CD? --Kierah 14:03, 16 Mar 2005 (UTC)

It should be sufficiant to just note which page it came from so anyone who needs to can follow its history and find the real authors. Plugwash 00:49, 15 June 2006 (UTC)

Remove IPstack template?

As I mentioned in Template_Talk:IPstack#Template_overuse I don't think it is appropriate to put the IPstack template on the Ethernet page. Does anyone disagree? Sfisher 00:45, September 8, 2005 (UTC)

I agree that Ethernet is not part of the "Internet protocol suite", exactly. However, Ethernet is very often used as a link for IP networks; and the terms "Internet" and "Ethernet" get chucked around a lot, and sound superficially similar. So I can imagine someone coming here to figure out how they relate to each other. Hence, illustrating (as the IPstack template does) that Ethernet is one of several protocols that can be used to carry IP seems useful to me. Failing that, maybe a section called "Ethernet's relationship to Internet" or something. -- Johantheghost 21:00, 16 September 2005 (UTC)

I have a disloke for that template as well, because it is neither accurate nor does it give a full picture. But apparently it serves its purpose, and it could be worse :-). So I'd suggest to leave it in place. —Preceding unsigned comment added by we (talk • contribs)

History of the Name

Bit of a "Credit where credit's due" rant... :-) The article says:

Ethernet was originally developed as one of the many pioneering projects at Xerox PARC...

Ethernet is based on the idea of peers on the network sending messages in what was essentially a radio system, captive inside a common wire or channel, sometimes referred to as the ether.

Wouldn't this be a good place to mention the University of Hawaii, who paved the way with radio-based CSMA/CD on their AlohaNet? Wasn't the name Ethernet based at least in part on this pure radio origin? (I believe that the first incarnation of Ethernet at PARC was called Alto Aloha Network, as it was an Aloha-based scheme for networking Xerox Alto computers.)

BTW, no argument about the great work that PARC has done over the years! - Johantheghost 21:46, 16 September 2005 (UTC)

Bit stuffing

Ok, I don't know if this is the right place to place this question, but does Ethernet use bit stuffing like CAN? —Preceding unsigned comment added by Doug1984 (talk • contribs)

No the early variants of ethernet use manchester encoding and the faster variants use more complex systems. Plugwash 00:49, 15 June 2006 (UTC)

CSMA/CD algorithm incorrect?

According to Peterson & Davie's Computer Networks (ed. 3, p 116), Ethernet is a 1-persistent protocol. This means when a busy line goes idle, an Ethernet adaptor will promptly send any queued frames (specifically, after a 9.6 microsecond delay); the article contradicts this with the statement "Wire just became idle - Wait a random time." I believe that statement only applies after a collision, although the article implies it is relevant even without a collision. But actually, I thought the exponential backoff started right after step 2, not after the busy line goes idle. The CSMA/CD article says the backoff starts after the jamming signal. -- anon

You are absolutely correct, I've fixed the algorithm now. See IEEE 802.3-2002, section 4.2.2.3 for reference (figure 4-4a shows the complete procedure). --Gosub 13:57, 19 March 2006 (UTC)

can token ring be briged to ethernet?

-- Plugwash 19:14, 16 December 2005 (UTC)

No. Among other things, the MTU is different. --Alvestrand 07:56, 9 January 2006 (UTC)

Yes, but only using specialized equipment that is aware of and remediates the issues the dieffernce between TR and Ethernet cause in Layer 3 protocols like IP. More specifically, it works for IP and IPX with switches from a number of vendors, e.g. Cisco. OTOH many of these have already disapperead or are currently disappearing from the market - except for some legacy networks Token Ring is effectively dead now. Wefa 19:26, 30 January 2006 (UTC)

I wouldn't call the result "bridging" - but YMMV..... and I don't have a good name for that functionality..... "non-TTL-decrementing router"????? (URGH) --Alvestrand 21:26, 30 January 2006 (UTC)

It's bridging in the sense that it decides what interface to forward packets over based on the layer 2 MAC address and does not forward packets between layer 3 networks like routers. It's more than bridging because it has to modify the payload to convert embedded MAC addresses, and strict bridges never modify the packet. The goal of Wikipedia is not to come up with good names, but to document the names that are used. I haven't researched it, but think the common term is "translational bridge". A related term is "encapsulation bridge", which doesn't translate the packets but simply tunnels Ethernet packets across another medium such as FDDI or a serial line.

Translating a large Token Ring or FDDI packet to Ethernet is tricky. Actually, it's impossible at layer 2. Some translational bridges know enough IP to do IP Fragmentation. But I think they mostly require routers and hosts connected to the Token Ring or FDDI segment to explicitly set a lower MTU than would normally be allowed with those technologies, which has a side effect of making communications between hosts that don't traverse an Ethernet segment slightly less efficient. --Rick Sidwell 01:22, 12 February 2006 (UTC)

"Layer 3 Bridge" Iambk 03:46, 6 December 2006 (UTC)

separate 100base-t4 100base-t2 from ethernet article

There can be some history info about them, list of products (?), wiring (as for 100BASE-TX), information about signals encoding. 194.85.82.121 01:04, 17 December 2005 (UTC)

why didn't 100baseT2 make it?

was running ethernet over cat3 less common than people thought?

were there generally the spare pairs availible for 100baseT4?

were thier technical problems that meant 100bit over 2 pair cat3 wasn't feasible?

did it just arrive too late? Plugwash 23:17, 28 December 2005 (UTC)

Merge 802.3 article ?

Dont't merge! I don't think that is a good idea. the only substance in the 802.3 article is the indexing of the various standard subgroupos to the respective technologies they invented resp. specified. If we merge that now, we will have to branch that out again sooner or later, since the ethernet artiocle is pretty large already. Wefa 05:16, 4 January 2006 (UTC)

So what about that table makes it apply to "802.3" rather than "Ethernet"? At this point, "Ethernet" and "802.3" are pretty much the same thing - as of 1997, "802.3" doesn't imply "length field, not type field", so that's no longer the distinction between "802.3" and "Ethernet". Should there be a split of the Ethernet page, with a top-level page, linking to subpages for items such as the list of PHY types, but with no distinction made between "802.3" and "Ethernet"? Guy Harris 07:11, 4 January 2006 (UTC)

the table explains the standard body's or the standard's structure in relation to ethernet. I do not see that the Ethernet Article should be splitted according to PHY anyway, so I don't see that point. ( Plus, while you are correct that the difference is mostly moot these days, it should be noted that about 99,9% of today's ethernet packets do not claim adherence to this standard (since they are DIX framed)) Wefa 11:02, 4 January 2006 (UTC)

Err, umm, perhaps you missed what I said - as of 1997, DIX-framed packets DO adhere to the 802.3 standard; to quote the Ethernet page, "In IEEE 802.3x-1997, the IEEE Ethernet standard was changed to explicitly allow the use of the 16-bit field after the MAC addresses to be used as a length field or a type field." Take a look at IEEE 802.3-2002, page 40, where it says:

3.2.6 Length/Type field

This two-octet field takes one of two meanings, depending on its numeric value. For numerical evaluation, the first octet is the most significant octet of this field.

a) If the value of this field is less than or equal to the value of maxValidFrame (as specified in 4.2.7.1), then the Length/Type field indicates the number of MAC client data octets contained in the subsequent data field of the frame (Length interpretation).

b) If the value of this field is greater than or equal to 1536 decimal (equal to 0600 hexadecimal), then the Length/Type field indicates the nature of the MAC client protocol (Type interpretation).

The Length and Type interpretations of this field are mutually exclusive.

When used as a Type field, it is the responsibility of the MAC client to ensure that the MAC client operates properly when the MAC sublayer pads the supplied data, as discussed in 3.2.7.

So the difference is no longer a difference between "802.3" and "DIX", it's a difference between two types of 802.3 frames.

The table enumerates the "versions of Ethernet", to quote the table's title, so it's certainly relevant to Ethernet, and would make sense on an Ethernet page. If the problem is that the Ethernet page is too large, then either 1) it should be split with that table on a "sub-page", and with other sub-pages or 2) it should be split with that table on the main Ethernet page, and with other sub-pages - but it's not at all clear that one of the "sub-pages" should be "IEEE 802.3", as, at this point, IEEE 802.3 is Ethernet, just as IEEE 802.5 is "Token Ring" (although, frankly, one could make a better case for splitting "IEEE 802.5" and "Token Ring" than for not combining "IEEE 802.3" and "Ethernet", as one could argue that "Token Ring" should describe the general concept of a token ring, including FDDI, etc., while "IEEE 802.5" should describe the IBM/802.5 implementation thereof; there's no such split for Ethernet and 802.3 any more, as 802.3 now includes DIX framing). Guy Harris 19:08, 4 January 2006 (UTC)

Please, you can nitpick all you want - I don't want this huge standards committee oversight table in the ethernet article. it's already huge and confusing without it. Put it somewhere else and have a link. The situation right now, while maybe not optimal, does this just fine. Any potential change has to improve on this. Wefa 20:46, 24 January 2006 (UTC)

I have removed the merge tag - no compelling consensus has been reached on a merge and no comments have been made here in well over a month. I second the view that the Ethernet article is too large to accomodate the information from 802.3 - if they are to be merged Ethernet will require a major overhaul first. QmunkE 18:47, 8 March 2006 (UTC)

Electrical Characteristics?

A missing bit of information is the electrical characteristics of the various versions of Ethernet. What are the voltage levels? What would you see if you hooked up an oscilloscope to the wire? —Preceding unsigned comment added by 65.206.239.163 (talk)

With a basic scope nothing you could make sense of, you aren't going to see more than a handfull of bytes worth of data on a scope screen and at that scale it will look pretty random. Anyway this information should be in the 802.3 standard and some of the information on encoding techiques is already in wikipedia but if you are going to add this sort of infromation to wikipedia please do so in more specific articles on the variants of ethernet not in the core ethernet article. Plugwash 00:17, 10 May 2007 (UTC)

segments

Repeaters can be used to connect up to five Ethernet segments

i thought it was 5 between any two endpoints not 5 total please clarify Plugwash 20:18, 22 January 2006 (UTC)

[updated with signature and a few corrected typos] As far as I know you are right. The key point is the network diameter in terms of signal runtime, because you need a certain maximum signal runtime to guarantee everybody is correctly aware of collisions. The rule of thumb usually is "no more than 4 repeaters between any two stations". Interestingly the article is misleading here. Hubs are nothing but multiport repeaters anyway, so this got quite important with the amount of hub-chaining many people liked to do in the nineties when hub networks were big. One practical corollary of this was that you could not allow users to connect hubs tio the network when you rand a two tiered hub structure yourself. In today's switching world, this issue is mostly moot anyway - I rarely get to see more than two hubs chained together. All this of course applies only to 10Mbit - chaining 100mbit hubs used to be so complicated that most people opted to switches for backbone connectivity.wefa 18:53, 30 January 2006 (UTC)

Regarding Hubs are nothing but multiport repeaters, I don't think that's quite true. There were multiport tranceivers (like the DEC DELNI), and there were also buffered repeaters. The difference was that the buffered repeater regenerated the timing, but the MPT did not. -- RoySmith (talk) 18:11, 30 January 2006 (UTC)

Interesting point, even though a multiport transceiver is a different (and not so standard) beast IMO. What, if any, do you propose to clarify the section on repeaters in this regards ? wefa 18:53, 30 January 2006 (UTC)

How is length of payload determined?

Hi!

The article says that 802.3 uses a payload length field while Ethernet uses an EtherType field. How can the length of the payload contained in an Ethernet frame be determined?

On a side note, the article EtherType contains text which is just copied out of the Ethernet article (or vice versa).

Best regards
Christian 11 Feb 2006 —Preceding unsigned comment added by 84.175.181.83 (talk)

It's determined either by

• using a length field in the higher-level protocol, if the higher-level protocol has such a field, as IPv4 and IPv6 do - the length field might be the length of the payload, as with IPv4, or the length of part of the payload, as with IPv6, where it's the length of the IPv6 payload, not counting the bytes of the fixed-length IPv6 header;
• inferring it from other values in the packet, as is done with, for example, ARP (the length is the fixed-length part of the ARP packet plus the lengths of the addresses, as specified by length fields in the fixed-length part), or the Spanning Tree Protocol (the length depends on the packet type).

BTW, the article should say that both of those two packet formats are legal 802.3 packet formats and legal Ethernet packet formats now - as of 1997, the 802.3 standard supports the use of the field as a type field or as a length field, and the 802.3 standard defines Ethernet now. Guy Harris 11:46, 11 February 2006 (UTC)

I can't find a copy of 802.3 now (where it should be stated), but I believe the end of packet is signalled to the hardware by some special bitpattern on the wire - something that can't occur in a real packet. The minimum packet size is 64 bytes, so protocols like IP and ARP that sometimes have smaller packets have to include their own length fields. But the reason for the demise of the intra-packet length field was that it did not give anything new. I believe - this should be stated by someone who can also cite the reference! --Alvestrand 13:07, 11 February 2006 (UTC)

In the 10MB versions, the packet ends when the sender stops transmitting. The receiver determines the length by simply counting the number of octets it received. (If transmission stopped mid-octet, it reports a framing error). It them passes this value up to the higher layers, which compare the actual length with the expected length as recorded in various length fields as mentioned above, and reject packets that are too short or truncate packets that are too long.

The higher speed versions have a special End-of-Packet Delimiter (EPD) to specifically mark the end of the packets. I think this is to allow "frame bursting", sending a series of frames without relinquishing control of the medium. Once the sender stops transmitting, the medium must remain idle for some minimum amount of time (at least in half duplex mode), so that all connected devices can reliably detect the idle condition. --Rick Sidwell 01:57, 12 February 2006 (UTC)

Merging

I whole heartedly disagree with merging any more articles into this one. It's already 38 KB. If anything, stuff should be merged out from here into other articles. Cburnett 19:52, 22 March 2006 (UTC)

Merger proposal

I propose to Merge in 10-gigabit Ethernet, Gigabit Ethernet and Fast Ethernet into the respective sections as it all is (or at least should be) duplicate information. Of course this page is getting a little large, so I was then going to split off some of the development history into a new page named something like Ethernet development history as I believe that most people surfing to the Ethernet page want to know current facts more than that it was originally a 3Mbps over a big COAX cable. KelleyCook 19:52, 22 March 2006 (UTC)

I whole heartedly disagree with merging any more articles into this one. It's already 38 KB. If anything, stuff should be merged out from here into other articles. Cburnett 19:52, 22 March 2006 (UTC)

Dont merge, information will be lost. Each generation of ethernet should have its own article.Patcat88 14:17, 26 March 2006 (UTC)

The merger proposals have been redirected to suggest merging into the new Varieties of Ethernet page (as that page already had the mergefrom proposals in it). Discussion of the merger should be moved to the Talk:Varieties of Ethernet page. Guy Harris 23:44, 4 April 2006 (UTC)

I've merged Varieties of Ethernet into Ethernet physical layer.

Merging

Hi, I think I have a solution to the merge problem. I posted this on KelleyCook's talk page: "You expressed interest before (Talk:Ethernet) in writing an ethernet history article. I think that's a great idea and would solve our merge problems. I have a two pronged attack solution, please let me know what you think. Currently, the articles 10-gigabit Ethernet, Gigabit Ethernet and Fast Ethernet seem weak. But I'm afraid that merging with Ethernet varieties will lose interesting historical info. So... what if you wrote your history article and integrate the historical info from these three and then I'll merge the variety info with the varieties page. Does that sound good?" I think this is the best solution, any other ideas? Comments? Avraham 20:22, 6 April 2006 (UTC)

I don't get it...

After skimming through this article, I still don't know what an Ethernet is. Can someone put a summary in less technical terms or something? --80.227.100.62 11:43, 4 April 2006 (UTC)

I didn't change anything but is Ethernet#General description still too technical? Cburnett 22:50, 4 April 2006 (UTC)

"General description" seems like the worst name for a section, ever. If someone could use that section and the intro section to create a single concise introduction, that would greatly improve the article. --71.169.132.97 21:56, 26 October 2006 (UTC)

half duplex and twisted pair ethernet.

how exactly does this operate? i seem to remember something about the recipiant sending the data back to the sender so the sender can detect collisions. Is this correct? Plugwash 12:07, 7 May 2006 (UTC)

Half-duplex Ethernet detects collisions in the hub and sends a Jam signal out all ports when it sees one. The Jam is a Manchester code violation. Richard Bennett.

Having checked the actual specs it seems colisions are detected by the trancievers when they detect data from both the host and the wire at the same time. The jam signal is a function of the repeater (hub) that comes in when there are multiple segments (which there nearly always are with half duplex 10baseT). Plugwash 01:55, 4 June 2006 (UTC)

I wrote the actual spec for 1BASE5, the first twisted-pair Ethernet standard, and I remember how it worked. The hub detected a collision because its receive was active on more than one port, and sent a Manchester code violation out each port. Repeaters on coax Ethernet didn't do this, as the coax method of collision detection relied on sensing a voltage drop on the cable. In this scenario, the senders of the affected packets sent Jam messages. But who really cares about coax repeaters in 2006? RichardBennett 02:59, 4 June 2006 (UTC)

alternatives

how about Myrinet or InfiniBand ???

should these be "see also" links somewhere on the page?

I dunno they are only competitors at the very high end, in the general purpose LAN market noone uses anything but ethernet. Plugwash 00:49, 15 June 2006 (UTC)

benifits of twisted pair

I just removed the following (which i belive was recently added)

"The primary benefit of twisted-pair Ethernet, however, was the ease with which its cabling could be installed in the modern office. Offices are generally equipped with cable trays or ducts for telephones, and twisted-pair cabling was easily installed alongside existing cables."

Thinnet cabling is no easier or harder to handle than cat5 and in fact i'd think it would be easier to retrofit because you need a lot less of it. any comments? Plugwash 08:18, 6 June 2006 (UTC)

Take it from one who has done both, and run both, too. Thinnet was a nightmare in larger installations, which is why it never really left the realm of small and hobbyist networks. For one, it was way more fragile than TP because of the termination issue, then the coaxial cable never had the engineered environment to be built into cable trays (though there were some contenders). The point of 10baseT was to provide well engineered solutions to correct the problems found with thinwire and yellow cable, and learn a bit or two from Token Ring cabling, too. Wefa 00:04, 8 June 2006 (UTC)

but the reason it was a nightmare was not because of the cable as that paragraph implies but because it was a bus network. the big advantage of twisted pair was the cabling was so cheap that a 100% point to point system was feasible. Plugwash 01:12, 8 June 2006 (UTC)

The network that I ripped out at work eight years ago consisted of a thicknet backbone running through cable trays with a transceiver for every office. That transceiver was connected to a DELNI screwed onto the wall behind the office door, which served as a "hub" for the office. We began replacing that in 1991 with 10BASE-2 multiport repeaters, but a lot of people stayed on the yellow cable because thinnet was thought to be unreliable. Yet, in 1994, we started replacing the repeaters with switches, but people didn't want 10BASE-T wiring to their offices because "hubs are too expensive and it's easier to daisy-chain new computers on the thinnet segment"! I didn't get the offices converted to twisted-pair until 1998, and didn't get the last thicknet segment ripped out until 2002. 121a0012 02:58, 8 June 2006 (UTC)

The paragraph was correct in that RG58 wouldn't flex around corners through ducts nearly as easily as Cat 3 will. But I don't think that was a reason for twisted pair taking off. Twisted pair was significantly cheaper and moreover was point-to-point which made the network far less prone to segment wide disruptions. —Preceding unsigned comment added by KelleyCook (talk • contribs)

I always found the cat5 cable to be much easier to handle than the thinnet coax. For one thing, you can pull cat5 cable into far tighter bends than thinnet cables - and the drop cables for thinnet were both expensive and heavy (they were basically 2 coax cables running up to a hidden T junction inside the connector - when you inserted the plug into the wall, you briefly broke open the cable you were splicing into). But I too think that the reason 10BASE-T won was because it was feasible to star-wire it. --Alvestrand 06:34, 15 June 2006 (UTC)

MLT-3

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. oakad 07:44, 14 June 2006 (UTC)

note, oakad wrote all the above in this section but heavilly edited his existing comments while doing so, history starts at http://en.wikipedia.org/w/index.php?title=Talk:Ethernet&diff=prev&oldid=58532828 Plugwash 00:49, 15 June 2006 (UTC)

So what? I always write, then edit, then write some more. Why shouldn't I do this to my own comment? oakad 16:33, 15 June 2006 (UTC)

gigabit and autonegotiation

From the article

"Note that some switch OSes, as well as some card drivers, still have the option to disable autonegotiation and force a twisted pair connection to 1000Full or 1000Half, but doing that is against specification and should never be used as you won't properly negotiate any of the other parameters. Instead the proper way, for example, to force gigabit ethernet over a Cat 5 connection is to still specify autonegotiation, but limit the advertised capabilities to only 1000Base-T"

From what i've read of the spec it seems not doing the autonegotiation would make it impossible to connect at all. I wonder if forcing 1000Full or 1000Half on actual hardware just does do autonegotiation with the capabilities limited to one entry? Plugwash 23:19, 24 June 2006 (UTC)

xerox report

from the article:

"However, a Xerox report in 1980 summarized the results of having 20 fast nodes attempting to transmit packets of various sizes as quickly as possible on the same Ethernet segment"

Does anyone know if this report is availible online anywhere, i'd like to check the specifics (in particular the cable lengths) Plugwash 22:57, 25 June 2006 (UTC)

fiber optic ethenet

are there any mechanisms in place for autodetecting the type and duplex of a fiber optic ethernet link or does it have to all be configured manually? Plugwash 23:16, 29 June 2006 (UTC)

1000BASE-X uses Autonegotiation to resolve Duplex and Flow Control, but not speed, as those technologies are not backwards compatible with older fiber technologies, like 100BASE-FX. --UNHchabo 20:14, 30 June 2006 (UTC)

Metcalfe Ethernet Sketch

Maybe someone will find this useful: http://www.digibarn.com/collections/diagrams/ethernet-original/composit-ethernet-sketch.jpg --CCFreak2K 10:01, 9 July 2006 (UTC)

Here's the page it's from: http://www.digibarn.com/collections/diagrams/ethernet-original/index.html --CCFreak2K 10:13, 9 July 2006 (UTC)

This one is much more common: http://exponential-e.com/images/technology.gif I have a higher-res version somewhere if I can find it. I'll post it online if I do. -UNHchabo

Here is a higher res from IEEE.org: http://grouper.ieee.org/groups/802/3/ethernet_diag.html I would post this, but I really am not up to figuring how to upload an image. Also, I do not know the copyright implications.

Bridging and switching section

The text talks about "bridges and switches" when they really are the same thing. The question is whether we should use the term bridge or switch? —The preceding unsigned comment was added by 81.235.163.30 (talk • contribs) 16:41, August 27, 2006.

The trouble is that whether they mean the same thing depends on which marketing department you talk to. Yes, the Computer Science definition would suggest that a bridge is a switch operating at the link layer. However, when the first products called "Ethernet switches" were introduced (in the early 1990s), the companies selling them meant many different things, and this confusion has persisted to this day. The three most common versions I remember hearing at that time were:

1. A "switch" is a learning bridge with more than two ports.
2. A "switch" is a learning bridge with more than two ports which can forward traffic on all ports simultaneously, at full line rate, without dropping a frame.
3. A "switch" is a device that connects two or more network segments using a more-complicated forwarding computation than a standard 802.1D bridge.

Of course, the people selling #2 and #3 wanted people to believe that #1 "wasn't really a switch", and for the most part got away with it. The people selling #3 were very insistent that their box wasn't a "router" even when it was operating at layer 3 rather than layer 2, because "routers" were expensive and made by the "C" Entity. Now we seem to have gone back to #1 as the primary definition, but #2 and #3 still seem to have some currency. 121a0012 21:23, 27 August 2006 (UTC)

Mess

Both 10Base-F and FOIRL redirects here, but the article does not explain clearly what they are. --Juliano (T) 21:46, 2 October 2006 (UTC)

I've made them point to Varieties of Ethernet instead; it briefly discusses them. Guy Harris 23:00, 2 October 2006 (UTC)

Wi-fi

Quoth the article:

Even when the PC is connected by Wi-Fi, nearly all Wi-Fi gear uses Ethernet for connecting to the rest of the network.

I thought Wi-Fi transported Ethernet frames around. My Wi-fi router certainly bridges my wired and wireless communication so that it's all one subnet. — ciphergoth 10:52, 9 October 2006 (UTC)

Well, the statement you're quoting doesn't say that Wi-Fi doesn't transport Ethernet frames. What it's saying is that, if you have a Wi-Fi network and an Internet connection, the device providing the Internet connection - at least if it's a broadband connection - probably has an Ethernet jack as its connection to the local network, into which might be plugged a device such as a Wi-Fi router.

As for transporting Ethernet frames, that's a bit of an oversimplification. Bridging doesn't imply directly transporting frames of the bridged type; if you're bridging between two different LAN technologies, some header translation will have to be done as part of the bridging.

Most LAN technologies, including token ring, FDDI, and IEEE 802.11 (i.e., Wi-Fi), use the IEEE 802.2 Logical Link Control protocol; the Media Access Control (MAC) sublayer of the data link layer for those technologies doesn't contain a type field with Ethernet type values, so you need 802.2 or 802.2 plus the Subnetwork Access Protocol (SNAP) to distinguish packets for different protocols running atop those link layers.

Ethernet, however, has a type/length field; values greater than 1500 are type values, so there's no requirement for an 802.2 header in most Ethernet frames. Some protocols do require 802.2 headers, because they don't have Ethernet types assigned to them. If those frames are bridged between Ethernet and other LAN technologies, the raw frame content, complete with the 802.2 header, will be sent over both technologies (the MAC headers will be translated from the format appropriate for one technology to the format appropriate for the other). However, for protocols that don't use 802.2 when run over Ethernet, such as ARP, IPv4, and IPv6, an Ethernet packet will have an 802.2 and SNAP header added to it if it's to be transmitted over another LAN technology; those protocols will probably use SNAP on those other technologies, with the SNAP Organizationally Unique Identifier (OUI) being 0 and the SNAP protocol ID being the Ethernet type value, and the 802.2 and SNAP headers will, in those cases, be removed and the protocol ID will be put into the Ethernet header as the type field. (If the OUI isn't 0, the 802.2 and SNAP headers will be preserved when the packet is bridged.) Guy Harris 17:31, 9 October 2006 (UTC)

Ethernet Switching

Should bridge and switch section expand some more details? Or having one individual switching sub-section will be helpful. Yes CSMACD is fundamental stuff of ethernet, but nowadays switch based ethernet networks are deployed far more than hub based. It is worth to have section as same weight as CSMACD to talk about how Ethernet Switching works, maybe like micro-segmentation spanning tree etc. Lielei 21:25, 15 October 2006 (UTC)

microsegmentation is just a fancy name for reducing segment size to two devices, spanning tree is an advanced feature which afaict is only used on large networks. Plugwash 07:30, 18 October 2006 (UTC)

I think bridge does segmentation which reducing collision domain, whereas the feature of switches is collision free network, that's where microsegmentation stands. SO switches actually create NO collision at all (no place for CSMA-CD) ethernet which I think is quite different with shared media ethernet which depends on very much collision detection mechanism. And if you interconnect switches together, Spanning tree is unavoidable, unless old shared media network you only need to following 4-3-2-1 rule.Lielei 13:54, 18 October 2006 (UTC)

Incomprehensible sentence "likened to the ether"

The article says:

The common cable providing the communication channel was likened to the ether and it was from this reference that the name "Ethernet" was derived.

I am unable to understand this sentence. What does likened mean? And is ether the chemical class?

Please rewrite it.

Velle 07:51, 11 January 2007 (UTC)

Bug in Ethernet Frames

Look at the two pictures representing an ethernet frame, the one with preamble en the one without. In one of them, the ethernet source address and ethernet destination address are mixed up. The one with the destination address first, is the right one. —The preceding unsigned comment was added by 157.193.214.17 (talk) 10:44, 31 January 2007 (UTC).

Suggestion to remove duplicate information

Hi - I have been working on the Ethernet over twisted pair article - specifically the section on Autonegotiation and Duplex mismatch. - I think that I have cleaned it up considerably for brevity and made it more readable - I think a short summary here is ok, but the full details should live elsewhere. That information is replicated in this article. I suggest that this identical section should have only one home. Note that there are also separate articles on autonegotiation and duplex mismatch - too many locations, I think. comments?--Boscobiscotti 21:07, 9 May 2007 (UTC)

Personally i'd say merge the autonegotiation and duplex mismatch articles into the ethernet over twisted pair article and leave a summary here. Plugwash 18:23, 29 May 2007 (UTC)

What Ethernet type is the picture referring to?

This picture is being used by this article. http://en.wikipedia.org/wiki/Image_talk:Ethernet_Type_II_Frame_format.svg

What does it mean Ethernet type 0x8000? I checked a list, there is no such Ethernet type. If it is supposed to refer to IP, then it should be 0x0800. PureRumble 00:54, 30 May 2007 (UTC)

It could be an unpublished ethertype. But in any case, I interpret it as a generic example, not meant to refer to any actual protocol. Paul Koning 10:56, 30 May 2007 (UTC)

Yes ofcourse, and it is just because of 100% purified coincidence that their completely random choice, 0x8000, happened to get so close to the IP type, 0x0800. Methinks this is an error, since this wouldn't be the first problem with this picture. Read its talk-page and you'll see the destination- and source-field had previously been swapped in position. PureRumble 14:37, 30 May 2007 (UTC)

Overhead due to bit-stuffing, block coding, line coding, etc?

How does the bit-stuffing affect the frame size of an Ethernet frame?

Have I understood it correct?

An Ethernet frame consists of maximum 1500 byte payload data + 14 byte header + 4 Byte trailer = 1518 bytes of data. 8 byte preamble is added, resulting in 1526 byte total frame size if no bit-stuffing occurs. In a worst case scenario, where an Ethernet frame only consists of binary 1:s, one extra zero will be inserted after each bit except in the preamble, resulting in an extra overhead of 20%, or totally 1526+1518*0.20 = 1829 bytes and 5 bit per frame. The bit stuffing in average adds one extra bit per 63, except to the preamble, resulting in aproximately 1518/63 = 24 extra Bytes, or totally about 1526+24=1550 bytes. An extra interframe gap corresponding to 12 bytes may also be added to each frame.

Mange01 22:29, 20 June 2007 (UTC)

You're working from an incorrect premise. There is no bitstuffing in Ethernet. Bitstuffing is found in HDLC (and related protocols such as SDLC. Ethernet uses Manchester code for 10 Mb/s, 4B/5B code for 100 Mb/s, 8B/10B code for 1 Gb/s, and a variety of things I don't fully remember for 10 Gb/s. All of these have constant overhead -- 100% for Manchester code, 25% for the others. No bitstuffing or other weird hackery. Paul Koning 01:18, 21 June 2007 (UTC)

In particular, the reason why bit-stuffing is done is that the way HDLC-like protocols mark the beginning and end of frames is that a "flag" bit pattern marks the beginning and end of a frame, the pattern being 0 1 1 1 1 1 1 0, and, to handle the case where a frame includes a byte with that value (hex 7E), if five 1 bits appear in a sequence in the data being assembled into a frame, a 0 bit is inserted (and removed on the receiving end), so the only way six 1 bits should appear in the bit stream transmitted with HDLC would be if a "flag" pattern is being transmitted.

Ethernet uses different schemes to delimit frames. The scheme used depends on the particular type of Ethernet being used; however, none of those schemes involves a "flag" bit pattern, so no form of bit-stuffing is required. Guy Harris 07:51, 21 June 2007 (UTC)

Thankyou friends for this helpful information. What about the overhead for block coding? Is it correct that the data rate of 10 Mbit/s, 100 Mbit/s, etc, should be considered as a net bit rate, excluding all physical layer channel coding overhead? Any idea about the gross bit rate?

I suppose the channel coding (Manchester and oterhs), should not even be considered as part of the gross bit rate, but adds 100% or 25% to the analogue signal bandwidth. Mange01 10:32, 21 June 2007 (UTC)

That's correct. The Ethernet data rates (10 Mb/s etc.) are actual payload data rates. If you want to describe the coding overhead, the term would be Baud rate. So 10 Mb/s Ethernet is 20 MBaud (though I've never seen it put that way), 100 Mb/s Ethernet is 125 Mbaud, and so on.

By the way, various other high speed protocols do not follow this practice, and speak of speeds in Mb/s when they are actually giving you MBaud. In other words, the numbers you see are inflated by 25%. Fibre Channel, Serial ATA and several others are most commonly quoted this way, so you might see "1 gigabit" Fibre Channel which is in fact 1.0625 GBaud, or 850 Mb/s. Similarly, SATA is 3 GBaud, not 3 Gb/s. Both use 8B/10B coding so the coding overhead is 25%.

And finally, sometimes there is much more complex coding going on to complicate things; gigabit Ethernet over unshielded twisted pair (1GbaseT) is an example. You can speak of "Baud rate" there but the answer isn't at all obvious. Paul Koning 10:59, 21 June 2007 (UTC)