Talk:Ethernet/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Official logos?

Are there any official logos for the various versions and types of ethernet, like there are for Firewire and USB? Or did nobody think of things like that in the 1970's? —Preceding unsigned comment added by Bizzybody (talk • contribs) 07:05, August 27, 2007 (UTC)

Not that I know of. One difference between Ethernet and the others you mentioned is that those others are semi-proprietary, owned and marketed by industry consortia. Ethernet was an open standard from day 1. As I understand it, the name was at one time a trademark of Xerox, but it was released into the public domain around the time the first Ethernet standard came out. (I don't have a reference for that; it would be interesting to try to track that down.) Paul Koning 13:53, 27 August 2007 (UTC)

Broken link?

The ACM classics page appears to no longer list the original ethernet paper. —Preceding unsigned comment added by 130.217.250.13 (talk) 01:21, 25 September 2007 (UTC)

"Dealing with multiple users" confusing/misleading

The first part of this section "CSMA/CD shared medium Ethernet" cofuses me. It begins "Ethernet originally used a shared coaxial cable... (CSMA/CD) governed the way the computers shared the channel..." and then carries on in the past tense (apart from the final paragraph oddly enough).

It implies that the CSMA/CD method is no longer used and then provides no information on the currently used method of dealing with multiple users :/

Is it just bad wording?

Thanks in advance.

Cre8tor 20:35, 28 October 2007 (UTC)

Coax is pretty much obsolete -- it only suppors the original 10 Mb/s version of Ethernet, and it is inconvenient to install. CSMA/CD carries over into the predominant twisted pair version of Ethernet, though. While switches (bridges) are now very common, Ethernet hubs still exist. If you have one of those, then you're using CSMA/CD. Paul Koning 13:49, 29 October 2007 (UTC)

Quoted from the article

"Despite the physical star topology, hubbed Ethernet networks still use half-duplex and CSMA/CD, with only minimal activity by the hub, primarily the Collision Enforcement signal, in dealing with packet collisions. Every packet is sent to every port on the hub, so bandwidth and security problems aren't addressed. The total throughput of the hub is limited to that of a single link and all links must operate at the same speed."

"When a twisted pair or fiber link segment is used and neither end is connected to a hub, full-duplex Ethernet becomes possible over that segment. In full duplex mode both devices can transmit and receive to/from each other at the same time, and there is no collision domain."

So if you keep reading it does indeed explain how multiple users are dealt with nowadays. Plugwash 20:34, 29 October 2007 (UTC)

TP hubs are little computers with multiple NICs

"When a twisted pair or fiber link segment is used and neither end is connected to a hub, full-duplex" is nonsense. A hub is like a PC with multiple NICs in crossover mode and set to forward packets. Half duplex is required on coax, not with separate receive and transmit twisted pairs. Some older NIC chips were too slow or not enough ram or bad drivers, ran half duplex. Again, the TX/RX wires don't touch, collisions are actually handled in Hub firmware.

Shjacks45 (talk) 17:27, 9 December 2007 (UTC)

Sorry, but you're mistaken. A hub is not a computer; it's an Ethernet repeater. An Ethernet with repeaters runs in half duplex mode, always. Also, half duplex has nothing to do with "too slow" NIC chips; it's one of the two operating modes of Ethernet (the original one). Please see the Ethernet standard for more details. Paul Koning (talk) 00:50, 10 December 2007 (UTC)

correct "related" 100BaseVG

Actually 100Base-VGAnylan was a Hewlett-Packard token passing protocol. Wiki on IEEE 802.12:"100BaseVG-AnyLAN technology developed by Hewlett Packard, which uses the demand priority access method." 'Overview of IEEE 802.12 Demand Priority'

Shjacks45 (talk) 17:59, 9 December 2007 (UTC)

Interesting. The article doesn't call it "token passing". It was originally proposed as a faster Ethernet (competing with 100BaseT, which came out the winner) so it certainly is related in that sense. Calling it "token passing" would have been a marketing mistake even if it's technically correct (which I'm not convinced about) -- it would make it sound like 802.4, which was even back then obviously a complete dead end. Paul Koning (talk) 00:55, 10 December 2007 (UTC)

looking for DLC??

win31/win95 to print to HP JetDirect Card network printers directly you had to install HP Jetadmin printing client and "DLC" protocol. ref MS KB Q117629 Q119068 Q94084 Q96623 but most 9x and w31 stuff deleted. If you've an old CD, the (Q146238)Admin.doc file included with Microsoft

Windows 95 Service Pack 1 (has IE 2.0): "Microsoft 32-Bit DLC Protocol 

for Windows 95", about access to IBM SNA stuff. IBM incuded it with OS/2. Also listed by HP as DLC/LLC.

DLC is seminal in that it is a MAC address to MAC address protocol. Frustrating that documentation for old software disappears. However in setting SNA connectivity up on a reinstall, some NIC cards worked (like 3com) and some (ne2000 clones) didn't until Microsoft Netbeui was added. TID and MS docs said it was missing functionality in NIC firmware.

Shjacks45 (talk) 21:32, 9 December 2007 (UTC)

802.11

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? —Preceding unsigned comment added by Patcat88 (talk • contribs)

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)

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)

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)

