Talk:Ethernet

total length

For signal degradation and timing reasons, coaxial Ethernet segments have a restricted size. Somewhat larger networks can be built by using an Ethernet repeater. Early repeaters had only two ports, allowing, at most, a doubling of network size. In the early days, thick coaxial cables of up to 500m and FOIRL links were used. Within the timing limits you can chain them, allowing for somewhat bigger than doubling the 500m size. Does size mean physical size or the number of taps (hosts)? In the latter case, you can connect many repeaters between a backbone cable and branch cables, for a really large number of hosts. Gah4 (talk) 18:49, 5 October 2016 (UTC)

This is a network diameter restriction required for collision detection to work reliably. Network diameter is the longest cable distance between any two nodes on the network. ~Kvng (talk) 16:03, 25 March 2020 (UTC)

The limit is for two nodes on a segment (OSI Layer 1). The network can be bigger than that, but the links need to be switches or bridges, not merely a packet-level repeater. Andy Dingley (talk) 17:11, 25 March 2020 (UTC)

Just to hop out of the weeds here, the limit is on physical size. Certainly there is some practical limit, but I'm not aware of a design-rule limit on the total number of nodes for this type of Ethernet. ~Kvng (talk) 17:02, 28 March 2020 (UTC)

There are limits on the number of taps on the coaxial segments. I did once see an 8 port (BNC) repeater, but not more than that. With 24 port repeaters, you could get pretty many on coaxial cables, though watch out for knots. Gah4 (talk) 18:42, 28 March 2020 (UTC)

• There's no hard limit on the number of taps, it's about the total losses. As some types of tap were lossier than others, that varied.

Around 1990, I was working for a well-known connector manufacturer. Like many, they had invented a no-break 10base2 connector, with two BNCs and a flat pluggable tongue in the middle. Mechanically, it was excellent. They were a connector maker who knew all about reliable contacts. Seems they knew less about RF design though. Turns out these things had about six times the insertion loss of a normal T piece. They worked fine across one desk, but use more than a handful of them on a segment and it stopped working. Although instructed to "eat our own dogfood", I had to quietly lose all of them one night to make the network reliable again.

The size limit is a physical size limit, based on timing and signal propagation time down RG-58.

There is, AFAIR (the blue DIX pamphlet), a hard limit on number of nodes too, but it's enormous and far higher than any of the other practical limits would permit. Andy Dingley (talk) 19:56, 28 March 2020 (UTC)

"There is, AFAIR (the blue DIX pamphlet), a hard limit on number of nodes too" Section I, "Introduction", of the 2.0 DIX spec says, under "Physical Layer", "Maximum number of stations: 1024". The only other 1024 that Preview (macOS) could find in the document is in the backoff algorithm, with 1024 being the maximum backoff; I don't know what motivated the 1024-station maximum. Guy Harris (talk) 20:52, 28 March 2020 (UTC)

The backoff limit is statistical. Well, first, it only applies to hosts actually transmitting. In backoff, each host picks a random number, in the later stages between 0 and 1023. If only one host has the lowest number, they transmit, else there is a collision and everyone tries again. More hosts trying means more likely that more than one get the same lowest number, but nothing magic happens at 1024. Especially as for most nets, not everyone is active at the same time. (Unless everyone is doing online work due to Covid-19 rules.) Gah4 (talk) 21:53, 28 March 2020 (UTC)

GA status

I recently completed addressing all complaints from a failed 2011 GA review. I submitted for a new GA review which prompted Chiswick Chap to insert 19 {{cn}} requests. I have withdrawn the request for GA review. ~Kvng (talk) 13:48, 20 April 2020 (UTC)

Kvng - I'm not sure if you missed it by accident, but removing the nomination from Wikipedia:Good article nominations isn't necessary, you just need to remove the GA template at the top. Best Wishes, Lee Vilenski ^{(talk • contribs)} 13:58, 20 April 2020 (UTC)

 Done ~Kvng (talk) 14:03, 20 April 2020 (UTC)

