Talk:Ethernet

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)

"So if WiFi uses the same layer 2 frames over a different layer 1 media," Define "same layer 2 frames". The Ethernet and 802.11 MAC headers are not the same, for example. Guy Harris (talk) 09:32, 31 March 2021 (UTC)

Ethernet is what is defined by the IEEE 802.3 work group with the data link layer defined/expanded in IEEE 802.1 (which is similarly used by multiple 802 PHY families). Wi-Fi is defined in 802.11. --Zac67 (talk) 10:44, 31 March 2021 (UTC)

WiFi has been referred to as Wireless Ethernet so I wouldn't rule it out as a type of Ethernet. We don't have a definition for Ethernet here because this is an encyclopedia, not a dictionary and I don't think we'd find a consensus of sources that agree on a definition. ~Kvng (talk) 16:39, 1 April 2021 (UTC)

If Wi-Fi is a type of Ethernet, why isn't Token Ring a type of Ethernet? The physical layer and MAC layer are different from those of Ethernet, but the same is true of Wi-Fi. Guy Harris (talk) 19:34, 1 April 2021 (UTC)

We should probably not do this. Just because Wikipedia thinks ASCII is a form of Morse Code, doesn't make it so. --Wtshymanski (talk) 19:49, 1 April 2021 (UTC)

Guy Harris, strong point ~Kvng (talk) 22:29, 1 April 2021 (UTC)

Interesting. I can put WiFi and wired ethernet in the same layer 2 broadcast domain and communicate directly without routing - and yet the frames are different? Learning all the time. Commking (talk) 23:43, 5 April 2021 (UTC)

Yes, bridges between link layers always using 802.2 LLC (most non-Ethernet link layers) and link layers not always using 802.2 LLC (mainly Ethernet) have to do some frame translation (adding or removing an 802.2 LLC header), and bridges between any two non-identical link layers have to deal with non-data frames (which generally means "don't forward them if they don't have an equivalent on the other link layer") and other link-layer dependent header information. Guy Harris (talk) 00:56, 6 April 2021 (UTC)

Generic 802.11 Frame

Yup, among other differences the Wi-Fi frame structure has no less than four address fields.

GliderMaven (talk) 00:58, 6 April 2021 (UTC)

@Kvng: Even though you can read "Wireless Ethernet" here and there, it's not a thing. Ethernet is generally wired. Wi-Fi uses a distinctive frame format and is vastly different from Ethernet at a low level. There's actually not too much in common, apart from both being MAC-based IEEE 802 standards. --Zac67 (talk) 21:27, 1 April 2021 (UTC)

Arguably Ethernet and Wi-Fi are both types of ALOHAnet ;) GliderMaven (talk) 22:18, 1 April 2021 (UTC)

Used as appropriate, not replaced or superseded.

As regarding recent edits and edit summaries. 10base5 was mostly used across campuses, and for larger buildings. 10base2 for small workgroups and labs. In that way, they weren't alternatives. Especially since they are electrically the same, but no-one would use 10base2 across a campus, or 10base5 within a (small) room. The early 10base2 transceivers were 10base5 transceivers with N to BNC adapters on them. I suspect that was done some time before it was official. Well, there were some other choices for campus networks, FDDI being one of them. You won't see the campus network unless you go down in the tunnels were wires go between buildings. That is why I am against replaced or superseded. They were each used as appropriate. Gah4 (talk) 17:33, 23 March 2023 (UTC)

Before 10BASE2 existed, 10BASE5 was used in small workgroups and labs; I have old memories of yellow cables in at least one non-campus setting. In that way, 10BASE2 was an alternative to 10BASE5. Guy Harris (talk) 20:52, 23 March 2023 (UTC)

There were many installations and pretty much all above is true. I was trying to convey the (perceived) fact that Ethernet pretty much exploded with 10BASE2 and installations increased more than tenfold. On the other hand, 10BASE5 installations were very rarely replaced, they just continued or might have been augmented with 10BASE2. FDDI came a bit later but I remember ARCNET being used for smallish installations quite a bit. --Zac67 (talk) 08:07, 24 March 2023 (UTC)

Well, it pretty much exploded when the price came down. I was recently remembering the story, about a conference years ago, when IBM had a talk about their newest Token-ring card, I suspect for the IBM PC. At question time, someone asked about Ethernet. The reply was that when Ethernet got below $1000, they should buy it. The next talk was 3Com announcing their $999 Ethernet card. It is hard to imagine now $999 being cheap. (Without inflation adjustment!) In any case, it is the economy of scale as production went up, and then people buy more as the price goes down. Now, part of the price comes down was due to the ease of use of 10base2. AUI cables were expensive. Especially plenum rated cables. 10base5 transceivers weren't all that bad, thought we used to by two-port and four-port versions to keep the price down. FOIRL and then 10baseFL would have been more competition for campus wide networks. And repeater costing thousands of dollars, in big boxes. Gah4 (talk) 21:53, 24 March 2023 (UTC)