"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?" collision detection is also important on hub based ethernet which is still pretty common on existing installations. Plugwash (talk) 21:55, 22 February 2008 (UTC)

I agree! Electron9 (talk) 22:19, 22 February 2008 (UTC)

Preamble and SFD was incorrect

The article originally stated that the preamble is 7 octets of 01010101 and the SFD is 11010101. The correct preamble is 7 octets of 10101010 and the SFD is 10101011. I have modified the article to reflect this. http://docs.hp.com/en/98194-90053/ch02s04.html confirms this. —Preceding unsigned comment added by Blutrot (talk • contribs) 05:58, 2 January 2008 (UTC)

Is that "10101010" and "10101011" in the sense that the preamble and SFD go onto the wire as 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1? If so, that means that the actual octets of the preamble are 0 1 0 1 0 1 0 1, at least as I interpret 3.3 "Order of bit transmission" in IEEE Std 802.3-2005, which says "Each octet of the MAC frame, with the exception of the FCS, is transmitted low-order bit first." Or is that "10101010" and "10101011" in the sense that those are the octets, so that the preamble and SFD go onto the wire as 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 0 1 0 1? Guy Harris (talk) 09:16, 2 January 2008 (UTC)

Yes. The source of the problem is that IEEE 802 writes octets with the LSB on the left. In other words, you have to read them as bitstrings, not as numeric values.

When dealing with bit patterns that aren't really numeric values -- like the preamble/SFD -- this is confusing but at least not completely nuts. It gets worse, though, when you try to make sense out of the LLC standard (802.2). It deals very clearly with octets, and in fact those are transmitted in whatever order the specific MAC used transmits them. But still they are written LSB first.

Paul Koning (talk) 12:04, 2 January 2008 (UTC)

I will review some more documentation and attempt to make sense of what actually goes on. On nodes (not switches) running 10BASE-T and 100BASE-TX, pins 1 and 2 are used to transmit while pins 3 and 6 are used to receive. Perhaps it would make sense to say pin 1 transmits X and pin 2 transmits Y (x and y being whatever they transmit) 31 times, followed by pin 1 and 2 both transmitting 1 once. Although, this isn't as helpful with 1000BASE-T which uses four wires to transmit and receive.

Blutrot 18:33 2 January 2008 (UTC)

