Talk:PCI Express/Archive 2020

Infobox
I recently made changes to the infobox in order to improve its WP:ACCESSIBILITY. There were no content changes, only minor copy-editing, besides the removal of version 6.0's "secondary" speeds on the grounds that they are not mentioned anywhere in the body. However, has reverted these changes back on two occasions (the first of which prompting me to look harder into the edit and improve some things), aggressively categorizing my edits as vandalism, which clearly makes no sense. I'm creating this section for them to support their reasoning here in the hopes of avoiding an edit war. Other editor's input is welcome.

For reference, here are the changes in question:

~ Arkhandar (message me) 22:51, 26 May 2020 (UTC)


 * PCI Express is not hardcoded to a particular speed or duplex.


 * - have been vandalizing the infobox and vandalizing the PCI Express page. You have been stalking my pages (every page that I have made edits on) and making content changes, removing important details, removing ALL of PCI Express existing template and PCIe's per lane bandwidth, as well as PCI Express 6.0's speeds. Stop stalking me, and stop stalking my pages!  Also, stop vandalizing and deleting important information on the PCI Express page!  The Info Box serves a purpose and has been there for many years. You are not an engineer, and clearly don't know what you are doing, so please stop vandalizing the PCI Express page, and stop removing Info Boxes on every page that you visit and vandalize.


 * has reverted these vandalism changes back on two occasions (the first of which prompting me to look harder into the edit and improve some things), aggressively categorizing my edits as vandalism, which is exactly what it is. — Preceding unsigned comment added by Mark.malewski (talk • contribs) 23:10, 26 May 2020 (UTC)


 * It is NOT a "clean up" when you are vandalizing a page, changing important details and adding INCORRECT information. What you are doing is WP:VANDALISM. The information you are changing is WRONG and INCORRECT.  There is a reason for specifying RS specifications (as per PCI Express draft specification) as well as the link/lane bandwidth.  (e.g. quick glance at the lane bandwidth).  Also you can't state "full duplex" under speed, when that is not hardcoded to a particular speed or duplex (as per PCI Express specifications).  It's just like clock, it can be changed and can be variable.  Your edits are not adding anything to the page, and instead is making the page worse by adding incorrect information and removing important details. ~ Mark.Malewski (message me) 18:25, 26 May 2020 (UTC)


 * It might be best for you to "take a break" and stop engaging in disruptive behavior. Your changes are NOT improving the page. You are changing content, and entering WRONG and INCORRECT information, and removing important details and important information. If you don't know what you are doing, please stay off the page! Preceding unsigned comment added by Mark.malewski (talk • contribs)


 * , you need to calm down. As per the bold, revert, discuss cycle, you are obligated to discuss editorial differences with the other editors. There's been no vandalism and you calling that out is offensive. Please calm down and settle the differences. And don't change/remove other editor's comments here, that is also offensive and may get you blocked. --Zac67 (talk) 06:20, 27 May 2020 (UTC)


 * Thanks for clarifying. Regarding the "RS" speeds. they should and will be deleted as long as there's not mention of such thing in the body, and especially if there no references to it. So if they do exist, and you consider them notable enough, please mention them in the body referenced with WP:RELIABLE sources first. Regarding the bandwidth layout, you are indeed correct and the data transfer is done via dual-simplex, rather then full-duplex signaling. A quick change should be enough. Thanks~ Arkhandar (message me) 11:37, 27 May 2020 (UTC)


 * Technically, dual simplex is correct because each direction uses dedicated, unidirectional wiring/contacts. Full duplex would indicate bidirectional contacts used simultaneously (like e.g. with 1000BASE-T). I'm not sure if we should make such a clear distinction here though as it might confuse many not-so-technical readers. A good compromise could be to point out this blurriness once and then leave it at that. --Zac67 (talk) 16:56, 27 May 2020 (UTC)


 * This: "GT/s is equivalent to Gbit/s in encoded bit rate." is almost gibberish to me. And I know what it means. I think you can pretty much only reconstruct what "speed in encoded bit rate" means if you already know what it means. It is already linked to the GT/s article; people can read up on it in the wikilinked article if they don't know yet. Trying to think of a one-phrase formulation, I can only come up with "gross rate after encoding" or some such. I'd rather just not explain it and refer people to the article. I also see no reason to use the term equivalence. Two terms for the same thing doesn't make them equivalent, it makes them synonymous or equal. Digital Brains (talk) 15:55, 27 May 2020 (UTC)


 * This will require rephrasing very soon anyway as PCIe 6.0 starts using PAM-4 and currently, it's not at all clear (to me) how PCI-SIG is defining a transfer with that. A level changes? A raw channel bit? --Zac67 (talk) 16:56, 27 May 2020 (UTC)


 * So, besides changing from full-duplex to dual-simplex, and removing GT/s is equivalent to Gbit/s in encoded bit rate. in the clean-up version, do you have any other suggestions? ~ Arkhandar (message me) 21:53, 31 May 2020 (UTC)

