PCI Express 7.0 v0.3 Specification Shared With PCI-SIG Members

[phoronix]

Phoronix: PCI Express 7.0 v0.3 Specification Shared With PCI-SIG Members

Ahead of the planned full specification release in 2025, the PCI-SIG has now shared with its members the first review draft "v0.3" of PCI Express 7.0...

https://www.phoronix.com/news/PCI-Express-7.0-v0.3

[rob-tech]

Lovely, however, there is still no need for PCIe 5.0 let alone 7.0 as even the best GPUs run on version 4.0 and anything more just doesn't seem to benefit the consumer at this point and isn't likely to for many years.

[torsionbar28]

Lovely, however, there is still no need for PCIe 5.0 let alone 7.0 as even the best GPUs run on version 4.0 and anything more just doesn't seem to benefit the consumer at this point and isn't likely to for many years.

This is not for the consumer. This is to support emerging server I/O standards that require more bandwidth than is currently available. 400 GBE, 800 GBE, etc. I'd be surprised if you see PCIe 7.0 at the consumer level in a decade from now even.

[stiiixy]

Exactly my thoughts. This is for those cases where there 1,934,302 CPU, GFX and AI cores feeding 4^34 TB RAM in a cube metre of datacentre space.

I'm still happily plonking along on PCIe 2 levels, despite 3/4 support.

[caligula]

This is not for the consumer. This is to support emerging server I/O standards that require more bandwidth than is currently available. 400 GBE, 800 GBE, etc. I'd be surprised if you see PCIe 7.0 at the consumer level in a decade from now even.

Well, the boot process isn't too fast these days. A faster disk would help a lot. This is with 5000 series Ryzen & PCIe 4.0 SSD:

$ systemd-analyze

Startup finished in 17.382s (firmware) + 528ms (loader) + 3.810s (kernel) + 10.344s (userspace) = 32.066s
graphical.target reached after 7.505s in userspace.

$ ​systemd-analyze blame
27.478s fstrim.service
5.894s systemd-swap.service
...
​

[mlau]

Lovely, however, there is still no need for PCIe 5.0 let alone 7.0

Sure there is: CPU-to-Chipset connections. The chipsets are usually hubs for other interfaces that get faster with every iteration (usb, thunderbolt, ...). Faster with less PCIe lanes is always good.

[Linuxxx]

Well, the boot process isn't too fast these days. A faster disk would help a lot. This is with 5000 series Ryzen & PCIe 4.0 SSD:

$ systemd-analyze

Startup finished in 17.382s (firmware) + 528ms (loader) + 3.810s (kernel) + 10.344s (userspace) = 32.066s
graphical.target reached after 7.505s in userspace.

$ ​systemd-analyze blame
27.478s fstrim.service
5.894s systemd-swap.service
...
​

On which distro?

On Lubuntu 22.04 LTS with an Intel i3-7100U (fully mitigated) + cheapest 256 GB PCIe 3.0 NVMe SSD from 2019:

Startup finished in 7.522s (firmware) + 4.515s (loader) + 5.474s (kernel) + 9.074s (userspace) = 26.586s
graphical.target reached after 9.062s in userspace

6.701s NetworkManager-wait-online.service
1.988s snapd.service
1.828s vboxdrv.service
908ms dev-nvme0n1p2.device

Your boot process should be alot faster than mine...

[stiiixy]

Oooh, looks like fun!

Startup finished in 8.415s (firmware) + 5.681s (loader) + 2.351s (kernel) + 15.132s (userspace) = 31.581s
graphical.target reached after 4.109s in userspace.


ManjaroKDE, current as of 16/06/23 (6.4rc2 kernel), 8 GB RAM, AMD A4-9125 RADEON R3

[aviallon]

Well, the boot process isn't too fast these days. A faster disk would help a lot. This is with 5000 series Ryzen & PCIe 4.0 SSD:

$ systemd-analyze

Startup finished in 17.382s (firmware) + 528ms (loader) + 3.810s (kernel) + 10.344s (userspace) = 32.066s
graphical.target reached after 7.505s in userspace.

$ ​systemd-analyze blame
27.478s fstrim.service
5.894s systemd-swap.service
...
​

You are spending an awfully long time in firmware.
Perhaps enable Fast boot in your "BIOS" settings?

[caligula]

You are spending an awfully long time in firmware.
Perhaps enable Fast boot in your "BIOS" settings?

Unfortunately it's already using the fastest boot mode that still enables USB keyboard (no overclocking, no CSM, many things disabled - training the DDR4 XMP settings takes time). I need the keyboard to choose an alternative entry in systemd-boot if something fails. I tried to enable the fastest mode earlier, but had to reset the BIOS settings. I didn't want to reconfigure all temp curves for the fans so it's easier this way.