I tested with Preamble=0101 and SFD=1101 (as 4'b1101 in verilog):

       0x0000:  ffff ffff ffff 1234 5678 9abc 0000 1083  .......4Vx......
       0x0010:  4567 6767 6767 6767 6767 6767 6767 6767  Eggggggggggggggg
       0x0020:  6767 6767 6767 6767 6767 6767 6767 6767  gggggggggggggggg
       0x0030:  6767 6767 6767 6767 6767 6767 c948 5581  gggggggggggg.HU.

And with Preamble=1010 and SFD=1011

       0x0000:  4567 6767 6767 6767 6767 6767 6767 6767  Eggggggggggggggg
       0x0010:  6767 6767 6767 6767 6767 6767 6767 6767  gggggggggggggggg
       0x0020:  6767 6767 6767 6767 6767 6767 467a 1c70  ggggggggggggFz.p

Both packets are sent out identical with the exception for an incremental 32 bit counter value, and the 32 bit crc. I have also verified that 4'b1000 sent to PHY will set TXD3=1 and the rest =0 etc.. I think the conclusion must be that the use of 0101 and 1101 with MSB at leftmost position is the correct ones. The only reason for the HP values must be they are using LSB at leftmost position.

As for TX pins, they are differential, so pin 1 transmitts X, then pin 2 transmitts the opposite of X to produce the differential signal. X usually being a voltage in the 3.3V range. 1000Base-T uses signal cancellation schemes to make simultaneous tx & rx work. Electron9 (talk) 19:08, 2 January 2008 (UTC)

Ok, so I got confused. The IEEE 802.3 spec is the authority here. (FWIW, the HP doc has the same pattern but without the explanation to make it intellegible.) The preamble is 101010... with the leftmost bit sent first. (It even adds "It should be noted that the preamble ends with a '0'.") And the SFD is 10101011 again with the leftmost bit sent first. So you have to read them as bitstrings, not as binary integers.

If you want to write everything as octets (binary 8-bit integers) then you'd reverse the strings because LSB is sent first in Ethernet -- and that brings you to the text in the article as it stands right now.

Paul Koning (talk) 20:21, 2 January 2008 (UTC)

Interestingly enough the description of what the SFD looks like for 100 Mb Ethernet was wrong, since the nibble order is low to high. Fixed. 20:25, 2 January 2008 (UTC) —Preceding unsigned comment added by Paul Koning (talk • contribs)

One could argue that Ethernet is little endian :-)... (hello Intel?). Anyway, any link to that IEEE 802.3u document that you reference too?, IEEE isn't letting people have it easily. Electron9 (talk) 21:21, 2 January 2008 (UTC)

I see what you are saying. I apologize for the confusion this caused in the article. Thank you for all of your insightful comments.

Blutrot 23:15 2 January 2008 (UTC)

802.3u was the Fast Ethernet spec, according to the IEEE 802.3 page. The IEEE does, in fact, make it harder to get old standards than current ones - the older standards aren't directly available from the Get IEEE 802 page, but that page points you to ShopIEEE for "New, Superseded, and Withdrawn standards".

802.3u's contents are probably mostly if not entirely found in the current 802.3 standard; see 802.3-2005 section 2 (the standard is in 5 separate PDFs on the Get IEEE 802 site). Guy Harris (talk) 23:36, 2 January 2008 (UTC)

Exactly. In fact, all of the 802.3 standards are there. What's been retired is the individual titles as separate documents, not the substance. And they are free -- so they the ideal sources to cite in this article... Paul Koning (talk) 11:58, 3 January 2008 (UTC)

looks like 802.3 IEEE standard is available for download free IEEE 802.3 part 1 page 50.

"The SFD field is the sequence 10101011. It immediately follows the preamble pattern and indicates the start of a frame."

also page 105 states

"The preamble pattern is: 10101010 10101010 10101010 10101010 10101010 10101010 10101010 The bits are transmitted in order, from left to right"

My suggestion is to follow the standard - and display the byte pattern Kevmcs (talk) 23:21, 27 January 2008 (UTC)

The problem with just following the standard is that the standard is seriously and unnecessarily confusing. I restored the "byte wise" way of showing the pattern, but added a paragraph explaining that the IEEE standard has it the other way around. One reason for showing it byte wise is that it's the only way to make sense out of what happens in the 100 Mb/s (4b/5b code) or faster (8b/10b code) transmission. Paul Koning (talk) 23:37, 27 January 2008 (UTC)

The bit pattern end with 11 is important to display as last 2 bits of the eight byte are always consecutive 11. Even if the preamble had been corrupted, the following destination address can be identified correctly. The table needs to reflect that the last two bits are 11. The authoritative source is 802.3 IEEE standard, and we need to source it and table should reflect it Kevmcs (talk) 23:56, 27 January 2008 (UTC)

Introduction year & Name in all caps..?

Paul!