Everything apart from the full-duplex/dual-simplex thing looks like an improvement to me. But the original explicitly said in each direction, so you know that there is, e.g., 250 MB/s in each direction. Now, with full-duplex, does it mean in each direction or in total? It doesn't clarify what the speed figure means, which seems like the purpose of mentioning it in the speed section in the first place. I'd suggest reinstating the old in each direction. Regarding full-duplex versus dual-simplex, maybe terminology has shifted and I'm just getting old, but the use of full-duplex to mean two simplex connections is ancient and well-established, like for instance in 10BASE-T and 100BASE-T Ethernet (and that's a very recent example given the long history of simplex/half-duplex/full-duplex). Digital Brains (talk) 09:23, 1 June 2020 (UTC)


 * Regarding the full duplex/dual duplex difference, I'm pretty sure it's the fact that while both transmit in both direction, full duplex tends to use the same "channel" for such, while dual simplex is basically two simplex channels transmitting in opposite directions. Hence, the "result" is the same, but it's done in different ways. Regardless, I've found an WP:RS that clearly categorizes it as dual simplex, so the ambiguity is reduced: ieee.org. Regarding the in each direction phrase, I think it's redundant as lonf as dual simplex is wiki-linked to a definition. 12:50, 1 June 2020 (UTC)


 * From the user side, there is no difference between full duplex and dual simplex – both provide a bidirectional channel with nominal speed in each direction simultaneously. For that, dual simplex uses two distinct, unidirectional connections (e.g. PCIe, SATA, SAS), while full duplex uses a single, bidirectional connection (e.g. 1000BASE-T, POTS), usually requiring a hybrid. The distinction is a telecommunication technicality, so I'm not sure if it is required here (as mentioned). --Zac67 (talk) 13:02, 1 June 2020 (UTC)
 * Since dual simplex is actually a redirect to full-duplex where the example of Ethernet with separate transmit and receive pairs is subsequently mentioned as an example of full-duplex, this article would fit perfectly if it's just called full-duplex. I think it's a bit pedantic to be so precise as to call it dual-simplex, and it reduces the audience that already is familiar with the terminology used. The Duplex (telecommunications) article does not define the term dual simplex, so a wikilink won't help much. "250 MB/s full-duplex" is ambiguous in the sense that it can mean both "125 MB/s in each direction" and "250 MB/s in each direction". I don't think that situation improves with "dual-simplex". I still don't know if it means total attainable throughput or unidirectional throughput. Since both conventions are used (although unidirectional is definitely more common), it's ambiguous. Digital Brains (talk) 16:32, 1 June 2020 (UTC)
 * Regarding the ambiguity, look at slide 4 here: . It mentions the aggregate bandwidth being 0.5 GB/s; in other words, a speed of 500 MB/s for a v1.0 x1 link. This is one of the sources used in the article. Digital Brains (talk) 16:44, 1 June 2020 (UTC)
 * By the way, if we could agree to use in each direction to avoid the ambiguity, the whole full-duplex versus dual simplex discussion is a moot point. Digital Brains (talk) 19:43, 1 June 2020 (UTC)


 * Agreed, in each direction is better in almost every respect. --Zac67 (talk) 19:47, 1 June 2020 (UTC)