reduced panel space

Currently this article says "Due to ... the reduced panel space needed by twisted pair Ethernet, most manufacturers now build Ethernet interfaces directly into PC motherboards, eliminating the need for installation of a separate network card."

Reduced compared to what? Is the panel space required by modern twisted pair Ethernet less than the panel space require by earlier twisted pair Ethernet?

What does the panel space used by Ethernet in a 19-inch rack panel have anything to do with Ethernet interfaces on PC motherboards? What other kind of panel could this be alluding to? --DavidCary (talk) 02:51, 9 September 2020 (UTC)

Possibly, the article refers to the reduced back panel footprint of 8P8C compared to Ethernet's initial DA-15 AUI port (for coax or an external transceiver) – twisted-pair Ethernet has used 8P8C from the start, so there's no difference there. The required back panel space isn't the only reason for ubiquity (the others being decreasing cost and increasing demand), so we should rephrase or maybe remove that sentence. --Zac67 (talk) 05:13, 9 September 2020 (UTC)

The cited source (from 2004—wow) says nothing about "panel space", and the term really doesn't make sense here. I agree with Zac67 that "back-panel space" may be the intended meaning. Nevertheless, it's unsourced, and far from clear to the average WP reader. I changed the sentence to read:

Due to the ubiquity of Ethernet, and the ever-decreasing cost of the hardware needed to support it, most manufacturers now build Ethernet interfaces directly into PC motherboards, eliminating the need for a separate network card.

This section is starting to show some age, so more editing is probably a good idea. Good catch, DavidCary! — UncleBubba ^{( T @ C )} 11:55, 9 September 2020 (UTC)

Alternate units

This is copied from my talk page and answered here per WP:BRD ~Kvng (talk) 14:51, 27 November 2020 (UTC)

Hi,

Please let me know why you reverted my edit for the page Ethernet. Generally, people are used to seeing representations of data (and their rates) in bytes, not bits. I felt that adding the speeds in bytes as notes was a good compromise.

Thanks.

DesertPipeline (talk) 07:34, 27 November 2020 (UTC)

While computer and storage performance is often specified in byte/s, network engineers work most frequently in bit/s. The alternate units with similar-sounding names can be confusing and are not frequently used in the field. Your casting them as notes will exasperate those who have criticized this article for having too many notes. ~Kvng (talk) 14:51, 27 November 2020 (UTC)

Generally it has seemed to me that the only usage of bits has been by ISPs. Am I incorrect? As a few examples of networking speeds measured in bytes, the proprietary game distribution program Steam uses bytes when measuring download speed, as does Speedtest.net (I believe?). (Edit: It does not use bytes). Regarding 'too many notes', I can understand that sentiment, but if notes provide useful explanations not exactly necessary to understand the article proper, it's better to have 'too many' of them rather than dumping the information directly into the article body or simply getting rid of them. I would be fine with the speeds in bytes being in brackets after each speed in bits, but because it isn't strictly necessary information, I don't want to clutter the article body with them, but I do feel that they are helpful additions. Your thoughts?

Thanks.

DesertPipeline (talk) 17:31, 27 November 2020 (UTC)

Against byte/s – Seconding Knvg here – in networking, only bit/s is used generally and throughout. Our aim should be to provide clear and useful information for the reader, and since professionally only bit/s is ever used, references to byte/s wouldn't do much good there. --Zac67 (talk) 18:28, 27 November 2020 (UTC)

Against byte/s – Section 1.2.3 "Physical Layer and media notation" of IEEE Std 803.3-2018 says:

Users of this standard need to reference which particular implementation is being used or identified. Therefore, a means of identifying each implementation is given by a simple, three-field, type notation that is explicitly stated at the beginning of each relevant clause. In general, the Physical Layer type is specified by these fields:

<data rate> <modulation type> <additional distinction>