• ) Should the pre 3 Mbps LAN networks count as "ethernet" which were introduced in 1980, or should one define it as a minimum 10 Mbps LAN that were introduced first in 1985 ..?

• ) Is there any official standard that backs up the claim that the standard names, like 10BASE5 etc. Should be in all uppercase ..?, anyway I find it much more readable in 'Base' format rather than 'BASE'.

Electron9 (talk) 17:53, 22 February 2008 (UTC)

In answer to the first question, given that the paper "Ethernet: Distributed Packet Switching for Local Computer Networks" describes a 3 Mbps LAN, I'd say that the term "Ethernet" covers such a LAN. However, that LAN wasn't compatible with DIX Ethernet (the source and destination addresses were 8 bits and LAN-specific, rather than 48 bits and universal), so, while it is a form of Ethernet, it should be noted as being a different form of Ethernet from the DIX Ethernet and 802.3 Ethernets that succeeded it.

In answer to the second question, yes, there is an official standard which calls them "10BASE5", "10BASE2", "10BASE-T", "100BASE-T", etc. - it's called IEEE 802.3-2005. Guy Harris (talk) 18:37, 22 February 2008 (UTC)

About year of introduction -- the Ethernet V2 spec is dated 1982. I believe that's the document that established the Ethernet standard and started the stream of products. I'm not sure what's in the V1 document or how it differs. As for the 3 Mb/s Ethernet, that certainly was called Ethernet, but it wasn't a product, only a research prototype at Xerox PARC. So when speaking of Ethernet as a commercial technology, my inclination is to use 1982 as the start year. To make the picture complete, it would make sense to discuss the research stage work, which includes the 3 Mb/s version. Paul Koning (talk) 15:56, 25 February 2008 (UTC)

Split the article in 'Ethernet I' and 'Ethernet II' then ..? (or how to deal with this?) Electron9 (talk) 16:58, 25 February 2008 (UTC)

No, just leave the article as it is, with the Xerox experimental Ethernet mentioned in the History section. That is part of the history of Ethernet. Guy Harris (talk) 18:18, 25 February 2008 (UTC)

Duplication

Ethernet#Autonegotiation_and_duplex_mismatch and Ethernet_over_twisted_pair#Autonegotiation_and_duplex_mismatch contain a lot of duplicated text and should be merged. JonathanWakely (talk) 14:34, 6 March 2008 (UTC)

Link Aggregation and Redundancy

I have deployed some Extreme Networks equipment that allows deploying 802.3ad (or any aggregation) over multiple physical switches in a stack. We utilize this redundancy to great effect. I don't know where I would find a citation for this, though, since their documentation isn't public and doesn't explicitly claim that it works anyways. I've heard that Ciscos do the same thing, although I haven't found any documentation of it. —Preceding unsigned comment added by Kagato (talk • contribs) 21:55, 19 August 2008 (UTC)

Picture of Cable

The picture at the top of the article is labelled "A standard RJ45 Ethernet cable". However the connector is more correctly a 8P8C modular connector. The Physical layer section confirms this "...used twisted pair connected to Ethernet hubs with 8P8C modular connectors (not to be confused with FCC's RJ45).".

I thought I'd mention it here rather than just go ahead and change it. —Preceding unsigned comment added by Mdt3k (talk • contribs) 13:45, 26 September 2008 (UTC)

Noticed this as well this evening (er... morning). Went ahead and changed the caption. -Kgasso (talk) 11:05, 29 November 2008 (UTC)

None of the wp articles that claims that rj45 and 8p8c should not be confused gives any literature reference. I think these articles need a couple of references. See a Google Books search. Mange01 (talk) 23:44, 29 November 2008 (UTC)

10G

"Ten-gigabit Ethernet is still an emerging technology, and it remains to be seen which of the standards will gain commercial acceptance."

It's been installed in my local datacentre for 2 years now. It was probably first commercially available a year or so before that. It's a mainstream technology, soon to be superceded, or at least supplemented by 40G or 100G technologies. Yes, things do move that fast in the technology world.

If the author means to say that the volume of 10G ethernet ports installed is still very low, when measured as a percentage of the total installed bease of Ethernet technologies, then that's a different point. "Emerging" suggests experimental, bleeding-edge (untested, unstable), or special-purpose.