What do you think? ~ <b style="color: #8cc5ff;">Arkhandar</b> (<b style="color: #b3b3b3;">message me</b>) 20:24, 1 June 2020 (UTC)
 * I see. I also agree with keeping the in each direction phrase, but as a short explanation of what the dual simplex jargon means. I say we keep the jargon since it's categorized as such by WP:RSs (e.g. i mentioned earlier }. I propose something like this: "Dual simplex (in each direction)"


 * Works for me. While we're at it I've added a bit of explanation to the dual simplex redirect which could be useful here now. --Zac67 (talk) 15:52, 2 June 2020 (UTC)
 * Sure, go ahead. Digital Brains (talk) 16:20, 2 June 2020 (UTC)


 * You stated: * Remove the GT/s is equivalent to Gbit/s in encoded bit rate. note;


 * This is actually INCORRECT!


 * GT/s is NOT equivalent to Gbit/s at all!


 * In data communication, GT/s is gigatransfers per second. The correct specification is GT/s (Gigatransfers per second).  It should NOT be Gbps or GB/s!


 * PCIe transfers in gigatransfers per second, that's the bus transfer speed (# of transfers per second) which is GT/s!


 * You can't swap out GT/s for Gbps, as they are NOT the same thing! It's like saying 5 pounds is the same as 5 gallons.  It's incorrect and they are not the same.  PCIe lanes (as most buses) are in GT/s (gigatransfers per second).  The data transfer rate of PCIe is measured in GT/s.


 * I am trying to say this (and explain this) in the nicest way possible, but you might want to go to school and get an engineering degree, or at least take a few computer engineering courses (in ECE), and learn about electrical and computer engineering before making drastic changes. I understand that you think these are "minor edits" but they are not, and they are extremely major changes and I suggest you sit on a IEEE Engineering Workgroup or Committee (to get an understanding of PCIe) and it would best to read this page here on  Transfer_(computing) to help give you a basic elementary understanding of the difference between transfers per second (GT/s) for a bus channel ( Communication_channel) and the difference between a  Sample_rate and a  Bit_rate, none of these things are the same. You should know this and understand this before attempting to make changes.

If you don't understand how data-transfer channels work, and don't even know (or understand) the difference between GT/s and Gbps (which is elementary basic Engineering 101), then this is probably not the best place for you to be making drastic changes or edits that are extremely wrong and incorrect about a subject/topic that you truly don't understand, can't seem to grasp or understand and don't seem to know anything about.


 * - I am trying my very best to "educate" you, but it doesn't seem to be working, because you keep trying to make changes when you don't understand that topic or subject matter (at all).


 * - Fundamentals of PCI Express:

'''Because PCIe is a serial bus with the clock embedded in the data, it needs to ensure that enough level transitions (1 to 0 and 0 to 1) occur for a receiver to recover the clock. To increase level transitions, PCIe (2.0) uses “8b/10b” encoding, where every eight bits are encoded into a 10-bit symbol that is then decoded at the receiver. Thus, the bus needs to transfer 10 bits to send 8 bits of encoded data.

'''Looking at a single PCIe 1.1 lane, the bidirectional bus can transfer 2.5 Gbps in each direction, or 5 Gbps in total. Because the bus needs to send 10 bits of encoded data for every 8 bits of unencoded data, the effective bit rate is ''' '''5 Gbps • (8/10), or 4 Gbps  A 16-lane PCIe 1.1 bus can transfer 80 Gbps of encoded data or 64 Gbps of unencoded data. Because PCIe 2.0 doubles the transfer rate, a single lane can transfer 5 Gbps of encoded data in each direction, or 10 Gbps of encoded data in total. That’s 8 Gbps unencoded data. Thus, a 16-lane PCIe 2.0 bus transfers 160 Gbps encoded, which is 128 Gbps of unencoded data. That’s 16 Gbytes/s of unencoded data.  So, when the PCI-SIG announced the new rate of 5 GT/s, it was referring to raw data rate—the number of bps that the bus can move, or transfer. The encoding process reduces the rate of useful data transferred over the bus to 80% of the bus’s raw speed.''' '''


 * - I can't explain 4-6 years of engineering courses to you in one paragraph, but it would be best for you to get an engineering degree, join the IEEE, and spend a few years sitting on a IEEE Committee (or Working Group panel) and understand the fundamentals of PCIe.

If you truly don't know or understand the difference between GT/s and Gbps then this is probably NOT the best page for you to be editing or making drastic (incorrect) changes. I have already discussed this with you (on your personal talk page), and I stated this multiple times.


 * - In laymen's terms:

For example, a data bus eight-bytes wide (64 bits) by definition transfers eight bytes in each transfer operation; at a transfer rate of 1 GT/s, the data rate would be 8 × 109 B/s, i.e. 8 GB/s, or approximately 7.45 GiB/s. The bit rate for this example is 64 Gbit/s (8 × 8 × 109 bit/s).

The formula for a data transfer rate is: Channel width (bits/transfer) × transfers/second = bits/second.


 * - These things are NOT the same. You can't just randomly interchange a bus transfers per second (GT/s) for a data-transfer channel (sample rate) to a binary data bit rate.  These are NOT the same.