The data rate, if only a number, is in Mb/s, and if suffixed by a “G”, is in Gb/s. The modulation type (e.g., BASE) indicates how encoded data is transmitted on the medium. The additional distinction may identify characteristics of transmission or medium and, in some cases, the type of PCS encoding used (examples of additional distinctions are “T” for twisted pair, “B” for bidirectional optics, and “X” for a block PCS coding used for that speed of operation). Expansions for defined Physical Layer types are included in 1.4.

and the sections on various PHY laters give speeds in bits/s or multiples thereof.

(This is not unique to Ethernet. 802.11, for example, also gives PHY bit rates rather than byte rates.)

There's no "125 megabyte Ethernet" page; instead, there's a Gigabit Ethernet page.

So, yes, you are incorrect when you say that bit rates are used only by ISPs; bits are used when discussing LANs, for example. Guy Harris (talk) 19:54, 27 November 2020 (UTC)

For networking hardware, and it seems ISP advertizing, it does seem that bits are used. For user software though, such as ftp and wget, in bytes/second. Since this article is on the hardware level it does seem that bits are appropriate, but it might also be worth noting the difference and when people should know to multiply/divide by 8. Gah4 (talk) 20:00, 27 November 2020 (UTC)

At the physical layer, rates are generally in bits/second. User software generally runs atop a transport layer; that layer, or layers below it, generally provide a physical-layer independent service and, in practice, are transferring data a byte at a time, so they tend to give the rates in bytes/second. Guy Harris (talk) 20:09, 27 November 2020 (UTC)

Directories for most OS give file size in bytes, or sometimes blocks. As far as I know, the places where software gives rates, it knows bytes (because that is how OS keep track of things) and divides by the time needed. Gah4 (talk) 23:40, 27 November 2020 (UTC)

Have a look at OSI model. Ethernet covers layers 1 and 2. Bits are the commonly used unit at those layers. FTP, HTTP via wget, and so on are at layer 7, where different terminology tends to be used. MrOllie (talk) 00:02, 28 November 2020 (UTC)

With notably rare exceptions, CPU instruction sets these days work in octets; working in bits would be a real stretch. :-) As such, OSes keep track of file sizes and the like in octets.

However, at the link layer, Linux "ethtool <interface>" shows the interface speed in Mb/s, for example, as does Windows 10's network settings GUI.

So, again, it's a function of the layer you're at, as per what MrOllie said. Guy Harris (talk) 00:45, 28 November 2020 (UTC)

Some link layer tools also give the total bytes sent/received ... not bits. Gah4 (talk) 01:40, 28 November 2020 (UTC)

Which link-layer tools are those? The BSD netstat, when given an interval argument of n in seconds, reports "bytes" in and out every n seconds - but I'm not sure that's "bytes" counting link-layer headers, so it may just be a count of the number of bytes that the IPv4/IPv6/ARP/etc. layers handed to it or that were handed to those layers, in which case that'd be above the data link protocol layer. Guy Harris (talk) 01:53, 28 November 2020 (UTC)

In my opinion, regardless of what the standards are when it comes to data transfer rates and how we measure them, it's worthwhile information for the article to mention what the speeds are in bytes. Recently I used a search engine to determine how many people get confused by the usage of bits rather than bytes by ISPs, and I found quite a few results where people wondered why they were not getting the speed they were paying for (because it was in bits and they did not know the difference between bits and bytes, especially because the ISPs did not specify bits, only using "Mb" or "Gb" which to the untrained user who has only ever heard of "megabytes" and "gigabytes" might assume it means that, despite being written MB and GB respectively in that case). Perhaps the article doesn't strictly need the information, because conversion is relatively easy, but some readers might not be aware that conversion is even necessary, or what the conversion rate is. Perhaps my logic is flawed here, but I don't think it does any harm to have the information in the article. I'm probably biased because I made the edit, but I do consider it to be "useful" myself. Of course, if consensus is that it is not useful, then I'll accept that. DesertPipeline (talk) 02:38, 28 November 2020 (UTC)