Fgtbell (talk) 08:57, 22 December 2008 (UTC)

CRC field

Does the CRC field only check the header, or also the data? My guess would be only the header, but someone should verify this and add it to the article. Aphexer (talk) 10:58, 7 January 2009 (UTC)

The CRC is created using the source & destination addresses and type fields in the header in addition to the data field. You may be thinking of the IP checksum which only checks the IP header's integrity. 142.55.55.185 (talk) 19:35, 21 February 2009 (UTC)

The CRC is part of the trailer, in the end of the frame after the payload data, because it is based on the whole frame. This simplifies the calculation concurrently as the packet is transmitted. However, CRC:s that are part of the header are not always based on only the header. In the UDP and TCP case, the CRC is based on the whole packet, but is part of the header. Mange01 (talk) 22:43, 21 February 2009 (UTC)

Incorrect of the word "Ethernet"

There's no such thing as "Ethernet" cable or "Ethernet hubs" even though many manufacturers label their equipment this way. Ethernet may define the necessary hardware standards, but it does not define the hardware itself. Ethernet can be used on any layer 1 device that supports the necessary signal carry; hubs/repeaters and cables do not read the addresses. Thus, the misnomer. Layer 2, however (such as a switch), is another story as this equipment does read addresses. —Preceding unsigned comment added by 173.18.21.137 (talk) 02:40, 25 February 2009 (UTC)

Ethernet for test and measurement instrument communication

The LXI instrumentation platform combines Ethernet-enabled instrumentation with the virtually universal availability of World Wide Web access and applies them to test and measurement applications. The LXI Standard, which is maintained and promoted by the LXI Consortium, an industry consortium that works to ensures the interoperability of LXI compliant instrumentation. The standard defines modular instruments using low-cost, open-standard LAN (Ethernet) as the system backbone. LXI supports synthetic instruments and peer-to-peer networking, enabling some unique capabilities not presently available to the test engineer in any other format. LXI’s flexible packaging, high-speed I/O, and standardized use of LAN connectivity address a broad range of commercial, industrial, aerospace, and military applications. LXI modules can have no front panel or display, using the host PC and Ethernet connections to present setup and results.

The LXI Standard is continuously evolving to take advantage of evolving LAN capabilities. Version 1.3 (released October 30, 2008) incorporates the 2008 version of IEEE 1588 for synchronizing time among instruments, so systems using LXI Class A and Class B devices will synchronize with each other based on the 1588-2008 Precision Time Protocol (PTP) standard. The Consortium also offers information on System Tests for LXI Devices implementing IEEE 1588-2008.

</nowiki>

Nuβiατεch ^Talk 03:03, 19 May 2009 (UTC)

Start Class..?

Why is this graded a Start Class article ? I am under the impression that is is good enough to be a B...Rkr1991 ^{(Wanna chat?)} 12:59, 10 November 2009 (UTC)

preamble 7Bytes?

in the section Physical layer the preamble is represented as 7 times 10101010, but doesn't the preamble also include the Start-of-Frame-Delimiter and thus is 8 bytes big?

my reference is the book Computer networking, a top down approach section 5.5.1 the structure of an Ethernetframe --OCELOT525 (talk) 22:26, 23 December 2009 (UTC)

It is always considered separately in all the sources I have seen. Most discuss 802.3 framing in comparison with ethernet II framing where the former is described as seven bytes preamble and a start of frame delimiter, and contrast this with the ethernet II frame which has no delimiter and an eight byte preamble. Therefore, assuming you do have the delimiter, then yes the preamble is seven bytes. CrispMuncher (talk) 22:38, 8 February 2010 (UTC)

Merge discussion

Significant overlap exists with the Ethernet over twisted pair article and to a lesser extent with the Fast Ethernet and Gigabit Ethernet articles. I've recently cited these as main articles from here. I think this works reasonably well. I do propose merging Ethernet over twisted pair into this (Ethernet) article. Discussion on this proposal and the more general topic of organizing Ethernet-related articles is solicited. --Kvng (talk) 01:06, 21 March 2010 (UTC)

