|
|
Log in / Subscribe / Register

Another round of speculative-execution vulnerabilities

Another round of speculative-execution vulnerabilities

Posted Aug 9, 2023 22:04 UTC (Wed) by willy (subscriber, #9762)
In reply to: Another round of speculative-execution vulnerabilities by malmedal
Parent article: Another round of speculative-execution vulnerabilities

To further emphasize this point, the speed of a PCIe gen 6 link is now 64GHz. And the maximum length of a trace is considerably longer than 3cm.


to post comments

Another round of speculative-execution vulnerabilities

Posted Aug 9, 2023 22:21 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

Another way to think about it: these signals are largely one-way communication. If it were round-trip, the speed of light would matter. But all that really matters is how accurately you can sample the wire for a signal (PCIe gen 6 can apparently do so 64 billion times a second).

And another way to sanity check things: if the size of space between communication endpoints limited your processing rate, we'd probably still be waiting for the first (quality) images from various Mars rovers.

At least I think that's somewhat closer than what Wol has as a model.

Another round of speculative-execution vulnerabilities

Posted Aug 10, 2023 8:00 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

No. I did say the model is based on communication *between* components, ie there-and-back.

Cheers,
Wol

Another round of speculative-execution vulnerabilities

Posted Aug 10, 2023 20:28 UTC (Thu) by rschroev (subscriber, #4164) [Link]

If I were to send you a good old-fashioned letter, it would take a day or 4 (or somewhat less or more, I don't actually know; the exact value doesn't matter for this discussion); a reply from you to me would take 4 days too; there and back is then 8 days. Does that mean that I can only send you a letter once every 8 days? Only when my letter needs information from your reply; in that case I have to wait until I get your letter. But in all other cases, I can easily send new letters while old ones are still in transit. The distance between you and me sets a lower limit on latency, but does not affect bandwidth. It's the same for communication in computer systems.

Another round of speculative-execution vulnerabilities

Posted Aug 9, 2023 22:23 UTC (Wed) by malmedal (subscriber, #56172) [Link]

It's amazing how far they have pushed the technology, just ten years ago I would have said it was impossible to get that high outside of a lab-setting.

Another round of speculative-execution vulnerabilities

Posted Aug 10, 2023 10:49 UTC (Thu) by james (guest, #1325) [Link] (6 responses)

To further emphasize this point, the speed of a PCIe gen 6 link is now 64GHz.
I'm pretty sure this isn't technically correct, at least when talking about how far the signal propagates before the next signal is generated. PCIe 6.0 uses
PAM4 (Pulse Amplitude Modulation with 4 Levels) [...] a multilevel signal modulation format used to transmit data. [...] It packs two bits of information into the same amount of time on a serial channel. The utilization of PAM4 allows the PCIe 6.0 specification to reach 64 GT/s data rate and up to 256 GB/s bidirectional bandwidth via a x16 configuration.
It's basically the same concept as MLC versus SLC in flash.

This is the key difference between PCIe 5.0 (which used NRZ, or one bit per cycle) and PCIe 6.0. Both run at 32 billion signals per second: it's just with PCIe 6.0 each signal conveys two bits.

Your main point is correct, though -- this isn't what limits the length of a PCIe 6.0 connection.

Another round of speculative-execution vulnerabilities

Posted Aug 10, 2023 15:39 UTC (Thu) by kpfleming (subscriber, #23250) [Link] (5 responses)

And those 32 billion transfers per second are spread across 16 parallel lanes... so each lane is nowhere close to '64 GHz' :-)

Another round of speculative-execution vulnerabilities

Posted Aug 10, 2023 16:44 UTC (Thu) by malmedal (subscriber, #56172) [Link] (4 responses)

> And those 32 billion transfers per second are spread across 16 parallel lanes...

No. Each lane separately transmits 64 Gigabits per second.

Standard terminology is 64GT and and 32GHz.

Another round of speculative-execution vulnerabilities

Posted Aug 23, 2023 5:28 UTC (Wed) by JosephBao91 (subscriber, #157211) [Link] (3 responses)

Well, I think this statement is still not correct.
PCIe Gen5 is 32GT/s, with a frequency of 16GHz (tranfer data both posedge and negedge), and Gen6 uses PAM4 instead of NRZ, it transfers 2bits each time, and the frequency is still 16GHz, but the speed is 64GT/s.
And for hardware design, PAM4 16GHz is more difficulty compared with NRZ 16GHz.

Another round of speculative-execution vulnerabilities

Posted Aug 23, 2023 11:34 UTC (Wed) by malmedal (subscriber, #56172) [Link] (2 responses)

Do you have a reference for this? I haven't read the actual specs myself, but all the articles I've read say 5.0 is 32GHz e.g. https://www.tomshardware.com/reviews/pcie-definition,5754...

Another round of speculative-execution vulnerabilities

Posted Aug 23, 2023 12:13 UTC (Wed) by excors (subscriber, #95769) [Link] (1 responses)

I think that may just be a different meaning of "frequency": the sampling rate is 32GHz, while the Nyquist frequency (basically the frequency of the sine wave corresponding to the worst-case signal 1010101...) is 16GHz. Same as describing audio CDs as 44kHz (the sampling rate) or 22kHz (the highest audio frequency that can be encoded without aliasing) - both are reasonable in different contexts.

For example https://blog.samtec.com/post/why-did-pcie-6-0-adopt-pam4-... describes the Nyquist frequency of PCIe 5.0/6.0 as 16GHz. (The sampling rate is also the same in both, the difference is that in 6.0 each sample encodes 2 bits, so it's 16GHz Nyquist frequency with 32GHz sampling rate and 64GT/s data rate.)

Another round of speculative-execution vulnerabilities

Posted Aug 23, 2023 13:14 UTC (Wed) by malmedal (subscriber, #56172) [Link]

Thank you, sounds plausible.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds