Talk:Ethernet

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Plugwash (talk | contribs) at 20:41, 8 June 2006. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Jump to navigation Jump to search

CSMA/CD algorithm incorrect?

Moved from Earlier Remarks:

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)[reply]

Earlier Remarks

I have seen 100base5 (100mbit thicknet) beeing refered to in the manual of my IBM rs/6000 unix machine, and when searching around the web it seems to really exist. Does anyone know more which they can add in the article?

Gah, what a mess. Should it be 100baseTX or 100BaseTX? We have both. -- ansible

I think it should be 100BaseTx. Wesley

No, we already have 10base2, 10base5 and 10baseT

None of the above. These designations are so often misquoted, but they are correctly 10BASE2, 10BASE5 and 10BASE-T
Similarly 100BASE-TX, 1000BASE-SX, etc.
I would correct the article now, but I'm not feeling up to learning how to rename all the relevent articles and create redirects. I would confirm, however, that I have as I type this a copy on my lap of the official IEEE Ethernet standard (2000 edition) -- all 1515 pages of it -- and I have verified the above designations against it. The general rule would appear to be that the designations are entirely uppercase, with no punctucation, except that if BASE is followed by an alphabetic (rather than numeric) designation, it is separated by a hyphen. I believe there are other minor errors in the article, I will come back to this when I have time. -roy
Ok I think I've done this right, I've fixed up the ones I've found, though there may well be others. As to whether we really need a separate entry for every flavour of ethernet, I'll leave that up to someone else... -roy
Also note that there is no hyphen between 10G and BASE in the 10Gbps standards, eg 10GBASE-SR -roy


The frame format stuff needs checking, as it is severely confusing even with references open in front of me!


There is so much more to write about here: AUIs, heartbeats, spanning tree, VLANs, G Ethernet and its relationship to Fiber Channel, 10G Ethernet and its relationship to SONET...

I now added a "See also" section and listed some of the terms. Gigabit Ethernet and 10 Gigabit Ethernet have their own pages, so Fiber Channel and SONE should be mentioned there (SONET already is, very shortly). Colin Marquardt

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)[reply]

Other issues

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 removed the link to "Wireless Ethernet"(aka 802.11 aka WiFi) in the "Related Standards" section. It stated that 802.11 uses the Ethernet headers(which is false) and that 802.11 is interoperable with Ethernet(which is ridiculous -- how can a standard for wired communication with interoperable with a standard for wireless communication?)--Ryan Stone 18:13, 25 Nov 2004 (UTC)

Wrong, to the OS, 802.11 is ethernet with ethernet frames, turn on network bridge in WinXP to see, or you can explain how on earth this [1] and this [2] possible?
There are a lot of networking technologies (like Ethernet, 802.11, Token ring, etc.), and a plethora of devices for converting from one to another, allowing them to interoperate. But without some kind of bridge to convert the media and frame types, devices using these different technologies can't communicate. And the bridging can get tricky; consider that 802.11 allows longer frames than Ethernet does, and that 802.11 must use IEEE 802.2. --Rick Sidwell 22:25, 12 Feb 2005 (UTC)
802.11 is not ethernet with ethernet frames to the OS. This is a feature of the NIC driver, or as with Windows and its miniport drivers, it's a function of the 802.11 MAC-layer driver in NDIS. The NDIS spec states that the the MAC-layer driver should present NDIS with 802.3 frames, thus it performs a conversion. If one has a driver with so-called monitor mode support, this functionality can be turned off. EOD :-) --Gosub 13:08, 24 Jun 2005 (UTC)
802.11 was designed to serve as a wireless extension to Ethernet rather than as a fully independent and competing standard, so it's not inaccurate to refer to it as Wireless Ethernet. There is so much historical crap in this article about Coax Ethernet that it's probably best not to make it any longer than it already is.

I mean, given that nobody has used a coax-based Ethernet for ten years, why not take all this collision detection crap and move it to another article? RichardBennett 02:54, 4 June 2006 (UTC)[reply]

I beg to differ. There were still buildings at MIT using thicknet as recently as three years ago (and may still be for all I know); there are probably many academic institutions where this was the case. But you are probably right that this discussion should probably move to a History of Ethernet article. 121a0012 03:02, 4 June 2006 (UTC)[reply]
I've personally never encountered thicknet. Thinnet on the other hand was arround much more recently and i know at least one person who still runs it today. In any case hubs (which are still sold new) still rely on that collision detection capability and i know of a recently released embedded ethernet controller that doesn't support autonegotiaton (limiting it to half duplex if the other end is an unmanged switch). Full duplex may be becoming more common but CSMA/CD will be with us for some time yet. In summary you can't really understand hubs without understanding the shared medium and to only describe switched ethernet would produce a hugely distorted picture even of current ethernet practice. Plugwash 08:10, 6 June 2006 (UTC)[reply]

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)

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)[reply]

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.

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)[reply]

Pronunciation dispute

According to most online dictionaries that I have reviewed, the standard pronunciation is with accent on the initial long "E". There does appear to be a conventionally used alternate pronunciation with the accent on the "eth" with a short "e". However this only applies to the generic use of the word, since the trademarked name uses the former pronunciation.

Since this is a somewhat disputed point, the least-contoversial approach is just to leave this out, since pronunciation is not typically included in Wikipedia articles (this is better handled in Wiktionary). If the point of dispute is important enough to include, it should at least address the commonality of both forms of pronunciation, support any assertions, and use IPA pronunctiaton markup as described in article: http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28pronunciation%29

can token ring be briged to ethernet?

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

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

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)[reply]

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)[reply]
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)[reply]

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)[reply]

Realtime Ethernet Issues

Does it make sense to include a chapter about Realtime Ethernet here?

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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?

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)[reply]
[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)[reply]
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)[reply]
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)[reply]

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

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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]
Dont merge, information will be lost. Each generation of ethernet should have its own article.Patcat88 14:17, 26 March 2006 (UTC)[reply]
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)[reply]

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)[reply]

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

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)[reply]

Re-arrangement would increase readability

I suggest that if one has some spare seconds, moving the general information like history on the top would be a good idea. That way, when someone who isnt technically oriented ends up on the article, he or she can read the history section before moving along.

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)[reply]

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)[reply]
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)[reply]

alternatives

how about Myrinet or InfiniBand ???

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

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Ethernet&oldid=57587023"