Talk:PCI Express/Archive 2023

PCIe Gen 5 page

I am new editor, and I realized that there is no PCIe Gen 5 page. I am really bad at writing, so I could not do this. Thank you for reading this, by the way! Intel Lover (talk) 00:14, 28 February 2023 (UTC)

PCIe 5.0, 6.0, and 7.0 can be found under the History and Revisions section of this page, did you miss these sections? 134.134.137.81 (talk) 22:18, 23 March 2023 (UTC)

Yes. I am so sorry about that. 2600:1702:3FC0:4590:113C:F289:9CBA:577C (talk) 22:56, 23 March 2023 (UTC)

Note iii on PCI Express Link Performance

Note iii specifies: "Throughput indicates the unencoded bandwidth (without 8b/10b, 128b/130b, or 242B/256B encoding overhead). The PCIe 1.0 transfer rate of 2.5 GT/s per lane means a 2.5 Gbit/s serial bit rate corresponding to a throughput of 2.0 Gbit/s or 250 MB/s prior to 8b/10b encoding." However, the conversion from 2.5Gbit/s serial bit rate corresponding to a throughput of 2.0Gbit/s or 250MB/s is a result of 8b/10b encoding, is it not? I ran the numbers on the throughput of the 128/130b encoded versions as well and they are also accounting for encoding losses, so I would propose altering Note iii as follows: "Throughput indicates the encoded bandwidth (with 8b/10b, 128b/130b, or 242B/256B encoding overhead). The PCIe 1.0 transfer rate of 2.5 GT/s per lane means a 2.5 Gbit/s serial bit rate corresponding to a throughput of 2.0 Gbit/s or 250 MB/s when accounting for 80% bandwidth efficiency of 8b/10b encoding." 134.134.137.81 (talk) 22:14, 23 March 2023 (UTC)

To me, "unencoded" means pure user data (ignoring any overhead) and "encoded" includes the line-code overhead. I understand your logic as "encoded" meaning "to be encoded" but I think most readers don't see it that way. Perhaps it's better to rephrase "Throughput indicates the usable bandwidth without 8b/10b, [...] encoding overhead." --Zac67 (talk) 08:23, 24 March 2023 (UTC)

slot size

The size of compatible cards is listed but not the size of the slot. 46.131.26.213 (talk) 14:29, 4 May 2023 (UTC)

Overhead calculation (in chapter "PCI Express 1.0a")

To me the sentence "PCIe 1.x uses an 8b/10b encoding scheme, resulting in a 20% (= 2/10) overhead on the raw channel bandwidth." would appear not ok, as "overhead" in form of a ratio would typically be regarded as the result of "(gross - net) / net". Hence in my view it should rather be an overhead of 25 % (= 2 bit / 8 bit).

Greetings from Munich/Bavaria!

Manfred / lini — Preceding unsigned comment added by 62.216.209.208 (talk) 02:08, 21 June 2023 (UTC)

That's not correct. Overhead is defined as the portion of data that is transmitted "in vain" in proportion to the total transmitted data: (total - payload)/total. --Zac67 (talk) 14:57, 21 June 2023 (UTC)

Sorry, but in my view that would be just one possible way to define overhead in form a ratio (or respectively a fraction) - and the less logical or respectively intuitive or natural one at that. Because the "over-" in the word "overhead" already indicates an extra on top of something, namely the net content (or the payload, to use your term) in this case. And hence the more logical (intuitive, natural...) choice as reference (denominator) for an overhead in form of a ratio would be the net (payload) rather than the gross (total). And examples of that sort of usage can also easily be found - e.g. the at least 33 (1/3) % overhead caused by Base64 encoding, or this example from the example section of the Wikipedia page about "Overhead (engineering)": "The date and time "2011-07-12 07:18:47" can be expressed as Unix time with the 32-bit signed integer 1310447927, consuming only 4 bytes. Represented as ISO 8601 formatted UTF-8 encoded string 2011-07-12 07:18:47 the date would consume 19 bytes, a size overhead of 375% over the binary integer representation."

Greetings from Munich!

Manfred / lini — Preceding unsigned comment added by 62.216.209.247 (talk) 02:46, 23 June 2023 (UTC)

Of course, that's an alternative way – the more common one is the one above. Please discuss your view on the appropriate page. --Zac67 (talk) 06:15, 23 June 2023 (UTC)

Giga bits per second needs fixing

There are mixes of confusing units here I think - GB/s meaning giga bits per second for example.. these need a thorough sweep through. Even Tomshardware had the same figures i think! Bravekermit (talk) 13:58, 2 November 2022 (UTC)

You're not the first to say so but with all these archives it's hard to notice. Since this keeps coming up we definitely need to explain better that, no, these figures are definitely in gigabytes per second (10^9 bytes per second). The relation between the doubly pumped lanes, bonded lanes, gigatransfers per second and net data rates can be a bit overwhelming at first. Digital Brains (talk) 20:26, 2 November 2022 (UTC)

Alternatively we could just convert everything to bits per second... it's a fairly uncommon unit, bytes per second. But then the problem will be people asking "so if I have a file of 10 GB, how long will it take to transfer?" Digital Brains (talk) 20:34, 2 November 2022 (UTC)

@Bravekermit: I don't see any problem either – otherwise please point to the exact error. @Digital Brains: I don't think everything in bit/s would be very useful. The signaling (encoded) rates in bit/s and the usable (uncoded) rates in B/s is fine imho. --Zac67 (talk) 21:52, 2 November 2022 (UTC)

I think it would be sufficient to have a general footnote something like this:

binary - kilo-mega-giga == 10241 / 10242 / 10243

decimal - thousand-million-billion == 10001 / 10002 / 10003

but industry standard nomenclature will never adhere to convention whenever exaggeration for profit is an incentive. 2601:40D:8100:9400:F5C7:8D0E:66E6:3C06 (talk) 08:48, 5 July 2023 (UTC)

Oh wierd - I must have had too many docs open - this one consistently uses GB/s gigabytes for the useful things. My only suggestion would be to first say what one lane was rather than 16 - but its a minor suggestion... Bravekermit (talk) 13:46, 7 November 2022 (UTC)

Throughput

I want to raise the question of what bandwidth to indicate in the article. It is now listed in one stream, but why?! It's a gross violation WP: OR! In a significant majority of sources, as well as PCI-SIG itself, the speed is indicated precisely in the duplex (in both directions), for example, for PCI-E 7.0 x16 it is 512 GB/s, which means that this is how we should indicate, as the source says, and not engage in unauthorized division into two. Of course, it is necessary to clarify that the speed is indicated in the duplex (in both directions). Wikipedia is written by source rather than original research. --185.52.142.168 (talk) 15:41, 10 August 2023 (UTC)

It's better as it is. To state the maximum throughput per direction is more meaningful to readers and users – there are few uses cases where Tx and Rx are both fully loaded. Adding both directions together is pure marketing from the side of PCI-SIG and it's simply copied all over the news. I don't see any OR as bidirectional and unidirectional values provide the same technical information. --Zac67 (talk) 17:36, 10 August 2023 (UTC)