Reminds me, before the Hz unit frequencies were commonly in megacycles (or kilocycles), with the "per second" implied. But yes, this is common in networking where there is 10 megabit ethernet, also leaving off the "per second". Seems to me that we don't need to put conversions on the units, but an explanation of the difference and the confusion it causes might be nice. Gah4 (talk) 03:57, 28 November 2020 (UTC)

The only guarantee offered by the speed of most if not all PHY layers is "guaranteed not to exceed". :-) And even if you're lucky enough to get the full link-layer speed, there may be network-layer and transport-layer that will eat some of that bandwidth, plus, if there are any routers/switches/bridges involved, those may slow things down, and the host from which you're fetching the data may not be able to provide data at full speed.

My DSL modem is currently reporting a download bandwidth of 5984 Kb/s, which is 748 KB/s, but I never see that much when downloading.

So the best way to fix that confusion may be to have ISPs provide an explanation that mentions not only b/s vs. B/s, but also all the other overheads, and "by the way, the server from which you're downloading might not be able to run at full network speed". (And if you're directly connected to the modem by Ethernet, the Ethernet's speed is probably not going to be the limiting factor for downloads, so this page might not be the best place to address an issue with people understanding the data rate their ISP is offering.) Guy Harris (talk) 04:08, 28 November 2020 (UTC)

So is the consensus here not to make the change to list the speed in bytes as well? DesertPipeline (talk) 15:08, 8 December 2020 (UTC)

Either that or we can call this no consensus in which case we also don't make the change. ~Kvng (talk) 17:14, 11 December 2020 (UTC)

User:Kvng Hi again. I have two different proposals for the different measurement units that I just thought up. If neither are to your liking, no problem, we can leave it at that. Obviously, these proposals only solve the issue of having two many notes, and they don't solve the issue of 'we don't need to say it in the first place'. Personally I feel the information would be useful, but if everyone else is of the opinion that it's not necessary, I understand. At the very least with proposal two it doesn't have to be implemented here but could be implemented generally for other purposes.

Proposal 1: Tooltip template

With this proposal we'd add the tooltip template to the numbers, like so:

2.94 megabits per second 400 gigabits per second

There may be a way to make it so "2.94 megabits per second" has the tooltip while only "megabits per second" has the wikilink, but I'm not sure how.

Proposal 2: New template

With this proposal we'd make a new conversion template suitable for all types of measurement units. Usage would be inserting something into the template and specifying what unit of measurement it is, then the template automatically converts it and gives readers a small [convert] button to click, which produces a box similar to what you'd see when mousing over a reference, which shows corresponding conversions. Ideally this could be used all over Wikipedia for other purposes as well, such as distance.

Please let me know if either of these are to your liking.

Thanks, DesertPipeline (talk) 17:03, 29 December 2020 (UTC)

@DesertPipeline: I personally don't think conversions of any type are needed where you placed them in this article. I'm not sure what the WP:MOS has to say about the tooltip proposal. Often clever ideas like this get shot down because of WP:ACCESSIBILITY concerns. It is possible bit-to-byte conversions may be useful somewhere else and, if so, a Category:Convert-like templates might be helpful. I would identify where it would be used before going to the trouble of creating it. ~Kvng (talk) 20:16, 29 December 2020 (UTC)

Do you have any suggestions as to where else in the article it could go? (Off-topic) By the way, speaking of accessibility, I think this talk section might not be conforming to an accessibility guideline, although I can't remember what it is. Something to do with each list item (the colon symbol making a list) needing to be 'attached' to the last one. We have gaps between our comments sometimes here. Is that something we need to fix? DesertPipeline (talk) 05:53, 30 December 2020 (UTC)

DesertPipeline, these conversions are covered in Bit rate which is linked in the first paragraph of the lead here. I think this is adequate treatment of the issue.

I haven't seen anyone try to apply WP:ACCESSIBILITY to talk pages. ~Kvng (talk) 14:18, 1 January 2021 (UTC)