I have to oppose such a merger as Ethernet is already reaching the typical size limits for splitting off sections into separate articles. Ethernet over twisted pair covers twisted pair pretty well, and we also have 10BASE2 for thinnet and 10BASE5 for thicknet. All three of these are proper spinout/subtopic articles and there are still others in this subject hierarchy as well. Trying to merge these into the parent article makes little sense at this point. --Tothwolf (talk) 01:23, 21 March 2010 (UTC)

I agree that Ethernet is getting large. Some editing is required. Because of the extent of duplication, I don't think the proposed merge would make it significantly larger. In any case, I think the Ethernet over twisted pair article, if it survives needs to be made to be more like 10BASE2, 10BASE5, Fast Ethernet, Gigabit Ethernet and 10 Gigabit Ethernet. Once overlapped information is removed from Ethernet over twisted pair, what remains is 10BASE-T, really. Interesting considering that 10BASE-T currently redirects to Ethernet over twisted pair. --Kvng (talk) 03:56, 21 March 2010 (UTC)

Well, that is still a bit of a can of worms. We might be able to justify a separate 10BASE-T article, or even use a section redirect for 10BASE-T to something like 'Ethernet#10BASE-T' but we technically should still have an ethernet over twisted pair article that covers the topic in the generic sense. For example, 10BASE-T, 100BASE-TX, and 1000BASE-T are all forms of ethernet over twisted pair. --Tothwolf (talk) 10:03, 21 March 2010 (UTC)

The current ethernet over twisted pair article could actually stand to be expanded as there are other forms of ethernet over twisted pair not covered by the IEEE 802.3* standards, such as AT&T StarLAN and Synoptics LattisNet. The reality of it is you could even argue that power over Ethernet is partly a subtopic of ethernet over twisted pair since the majority of PoE applications use UTP cabling. We also have an Ethernet over coax article (which needs some major expansion). It currently lacks coverage of 10BASE2 and 10BASE5, and should contain a lot more information on the various systems that were not covered under the IEEE standards. Also see "LAN wiring" by James Trulove ISBN 0-07-145975-8 pg 42 [3] as well as [4] [5] [6] --Tothwolf (talk) 10:33, 21 March 2010 (UTC)

So you want to keep and Ethernet over twisted pair. What is your proposal for reducing the amount overlap between Ethernet over twisted pair and this (Ethernet) article. As I understand it you are suggesting a 3-tier organization with a typical path being Ethernet -> Ethernet over twisted pair -> Fast Ethernet. I think two tier is enough. Ethernet is too long because there's a lot of unnecessary detail, not because it is a particularly complicated topic. Anyone else care to weigh in on this? --Kvng (talk) 15:09, 21 March 2010 (UTC)

I prefer not to try to look at it as a tier-based organisation because trying to outline large topics in tiers doesn't work well for wikis. I prefer to picture it as more of a collection of related topics and concepts which are interlinked and refer to one another. Ethernet of course should give a general overview to the main subject. Ethernet over twisted pair should give an overview and detail the general concept of ethernet networking via UTP and STP cabling. Articles like Fast Ethernet should give an overview and the details of that particular subtopic. You are going to have some overlap between some articles because you should still be able to read say Ethernet over twisted pair and be able to understand the concept without having to read Fast Ethernet (unless you wanted more detail about that particular subtopic). If you try to use a tired method of organisation then even things like TIA/EIA-568-B and IEEE 802.3 become confusing in how all of these subjects and concepts are interrelated. It seems that the main problem we have with this huge collection of related articles is organisation, not really that we have too much detail. For example, some of the material in Ethernet most likely should be split from the parent article and moved/merged into the articles that cover individual subtopics in more detail. If you already have a subtopic article linked via {{main}}, then one or two paragraphs giving a summary and overview in the parent Ethernet article should suffice. --Tothwolf (talk) 17:23, 21 March 2010 (UTC)

Does the amount of overlap between Ethernet over twisted pair and Ethernet look about right to you? --Kvng (talk) 18:57, 21 March 2010 (UTC)