What you are saying (and what you are changing) is the equivalent of YOU saying that pounds (weight) is equal to liters (volume). As an engineer and a scientist, I understand that these are not factual statements (but you don't). Weight is based on gravity times mass (without gravity, you have no weight, but you still have mass). Volume is the amount of space (a liquid) would take up, but it has nothing to do with weight (or mass) and is measured in liters.

The things you are stating (in your changes) make absolutely no sense (from an engineering perspective) and you are attempting to "dumb down" something that is technical (technical specifications), that you don't understand (because you are not an engineer in ECE) and you are attempting to change them to something that is completely different (and incorrect). If you want to read (and understand) WHY the PCI-SIG specifies GT/s, then that is a subject/topic that you should discuss with PCI-SIG (instead of trying to have this discussion in a Wikipedia Talk Page).

You can read about WHY PCI-SIG specification uses GT/s here: https://www.edn.com/what-does-gt-s-mean-anyway/

Please revert the changes, and do NOT make these changes, as we have NOT reached a "consensus" and the changes that you are attempting to make do not make sense, are inconsistent with PCI-SIG standards, and are FACTUALLY WRONG and INCORRECT (as I explained above, and posted reference links). Please revert the changes, and please stop posting things that are wrong and incorrect.

Please read this page here on Transfer_(computing), and please educate yourself on the differences on data rates and transfer rates.


 * - PCI-SIG standards (including PCI Express) and specifications are expressed and written in GT/s.

Please read [https://www.edn.com/what-does-gt-s-mean-anyway/ "What does GT/s mean, anyway?" (by Marin Rowe)] so you can understand the difference.

The consensus is that you are wrong, and I am asking you nicely to PLEASE stop changing GT/s and Gbps, these terms are not interchangeable, and please leave the infobox alone, and leave those correct items/terminology in the infobox as they are correct, and have been correct for many many years until you came along, and the changes you are making are wrong and incorrect.


 * - We have already discussed this on your talk page, and it is wrong. I thought you understood this, and I thought you agreed NOT to make any additional changes (as of last week), but you are back to making incorrect edits again.


 * - These are not minor changes, and you can't simply change transfers per second (GT/s) to a bit rate, as these terms are NOT interchangeable and PCIe specification states GT/s (Gigathreads per second) since it is a bus, and there is no specification at which binary data is being transferred. It is a data-transfer channel, and is known as a sample rate which should be written in GT/s (transfers per second)


 * - The formula for a data transfer rate is: Channel width (bits/transfer) × transfers/second = bits/second.

'''Newer bus architectures like the front side bus, Quick Path Interconnect, PCI Express and HyperTransport operate at the rate of GT/s. '''


 * - Read this link here: What does GT/s mean, anyway? [Gbps and GT/s are NOT the same!]

'''References: '''"Mega transfer". Encyclopedia of Information Technology. New Delhi: Atlantic Publishers & Distributors. 2007-06-13. p. 304. ISBN 9788126907526. "[http://www.knowledgetransfer.net/dictionary/Storage/en/megatransfer.htm Definition: megatransfer". www.knowledgetransfer.net]. Retrieved 2018-03-22


 * and : I also agree with keeping the "GT/s" and also the "in each direction phrase", as it's correct. I propose that the changes that Arkhandar made are incorrect, and the changes/page be reverted back to June 1st @16:36, at the last correct edit made by @Zac67, as this was the last correct edit.

You can learn more about Transfer_(computing).

After this discussion, I believe the consensus is that the recent changes to the Infobox that made is incorrect, and the PCI Express page should be using "GT/s" and should be reverted back to last known good edit on June 1st @16:36, at the last edit made by @Zac67, as this was the last correct edit.

Clarifying Thunderbolt, tweaks to form factor list
I've made the following changes:

This is misleading; PCI Express External Cabling is a specific standard, not a generic term, and Thunderbolt is unrelated to it. I have changed this to: "Yes (with OCuLink or PCI Express External Cabling)" Hope this helps. --Clothbound (talk) 05:23, 31 August 2020 (UTC)
 * Changed XQD card to CFexpress in the infobox list of hotplugging interfaces. (CFexpress is the successor to XQD and is backwards compatible with it, so while both could be listed, this keeps the list concise.)
 * The infobox previously listed under "External interfaces": Yes (with OCuLink and External Cabling, such as Thunderbolt)
 * I've removed mentions of Thunderbolt from both entries in the infobox, as Thunderbolt is not electrically PCIe; it's a different, proprietary PHY carrying an MPLS-like label-switched network, one of the possible payloads of which can be PCIe TLP. Since the infobox in large part discusses electrical/PHY aspects of PCIe, such as transfer rate, this seems misleading. It seems like an ordinary reader would be likely to conclude that Thunderbolt is simply another kind of external cabling for PCIe, which isn't the case.
 * The list of form factors under "derivative forms" conflated connectors which carry PCIe, with the reuse of PCIe connectors for things other than PCIe, and with Thunderbolt. I've restructured this section to make clearer which form factors are electrically PCIe, which are reuse of PCIe slots for non-PCIe protocols, and which are non-PCIe interconnects which can carry PCIe TLP.
 * Some points in the article refer to the bandwidth of a "Thunderbolt connector". This again implies Thunderbolt is an electromechanical concern and basically PCIe (and in any case, talking about the bandwidth of a "connector" is odd). I've changed "Thunderbolt connector" to "Thunderbolt link".
 * "Thunderbolt was co-developed by Intel and Apple as a general-purpose high speed interface combining a x4 PCIe link with DisplayPort" &mdash; reworded to "combining a logical PCIe link with DisplayPort". Saying "x4 PCIe link" implies the use of the electrical PCIe protocol, which is not used (moreover, see the Thunderbolt article for a pinout, which shows the use of two lanes, not four).
 * "Thunderbolt 3 is part of the USB4 standard": reworded to "forms the basis of".

PCIe is not a bus.
Strictly spoken: a bus system is actually defined as being a way to transmit data between multiple(!) components. That means there can be multiple listeners (or if you like stations) on a bus that may receive data if it is targeted at them. However PCI Express is a point to point connection. So even if it often is called a bus it is not a bus in terms of it's topology.

Quote from the PCI-Express spec: "In Conventional PCI, a device “claims” a request on the bus by asserting DEVSEL#. If no device claims a request after a set number of clocks, the request is terminated as a Master Abort. Because PCI Express is a point to point interconnect, there is no equivalent mechanism for claiming a request on a Link, since all transmissions by one component are always sent to the other component on the Link." ( https://www.intel.com/content/dam/altera-www/global/en_US/uploads/e/e2/PCI_Express_Base_r2.1.pdf ) — Preceding unsigned comment added by Msz666 (talk • contribs) 02:36, 18 September 2020 (UTC)


 * So, you have correctly determined that PCIe is not a bus (because it really isn't). Related: You don't dial a telephone, the Hundred Years War lasted 116 years, the October Revolution is celebrated in November, King George VI's first name was Albert, the Battle of Bunker Hill was fought on Breed's Hill, and catgut comes from sheep and horses. In other words, common names are often not technically correct.


 * The quote from the PCI-Express spec uses the word "bus". And so does Wikipedia.


 * "If Wikipedia had been available around the fourth century B.C., it would have reported the view that the Earth is flat as a fact and without qualification. And it would have reported the views of Eratosthenes (who correctly determined the earth's circumference in 240BC) either as controversial, or a fringe view. Similarly if available in Galileo's time, it would have reported the view that the sun goes round the earth as a fact, and Galileo's view would have been rejected as 'original research'. Of course, if there is a popularly held or notable view that the earth is flat, Wikipedia reports this view. But it does not report it as true. It reports only on what its adherents believe, the history of the view, and its notable or prominent adherents. Wikipedia is inherently a non-innovative reference work: it stifles creativity and free-thought. Which is a Good Thing." -- WP:FLAT
 * --Guy Macon (talk) 05:40, 18 September 2020 (UTC)
 * Oh, and Windows 3.x and earlier are operating environments, not operating systems. Blake Gripling (talk) 11:52, 18 September 2020 (UTC)
 * While I agree it's fine to use the word bus, I'd like to nitpick one comment makes: The quote from the PCI-Express spec uses the word "bus". I just went through the 2.1 Base Specification, and the only context the word bus is used in, is in reference to conventional PCI or PCI-X, or to some backwards-compatible concepts. It might refer to the Logical Bus and its associated Bus Number, which is a backwards-compatibility concept which encompasses enumeration of both conventional PCI as well as PCIe:
 * "Bus Number – PCI Express maps logical PCI Bus Numbers onto PCI Express Links such that PCI 3.0 compatible configuration software views the Configuration Space of a PCI Express Hierarchy as a PCI hierarchy including multiple bus segments."
 * In the same manner, it still uses some mechanisms that were introduced in conventional PCI, to wit the Bus Master Enable bit in the command register and the Bus Power/Clock Control Enable in power management. This is an exhaustive list of the use of the word bus in the Base Spec, and they are all things where backwards compatibility to conventional PCI is maintained. Digital Brains (talk) 15:18, 18 September 2020 (UTC)


 * You are correct. Thanks for catching my error. --Guy Macon (talk) 16:51, 18 September 2020 (UTC)