Fair enough, I'll concede the non-inclusion of my changes then. Also, what I read is on the page you linked: WP:Accessibility#Lists. I think if I do it this way (putting the list item indicators in the whitespace as well) that prevents accessibility issues for screen readers. I'm not sure if I'm actually supposed to be placing a gap between my comments and yours though. Can you advise me on the matter? DesertPipeline (talk) 17:03, 1 January 2021 (UTC)

ethertype

Can we mention which other protocols do, and don't, use Ethertype as the first field? Gah4 (talk) 04:01, 28 November 2020 (UTC)

IEEE 802.3 Ethernet is not such a protocol. :-)

The third field of the 802.3 header, at least as of 802.3y-1997, is a type/length field. (Prior to that, it was a type field in D/I/X Ethernet and a length field in 802.3; in practice, most Ethernet packets that had an Ethertype value used it as a type field, and others used it as a length field - 802.3y-1997 merely acknowledged reality.)

FDDI has no type field; instead, data frames begin with an {IEEE 802.2, ISO/IEC 8802-2} LLC header, and if both DSAP and LSAP were 0xAA, have a SNAP header following them.

Most non-802.3 technologies work/worked similarly.

802.11 always did so until recently; as of 802.11-2016, it's not that simple....

IEEE Std 802-2014 (802, with no .anything) introduced, in section 5.2.2 "LLC sublayer", two different forms of "protocol discrimination" - EPD, for "Ethertype protocol discrimination", and LPD, for "LLC protocol discrimination".

With LPD, packets have an 8802-2 LLC header, with DSAP and SSAP, and if both DSAP and SSAP are 0xAA, they have a SNAP header following it, with an OUI and a per-OUI protocol ID, and with an OUI of 0 meaning the protocol ID is an Ethertype.

With EPD, packets have an Ethertype, and, if the Ethertype is the the OUI Extended EtherType (0x88b7), the Ethertype is followed by... an OUI and a PID, interpreted the same way that they're interpreted in the SNAP header. (And presumably the OUI can be 0, in which case the PID would presumably be an Ethertype.)

(And, yes, you could have a packet with an 8802-2 LLC header with 0xAA as the DSAP and SSAP, followed by a SNAP header with an OUI of 0 and a PID of the OUI Extended EtherType, followed by an OUI, followed by a PID; 802-2014 gives that as an example in Figure 14 in Chapter 9.)

802.11 uses LPD, unless either 1) the traffic is in the 5.9 GHz band or 2) the IEEE Standard for Wireless Access in Vehicular Environments (WAVE) is in use, in which case it uses EPD. (Added: ISO 21215, "Intelligent transport systems — Localized communications — ITS-M5", says "Different to the information in IEEE Std 802.11TM-2016, 5.1.4, EPD is applicable in all frequency bands as long as dot11OCBActivated is set to true, i.e. activating the operation mode "outside the context of a BSS" (OCB).")

802.3 can now be described as using EPD for frames where the type/length field value is >= 1536 and using LPD for frames where the type/length field is <= 1500. (Frames where the type/length field value is > 1500 and < 1536 are invalid.)

I don't know whether any other 802.x link layers ever use EPD.

As for where that belongs in the Wikipedia, the general concepts of EPD and LPD probably belong in Logical link control#Local area network (LAN) and metropolitan area network (MAN) protocols, the way the choice between them is made in Ethernet would belong in Logical link control#Ethernet and various Ethernet-related pages, the way the choice between them is made in 802.11 would belong in IEEE 802.11#Data frames. Guy Harris (talk) 06:03, 28 November 2020 (UTC)

Definition of Ethernet

This is not really covered - Why isn't WiFi considered to be Ethernet? Where is it defined that only cabled technologies are considered to be Ethernet? Ethernet is not defined purely at layer 1. So if WiFi uses the same layer 2 frames over a different layer 1 media, why is itnot Ethernet? Commking (talk) 09:12, 31 March 2021 (UTC)