Not really. I really don't see a summary of the Ethernet over twisted pair concept in the Ethernet article. All of these articles need a lot of work IMO but I've been unsure where to begin myself. I previously had been working on parts of Modular connector and Registered jack (and related articles) as those directly tie in with Ethernet over twisted pair. --Tothwolf (talk) 11:46, 22 March 2010 (UTC)

I don't see much of a reason to keep Ethernet over twisted pair at all. There is no corresponding Ethernet over fiber optic or Ethernet over coaxial articles, although admittedly they are somewhat less common implementations than twisted pair. None of the information in Ethernet over twisted pair is unique; it all appears in articles such as Ethernet, Fast Ethernet, Gigabit Ethernet, Category 5 cable, TIA/EIA-568-B, etc. So, Ethernet over twisted pair is almost acting as a category index page; a page that readers can go to find specific articles on common Ethernet physical layer implementations. Perhaps there is an argument to keep it so that it can serve exactly that purpose, however in its current state it doesn't do a very good job. SnottyWong talk 16:40, 28 March 2010 (UTC)

That doesn't change the fact that "ethernet over twisted pair" is an extremely important concept within Ethernet and as such absolutely should have an article which covers it. We actually do have an Ethernet over coax article which I linked above, although like Ethernet over twisted pair, it needs major expansion. As it stands now it doesn't cover 10BASE5 or 10BASE2 at all. Just because we don't currently have a summary style article which covers Ethernet over optical fiber doesn't mean we shouldn't, it just means no one has written one. We have a very short 10BASE-FL article and lack articles such as FOIRL, 10BASE-F, and those that could cover the many 100BASE-* optical fiber technologies. The Ethernet article should be restructured to be more of a summary style article as it currently contains information which can be split/merged into separate articles. Ethernet over twisted pair#Autonegotiation and duplex mismatch is also summary style. This really is not all that unusual for a huge topic like Ethernet. Articles such as Ethernet physical layer#Ethernet over twisted-pair cable already link to Ethernet over twisted pair in a summary style. --Tothwolf (talk) 17:20, 28 March 2010 (UTC)

I agree completely, with the ever changing nature of networks and the advancement of technology, merging the information into one document will eventually create a page that is to large to find any information. As with most books on the subject, there is an overview section (which does cross over into the varying technologies) and then there are more detailed sections which explains in depth how it all works. I would say keep the articles seperate, develope the existing articles further and create articles to provide information on the older and newer technologies and then link between them 132.185.144.122 (talk) 14:32, 9 April 2010 (UTC)David Ford 9th April 2010 14:31 GMT132.185.144.122

Sounds like we should push all non-summary information out of the Ethernet article and into the other articles. Sections affected would be Autonegotiation and duplex modes and a bunch of stuff in Physical layer. In this context, it would also be nice to find a new home for CSMA/CD shared medium Ethernet and Ethernet frame types and the EtherType field --Kvng (talk) 17:36, 9 April 2010 (UTC)

I discovered that Ethernet physical layer had a copy of this whole section. I merged information from the section into Ethernet physical layer and jacked a bit of the intro from that article for the new body of this section. Ethernet over twisted pair advocates please note that Ethernet physical layer references Ethernet over twisted pair with Template:Main. We now have two Template:Main references to Ethernet physical layer. That's a blemish that I'll have to remove another day. --Kvng (talk) 16:08, 23 April 2010 (UTC)

Merged from Full-duplex Ethernet

I know Ethernet was getting big enough, but that article really deserved a merge in a big way. Publicly Visible (talk) 02:05, 28 March 2010 (UTC)

I edited this (on 28 March 2010) for better flow and reduced length --Kvng (talk) 17:39, 9 April 2010 (UTC)

Deletions of content

I am a bit perplexed by the recent deletions of the single mentions of 10base5 and 10base2 versions of Ethernet. Kbrose (talk) 06:39, 31 July 2010 (UTC)

I'm most of the way through my first pass executing the plan described above. I'm trying to keep the article from getting bogged down by too much history and detail. 10BASE5 and 10BASE2 are featured prominently in Ethernet physical layer. If you think I'm being to aggressive, feel free to jump in and help. Ethernet#Shared_media might be a good place to restore these links if you feel they're necessary. --Kvng (talk) 14:07, 31 July 2010 (UTC)