PCIe 3/4/5/6 : ce qui change pour les utilisateurs

Ce qui change de PCIe 3 à 6 (et ce qui ne change pas)

Le changement principal entre les générations PCIe est le débit par voie. La note fine est la difficulté à fournir ce débit de manière fiable sur
une carte mère réelle, avec des longueurs de piste réelles, des risers réels, des backplanes réels et des attentes d’entreprise réelles.

Ce qui change

• Débit par voie : chaque génération jusqu’à PCIe 5 double grossièrement le taux brut de transfert (GT/s). PCIe 6 double encore, mais modifie le schéma d’encodage et de tramage.
• Exigences d’intégrité du signal : à PCIe 5 et surtout 6, « il suffit de le routage » ne suffit plus. Les retimers, meilleurs matériaux et layouts plus stricts apparaissent.
• Comportement des erreurs dans les logs : des vitesses plus élevées signifient moins de marge ; les liens marginaux apparaissent comme des erreurs corrigées avant de tomber complètement.
• Économie des lanes plateforme : plus de périphériques se disputent un nombre fini de lanes CPU ; les fournisseurs s’appuient sur la bifurcation, les switches et des câblages de slots astucieux.
• Thermique et alimentation : les NVMe Gen5 peuvent être rapides et aussi excellents pour chauffer l’air du datacenter. Le débit est optionnel ; la physique, non.

Ce qui ne change pas (beaucoup)

• Attentes de latence : les générations PCIe ne divisent pas magiquement votre latence IO de la même manière que le débit double. Beaucoup d’applications « lentes » font de la mise en file, pas une limitation du lien.
• « x16 » reste « x16 lanes », pas une garantie : un slot physique x16 peut être électrique x8 ou x4, ou réduire sa largeur à l’exécution.
• La topologie compte toujours plus que le marketing : deux disques NVMe Gen4 x4 derrière un seul uplink peuvent se battre comme des frères sur la banquette arrière.

Ma règle opérationnelle : n’améliorez pas la génération PCIe pour la « vitesse » sauf si vous pouvez pointer un périphérique et une charge de travail précis qui atteignent déjà une limite de lien.
Autrement vous achetez du débit optionnel et une complexité obligatoire.

Blague n°1 : le débit PCIe, c’est comme une salle de réunion vide — tout le monde suppose qu’elle est disponible jusqu’au moment où la réunion commence.

Maths de débit que vous pouvez faire en tête

Si vous ne pouvez pas estimer le débit PCIe en 10 secondes, vous prendrez de mauvaises décisions d’upgrade et vous serez une proie facile pour les slides commerciaux.
Voici le modèle mental qui survit en astreinte.

Termes clés (utilisez-les correctement en réunion)

• GT/s : gigatransferts par seconde. Ce n’est pas la même chose que gigabits par seconde ; l’encodage compte.
• Surcharge d’encodage : PCIe 3–5 utilise 128b/130b (environ 1,54% d’overhead). PCIe 1–2 utilisait 8b/10b (20% d’overhead). PCIe 6 utilise un nouveau schéma avec FLITs et FEC.
• Largeur du lien : x1, x4, x8, x16 lanes. Largeur et vitesse se multiplient.
• Bidirectionnel : le débit PCIe est par direction. N’ajoutez pas les deux directions sauf si votre charge utilise vraiment les deux simultanément.

Règle pratique de débit par voie (une seule direction)

Débit effectif approximatif (après 128b/130b) par voie :

• PCIe 3.0 : ~1 GB/s par voie → x4 ≈ 4 GB/s, x16 ≈ 16 GB/s
• PCIe 4.0 : ~2 GB/s par voie → x4 ≈ 8 GB/s, x16 ≈ 32 GB/s
• PCIe 5.0 : ~4 GB/s par voie → x4 ≈ 16 GB/s, x16 ≈ 64 GB/s
• PCIe 6.0 : commercialisé comme « double encore », mais le débit utilisable réel dépend davantage de l’implémentation, du FEC et des patterns de charge que pour les générations antérieures.

Traduction pratique :

• Un SSD NVMe typique est x4. S’il est Gen3 x4, il plafonne autour de ~3–3,5 GB/s en pratique. Gen4 x4 peut atteindre ~7 GB/s. Gen5 x4 peut monter à ~12–14 GB/s en lectures séquentielles — si il ne se met pas en thermal throttle.
• Une NIC 100GbE représente ~12,5 GB/s en débit lineaire avant overheads. Cela signifie que Gen3 x16 (≈16 GB/s) peut le porter, Gen3 x8 (≈8 GB/s) ne le peut pas sans compromis.

Si vous ne retenez qu’une chose : le débit est facile ; le débit partagé est l’endroit où les carrières vont mourir.

Qui bénéficie vraiment : NVMe, GPU, NIC et cartes exotiques

Stockage NVMe

NVMe est le consommateur le plus visible de « PCIe qui accélère ». Mais le lien n’est qu’une porte.
Les autres portes : contrôleur flash, NAND, firmware, comportement de profondeur de file d’attente, système de fichiers, temps CPU par IO et le pattern d’IO de votre application.

• Gen3 → Gen4 : significatif pour les SSD haut de gamme et les baies multi-disques effectuant des lectures/écritures séquentielles ou des IO fortement parallèles.
• Gen4 → Gen5 : utile pour moins de charges que vous ne le pensez. Il brille pour les gros transferts séquentiels, les activités de reconstruction RAID, les checkpoint rapides et certains pipelines analytiques.
• IO aléatoire : souvent limité par la latence du périphérique et la surcharge CPU plutôt que par la bande passante du lien. Si votre latence p99 est dominée par la pile logicielle, Gen5 ne vous sauvera pas.

GPU et accélérateurs

Pour beaucoup de charges GPU, PCIe n’est pas le chemin principal une fois les données sur la carte. Mais « une fois les données sur la carte » représente beaucoup de travail dans cette phrase.
L’entraînement peut être moins sensible que les pipelines d’inférence qui streament constamment, et la communication multi-GPU peut utiliser NVLink/Infinity Fabric plutôt que PCIe.

• x8 vs x16 pour GPU : pour beaucoup de calculs, vous ne remarquerez peut-être pas. Pour des pipelines gourmands en données, vous le remarquerez absolument.
• P2P : la topologie PCIe détermine si les GPUs peuvent faire du P2P efficacement. Un switch ou un root complex incorrect peut casser la fête.

Réseau (25/100/200/400GbE)

Le réseau est l’endroit où les idées fausses sur PCIe coûtent cher. Une NIC n’a pas seulement besoin du débit lineaire ; elle a besoin d’efficacité DMA, de modération d’interrupts, de locality CPU et d’un headroom PCIe suffisant pour éviter que les micro-bursts ne deviennent des pertes.

• 100GbE : confortable sur Gen4 x8, limite sur Gen3 x16 pour des systèmes chargés, et mauvaise idée sur Gen3 x8 sauf si vous acceptez consciemment le compromis de débit.
• 200/400GbE : vous planifiez essentiellement une topologie PCIe, pas « ajouter une NIC ». Gen5 et une allocation de lanes soigneuse deviennent partie intégrante du design réseau.

HBA, cartes RAID, DPU, cartes d’acquisition, « ce FPGA »

Les cartes spécialisées ont souvent des contraintes particulières : largeurs de lien fixes, exigences de slot strictes, mappings BAR importants, bugs de firmware, et une propension à échouer de façons qui ressemblent à un « problème Linux ».
Avec PCIe 5/6, les cartes peuvent aussi nécessiter des retimers pour être stables à pleine vitesse.

Topologie : lanes, root complexes, switches et pourquoi votre slot x16 ment

Les générations PCIe sont des limites de vitesse. La topologie est le réseau routier. La plupart des problèmes de performance réels ne sont pas « la limitation de vitesse est basse » mais « vous avez fait passer l’autoroute par un parking ».

Budget de lanes : le seul tableur que vous devriez vraiment maintenir

Les CPU exposent un nombre fini de lanes PCIe. Ces lanes sont réparties en ports racine (root complexes). Les cartes mères mappent ensuite les slots physiques et les périphériques embarqués sur ces ports.
Ajoutez un second CPU et vous obtenez plus de lanes — plus la complexité NUMA et le trafic inter-socket.

Conséquences pratiques :

• Un slot x16 peut partager des lanes avec deux connecteurs M.2.
• Deux slots x16 peuvent devenir x8/x8 quand les deux sont peuplés.
• Un 10/25/100GbE « onboard » peut consommer des lanes précieuses que vous croyiez libres.
• Les backplanes NVMe frontaux utilisent souvent des switches PCIe pour distribuer les lanes ; ces switches peuvent oversubscriber les uplinks.

Switches PCIe : utiles, pas magiques

Un switch PCIe est un dispositif de fan-out : un lien upstream, plusieurs liens downstream. Il permet beaucoup de baies NVMe sans dédier x4 par disque jusqu’au CPU.
Mais il introduit aussi :

• Oversubscription : 16 disques derrière un switch avec un uplink x16 signifie que les disques partagent le débit. Ça peut aller. Ça peut aussi être le goulot d’étranglement.
• Latence additionnelle : généralement petite, parfois notable pour des charges ultra-basse-latence.
• Modes de défaillance : un switch ou son firmware peut se bloquer et emporter tout un segment avec lui.

Bifurcation : la fonctionnalité BIOS qui décide de votre sort

La bifurcation divise un lien plus large en plusieurs liens plus étroits (ex. x16 en 4×x4). C’est comment vous faites tourner des cartes porteuse quad-NVMe sans switch.
Mais la bifurcation exige le support plateforme et des réglages BIOS corrects.

Si vous branchez une carte 4×M.2 en vous attendant à voir quatre disques et que vous n’en voyez qu’un, ce n’est pas Linux qui fait des siennes. C’est que vous n’avez pas activé la bifurcation.

Localité NUMA : le tueur silencieux de débit

Sur des systèmes dual-socket, un périphérique PCIe est attaché au root complex d’un CPU. Si votre charge tourne sur l’autre socket, chaque DMA et chaque interrupt peut traverser l’interconnect.
Les symptômes ressemblent à « PCIe est lent », mais la correction est l’affinité CPU et le placement correct du périphérique, pas une nouvelle carte mère.

PCIe 6.0 : pourquoi ce n’est pas « juste deux fois plus rapide »

PCIe 6.0 est l’endroit où l’industrie arrête de prétendre que l’augmentation de fréquence est gratuite.
Au lieu de seulement augmenter les GT/s, PCIe 6 change la manière dont les données sont empaquetées (mode FLIT) et ajoute la correction d’erreurs en avant (FEC).

Ce que cela signifie opérationnellement

• Plus de résilience au bruit, plus de complexité : le FEC aide à soutenir des vitesses plus élevées mais ajoute du travail d’encodage/décodage et change la visibilité des erreurs.
• Différents compromis de latence : le FEC et le tramage FLIT peuvent ajouter une petite latence, tout en permettant au système global de fonctionner plus vite. Si vous « sentez » PCIe 6 dépend de la sensibilité de la charge.
• Intégrité du signal plus stricte : cartes, risers, câbles et backplanes doivent être conçus pour cela. « Il poste en Gen6 » n’est pas la même chose que « il tourne stable en Gen6 sous charge pendant 18 mois ».

La plupart des organisations devraient traiter PCIe 6 comme un choix de plateforme à adopter quand votre écosystème l’exige (NICs nouvelle génération, accélérateurs, infrastructure composable),
et non comme un « upgrade stockage » occasionnel.

Faits intéressants et courte histoire (pour ancrer votre modèle mental)

1. PCIe a remplacé PCI/AGP en passant au mode série : les lanes série de PCIe ont été un pivot par rapport aux bus parallèles larges qui galéraient avec l’horloge et le skew.
2. PCIe 1.0 et 2.0 utilisaient l’encodage 8b/10b : vous « perdiez » 20% de la bande brute à cause de l’overhead. Le 128b/130b de PCIe 3.0 a été un grand saut pratique.
3. NVMe n’a pas juste « utilisé PCIe » : il a été conçu pour réduire la charge logicielle et supporter des files d’attente profondes comparé à AHCI, pensé pour les disques rotatifs.
4. M.2 est un format, pas un protocole : M.2 peut transporter SATA ou PCIe/NVMe. Confondre les deux est une erreur d’achat classique.
5. « x16 slot » est devenu un artefact culturel des GPU : les serveurs ont gardé le standard physique, mais le câblage électrique varie énormément selon les fournisseurs et les SKU.
6. Les retimers sont devenus courants avec Gen5 : les générations précédentes pouvaient souvent se passer de re-drivers ou de rien ; Gen5 pousse les systèmes vers un conditionnement actif du signal.
7. Les switches PCIe ont discrètement permis l’ère des serveurs NVMe : les baies NVMe denses sont souvent une histoire de design de switch, pas d’« beaucoup de lanes ».
8. Resizable BAR est passé du niche au mainstream : des mappings BAR plus larges améliorent les patterns d’accès CPU pour certains périphériques ; le support plateforme a mûri avec le temps.
9. Les erreurs corrigées ne sont pas « acceptables » : les systèmes d’entreprise surveillent de plus en plus les taux d’erreurs AER corrigées car elles prédisent l’instabilité future à hautes vitesses.

Trois micro-histoires d’entreprise venues des tranchées

Micro-histoire n°1 : l’incident causé par une fausse supposition

Une entreprise de taille moyenne a déployé de nouveaux hôtes de base de données avec du « Gen4 partout ». L’objectif était simple : plus de bande NVMe pour accélérer les requêtes analytiques.
Les hôtes étaient dual-socket, remplis de NVMe U.2 dans les baies frontales et disposaient d’une NIC costaud pour la réplication.

La fausse supposition : chaque disque NVMe avait un chemin x4 dédié vers le CPU. En réalité, le backplane frontal utilisait un switch PCIe avec un seul lien upstream.
En OLTP normal, personne ne l’a remarqué. Pendant les tâches batch nocturnes, tout le cluster est devenu une trompette triste : les temps de requête ont doublé, la latence de réplication a grimpé,
et les tableaux de bord d’« utilisation disque » ressemblaient à de l’art moderne.

L’ingénieur d’astreinte a fait le rituel habituel : blâmer le système de fichiers, le noyau, le fournisseur de stockage, la phase de la lune.
Puis il a exécuté quelques tests ciblés : un disque seul atteignait le débit attendu ; plusieurs disques ensemble plafonnaient à un nombre rond suspect qui correspondait à l’uplink.
Le plateau était la topologie, pas les disques.

La correction a été ennuyeuse : rééquilibrer les baies peuplées par domaine de switch, déplacer la NIC de réplication hors du root complex partagé, et accepter que le serveur
était conçu pour la densité de capacité, pas la saturation complète du débit. Ils ont aussi mis à jour leur checklist d’approvisionnement interne pour exiger un diagramme de topologie PCIe publié.
Soudain « Gen4 partout » est devenu « Gen4 là où ça compte », et les incidents ont cessé.

Micro-histoire n°2 : l’optimisation qui a mal tourné

Une équipe d’inférence GPU voulait réduire la latence. Ils ont remarqué que les GPU négociaient en Gen4 mais ont pensé : « Forçons Gen5 dans le BIOS. Lien plus rapide, inférence plus rapide. »
La plateforme le supportait, les GPU le supportaient, et le changement a pris environ 30 secondes.

Pendant une journée, tout a semblé aller bien. Puis des pannes intermittentes ont commencé : erreurs CUDA occasionnelles, réinitialisations de driver soudaines et blocages rares de nœuds sous charge maximale.
Les logs avaient du spam AER — d’abord des erreurs corrigées, puis des non corrigées occasionnelles. Les redémarrages « réglaient » le problème, ce qui est un signe qu’il reviendra pendant vos prochaines vacances.

La vraie cause était la marge de signal. Les nœuds utilisaient de longs risers et un châssis dense. À la vitesse Gen5, le lien fonctionnait avec moins de marge qu’une compagnie aérienne low-cost.
Le FEC n’était pas en jeu (Gen5), et les erreurs corrigées étaient un avertissement précoce que le canal physique était marginal.

Le rollback a été immédiat : remettre les slots en Auto/Gen4, réduire les erreurs à quasiment zéro et retrouver la stabilité. La latence nette s’est améliorée de toute façon parce que
le système a arrêté de réessayer et de se bloquer. Ils ont ensuite déployé une plateforme Gen5 validée avec des retimers appropriés quand ils ont réellement eu besoin du débit pour l’ingestion multi-GPU.

Micro-histoire n°3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de stockage d’entreprise avait une politique qui paraissait bureaucratique : avant qu’un hôte n’aille en production, ils capturaient un « bundle de vérité matérielle ».
Il incluait la topologie PCIe, vitesses/largeurs négociées, versions de firmware et un profil fio de référence sur chaque NVMe.

Des mois plus tard, un lot de serveurs a commencé à reporter des timeouts NVMe sporadiques. Pas suffisants pour faire échouer les checks de santé. Juste assez pour ruiner la latence p99 et énerver l’équipe DB.
Le fournisseur insistait sur le fait que c’était un « problème logiciel » car les disques passaient SMART.

L’équipe de stockage a comparé le bundle de vérité courant avec la baseline. Un détail a sauté aux yeux : plusieurs disques négociaient maintenant une largeur de lien plus faible qu’avant.
Pas la vitesse — la largeur. x4 était devenu x2 sur un sous-ensemble de baies.

Cela a pointé directement vers un problème physique : mauvaise insertion du backplane, câble marginal ou retimer défaillant. Ils ont ouvert le châssis,
réinséré la connexion du backplane et les liens sont revenus en x4 avec des compteurs d’erreurs propres. Les timeouts ont disparu.
Pas de débogage héroïque. Juste des preuves, et une baseline pour comparer.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici des vérifications testées sur le terrain. Chacune a : la commande, ce que vous devriez voir et la décision à prendre.
Exécutez-les sur des hôtes Linux où vous suspectez un goulot PCIe ou un lien mal négocié.

Tâche 1 : Identifier le périphérique et son adresse PCIe

cr0x@server:~$ lspci -nn | egrep -i 'non-volatile|ethernet|vga|3d|infiniband'
0000:01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]
0000:3b:00.0 Ethernet controller [0200]: Mellanox Technologies MT28908 Family [ConnectX-6] [15b3:101b]
0000:af:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:20b0]

Sens : Vous avez maintenant des adresses BDF (domain:bus:device.function) comme 0000:01:00.0.
Décision : Utilisez la BDF dans les commandes suivantes pour inspecter la largeur/vitesse du lien et les compteurs d’erreurs pour le périphérique exact qui vous intéresse.

Tâche 2 : Vérifier la vitesse et la largeur négociées (ce que tout le monde oublie)

cr0x@server:~$ sudo lspci -s 0000:01:00.0 -vv | egrep -i 'LnkCap:|LnkSta:'
LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x2 (downgraded)

Sens : Le périphérique est capable de Gen4 x4 (16GT/s x4) mais tourne actuellement à une vitesse Gen3-ish (8GT/s) et largeur x2.
Décision : Traitez cela comme une mauvaise configuration ou un problème d’intégrité du signal, pas comme un « SSD lent ». Vérifiez le câblage du slot, la bifurcation, le BIOS, les risers et les erreurs AER.

Tâche 3 : Trouver le port parent et voir si le goulot est en amont

cr0x@server:~$ sudo lspci -t
-[0000:00]-+-00.0  Host bridge
           +-01.0-[01]----00.0  Non-Volatile memory controller
           \-03.0-[3b]----00.0  Ethernet controller

Sens : Vous voyez un arbre : root complex → bus → device. Cela vous aide à comprendre ce qui partage un lien upstream.
Décision : Si plusieurs périphériques lourds sont derrière le même port upstream ou switch, planifiez la contention ou déplacez des périphériques vers d’autres root complexes si possible.

Tâche 4 : Confirmer les infos de lien NVMe via sysfs (rapide et scriptable)

cr0x@server:~$ readlink -f /sys/class/nvme/nvme0/device
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0

cr0x@server:~$ cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/current_link_speed
8.0 GT/s

cr0x@server:~$ cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/current_link_width
2

Sens : Même histoire que lspci, mais plus adaptée à l’automatisation.
Décision : Construisez une vérification fleet qui alerte quand des périphériques critiques négocient en dessous de la vitesse/largeur attendue.

Tâche 5 : Chercher les erreurs AER PCIe dans le log du noyau

cr0x@server:~$ sudo dmesg -T | egrep -i 'AER:|pcieport|Corrected error|Uncorrected'
[Sat Jan 10 10:21:34 2026] pcieport 0000:00:01.0: AER: Corrected error received: 0000:01:00.0
[Sat Jan 10 10:21:34 2026] nvme 0000:01:00.0: AER: [0] RxErr

Sens : Les erreurs corrigées signifient que le lien récupère des problèmes de couche physique. Cela corrèle souvent avec des downgrades, des retries ou de l’instabilité sous charge.
Décision : Si les erreurs corrigées sont fréquentes, arrêtez d’« optimiser » et commencez à stabiliser : réinsérez, changez les risers, mettez à jour le firmware ou réduisez la vitesse négociée (Auto/Gen4 au lieu de forcer Gen5).

Tâche 6 : Inspecter les capacités PCIe et les réglages de Max Payload

cr0x@server:~$ sudo lspci -s 0000:3b:00.0 -vv | egrep -i 'MaxPayload|MaxReadReq|DevCap:|DevCtl:'
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
        MaxPayload 256 bytes, MaxReadReq 512 bytes

Sens : Le périphérique supporte 512B payload, mais est configuré à 256B. Cela peut importer pour des périphériques à haut débit (souvent les NICs).
Décision : Ne changez pas cela au hasard en production. Si vous avez un problème de débit prouvé et des recommandations fournisseur, alignez les tailles de payload le long du chemin. Sinon, laissez tel quel.

Tâche 7 : Confirmer les capacités du NVMe et le plafond de performance actuel

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0 | egrep -i 'mn|fr|rab|mdts|oacs'
mn      : ACME Gen4 SSD 3.84TB
fr      : 2B1QGXA7
rab     : 6
mdts    : 9
oacs    : 0x17

cr0x@server:~$ sudo nvme list
Node             SN                   Model                      Namespace Usage                      Format           FW Rev
---------------- -------------------- -------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1      S1234567890          ACME Gen4 SSD 3.84TB       1         3.84  TB /   3.84  TB    512   B +  0 B  2B1QGXA7

Sens : Vous avez la révision firmware et l’identification modèle pour le support fournisseur, et MDTS indique des tailles de transfert max.
Décision : Si vous voyez des downgrades de lien, vous avez maintenant l’identité exacte du périphérique pour corréler avec des bugs de firmware connus ou des listes de compatibilité plateforme.

Tâche 8 : Mesurer le débit réel avec fio (et bien l’interpréter)

cr0x@server:~$ sudo fio --name=seqread --filename=/dev/nvme0n1 --direct=1 --ioengine=io_uring --bs=1m --iodepth=16 --rw=read --numjobs=1 --runtime=20 --time_based --group_reporting
seqread: (groupid=0, jobs=1): err= 0: pid=21456: Sat Jan 10 10:33:10 2026
  read: IOPS=6100, BW=6100MiB/s (6396MB/s)(119GiB/20001msec)

Sens : ~6.1 GiB/s suggère que Gen4 x4 est plausible ; Gen3 x4 plafonnerait généralement plus bas.
Décision : Si le débit est bien inférieur à l’attendu, corrélez avec la largeur/vitesse du lien. Si le lien est correct, cherchez le thermal throttling, la saturation CPU, le système de fichiers ou la couche RAID.

Tâche 9 : Vérifier les signes de thermal throttling NVMe

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i 'temperature|warning|critical|thm'
temperature                             : 78 C
warning_temp_time                       : 632
critical_temp_time                      : 0

Sens : Le disque a passé un temps significatif au-dessus de sa température d’avertissement. Cela signifie souvent qu’il se bride pendant les benchmarks ou jobs batch.
Décision : Améliorez le flux d’air, ajoutez des dissipateurs, réduisez la densité de disques par châssis ou acceptez un débit soutenu plus faible. Passer à Gen5 sans refroidissement est de l’auto-sabotage.

Tâche 10 : Vérifier le lien PCIe de la NIC et s’assurer qu’il correspond aux ambitions line-rate

cr0x@server:~$ sudo lspci -s 0000:3b:00.0 -vv | egrep -i 'LnkCap:|LnkSta:'
LnkCap: Port #0, Speed 16GT/s, Width x8
LnkSta: Speed 16GT/s, Width x8

Sens : Gen4 x8 est une base solide pour 100GbE ; pour 200GbE vous serez plus prudent selon overhead et patterns de trafic.
Décision : Si une NIC 100GbE montre Gen3 x8, attendez-vous à des douleurs sous charge. Déplacez-la vers un meilleur slot ou ajustez vos attentes.

Tâche 11 : Vérifier la localité NUMA d’un périphérique PCIe

cr0x@server:~$ cat /sys/bus/pci/devices/0000:3b:00.0/numa_node
1

cr0x@server:~$ lscpu | egrep -i 'NUMA node\(s\)|NUMA node1 CPU\(s\)'
NUMA node(s):                         2
NUMA node1 CPU(s):                    32-63

Sens : La NIC est attachée au NUMA node 1. Si vos threads réseau tournent sur les CPUs 0–31, vous payez des pénalités inter-socket.
Décision : Pincez les IRQs et les threads applicatifs au NUMA local pour des chemins haut débit ou basse latence.

Tâche 12 : Inspecter la distribution des interruptions (repérer le classique « tout sur CPU0 »)

cr0x@server:~$ cat /proc/interrupts | egrep -i 'mlx|nvme' | head
  88:  1023491    2345    1987    2101  IR-PCI-MSI 524288-edge  mlx5_comp0@pci:0000:3b:00.0
  89:  1098833    2401    2011    2190  IR-PCI-MSI 524289-edge  mlx5_comp1@pci:0000:3b:00.0
 120:   883221    1900    1750    1802  IR-PCI-MSI 1048576-edge  nvme0q0@pci:0000:01:00.0

Sens : Les interruptions sont réparties sur les CPUs. Si vous voyez un CPU faire tout le travail, le débit chute et la latence explose.
Décision : Si déséquilibre, ajustez l’affinité IRQ (ou activez irqbalance de manière réfléchie) et alignez avec la localité NUMA.

Tâche 13 : Vérifier le throttling de fréquence CPU qui fait croire à un « goulot PCIe »

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 2 --num_iterations 3
Avg_MHz  Busy%  Bzy_MHz  TSC_MHz  IRQ  SMI  CPU%c1  CPU%c6
  1875    92.1    2035     2400  152k    0    0.2    6.8

Sens : Si Avg_MHz est bien en-dessous de l’attendu sous charge, des limites de puissance ou de température peuvent brider le traitement IO.
Décision : N’achetez pas des lanes PCIe 5 pour réparer un CPU qui tourne à mi-vitesse. Réglez le refroidissement, les limites d’alimentation et les profils BIOS en premier.

Tâche 14 : Vérifier la vitesse négociée sur le root port aussi (attraper les downgrades en amont)

cr0x@server:~$ sudo lspci -s 0000:00:01.0 -vv | egrep -i 'LnkCap:|LnkSta:'
LnkCap: Port #1, Speed 16GT/s, Width x16
LnkSta: Speed 8GT/s (downgraded), Width x16

Sens : Même si l’endpoint a l’air correct, un port upstream peut tourner à vitesse inférieure, contraignant tout ce qui est en aval.
Décision : Cherchez des réglages BIOS forçant une génération, des problèmes de firmware ou d’intégrité du signal affectant tout le segment.

Blague n°2 : Forcer Gen5 dans le BIOS, c’est comme rouler plus vite dans le brouillard parce que le compteur affiche une vitesse plus élevée.

Feuille de diagnostic rapide (premier/deuxième/troisième)

Quand la performance est mauvaise, vous avez besoin d’une séquence impitoyable qui vous amène rapidement au facteur limitant.
Voici la version astreinte.

Première étape : vérifiez que le lien est bien ce que vous pensez

• Vérifiez LnkSta speed/width pour le périphérique suspect et son port upstream (lspci -vv).
• Vérifiez sysfs current_link_speed/current_link_width pour la vérité scriptable.
• Décision : Si downgraded, arrêtez. Réparez la topologie/physique/BIOS avant de benchmarker autre chose.

Deuxième étape : cherchez l’instabilité de couche physique et les retries

• Scannez dmesg pour les erreurs AER corrigées ; corrélez avec les périodes de charge.
• Décision : Le spam d’erreurs corrigées n’est pas « acceptable ». C’est le système qui brûle de la marge. Réduisez la vitesse (Auto), réinsérez, changez les risers, mettez à jour le firmware.

Troisième étape : isolez si le périphérique est la limite ou si la plateforme l’est

• Benchmark mono-périphérique (fio sur un NVMe ; iperf ou test trafic sur une NIC ; tests memcpy GPU pour host-to-device).
• Benchmark à l’échelle (beaucoup de NVMe en parallèle, plusieurs queues NIC, plusieurs GPUs) et cherchez un plateau.
• Décision : Un plateau à un nombre rond correspondant à un uplink ou à la bande d’un root port crie « goulot partagé » (switch, uplink ou root port).

Quatrième étape (si nécessaire) : vérifiez NUMA et la surcharge CPU

• Noeud NUMA du périphérique et distribution des interruptions.
• Fréquence/pouvoir CPU sous charge.
• Décision : Si trafic inter-socket ou throttling CPU présent, corrigez l’affinité et l’énergie plateforme avant de blâmer la génération PCIe.

Une citation pour rester honnête : L’espoir n’est pas une stratégie — idée paraphrasée souvent attribuée dans les cercles d’ingénierie aux leaders opérationnels.
L’aspect utile est le message : mesurez, puis décidez.

Erreurs courantes : symptômes → cause racine → correction

1) « Mon SSD Gen4 fonctionne comme du Gen3 »

Symptômes : lectures séquentielles plafonnent autour de ~3 GB/s ; fio n’en dépasse jamais ; le disque tourne frais et sain.

Cause racine : le périphérique a négocié en Gen3 ou largeur réduite (x2) à cause du câblage du slot, de la bifurcation, d’un riser ou d’un BIOS forçant la compatibilité.

Correction : vérifiez LnkSta ; déplacez le disque/carte vers un slot connu bon ; activez la bifurcation ; mettez la vitesse PCIe en Auto ; mettez à jour BIOS et firmware du backplane.

2) « C’est rapide seul mais lent avec beaucoup de disques »

Symptômes : un NVMe atteint le débit attendu ; 8+ disques ensemble frappent un plafond dur ; la latence augmente avec la concurrence.

Cause racine : oversubscription du switch PCIe ou bande uplink/root partagée.

Correction : mappez les disques par domaine de switch ; répartissez la charge ; utilisez plus d’uplinks (dépend de la plateforme) ; acceptez l’oversubscription et ajustez la planification des charges.

3) « Après une mise à jour firmware, on a des erreurs PCIe bizarres »

Symptômes : nouvelles erreurs AER corrigées ; réinitialisations occasionnelles de périphériques ; downtrains de lien.

Cause racine : paramètres d’égalisation changés ou nouvelle génération par défaut ; le canal marginal est maintenant exposé.

Correction : revenir/avancer le firmware selon le conseil du fournisseur ; mettre Auto plutôt que forcer la vitesse ; vérifier la compatibilité retimer/backplane.

4) « 100GbE n’atteint pas le line rate »

Symptômes : le débit plafonne à ~60–80Gbps ; l’utilisation CPU est élevée ; pertes ou pauses sous charge.

Cause racine : la NIC est dans un slot Gen3 x8 ; IRQs non réparties ; mismatch NUMA ; payload trop petit ou réglages sous-optimaux.

Correction : placez la NIC sur Gen4 x8 ou Gen3 x16 ; alignez le NUMA ; vérifiez les interruptions ; n’ajustez le payload que si vous savez pourquoi et pouvez tester en sécurité.

5) « Entraînement GPU OK, pipeline d’inférence saccadé »

Symptômes : utilisation compute en baisse ; transferts host-to-device dominants ; latence p99 en pic.

Cause racine : largeur de lien GPU réduite (x8), root complex partagé avec NVMe, ou DMA cross-socket.

Correction : validez largeur/vitesse du lien GPU ; déplacez les périphériques vers d’autres root complexes ; pinnez les threads CPU au NUMA local ; évitez la contention de stockage lourde sur le même segment.

6) « Tout semble correct, mais la latence p99 IO est mauvaise »

Symptômes : les tests de bande passante semblent corrects ; pourtant la latence p99 applicative est élevée ; le CPU est occupé en softirq ou chemins de système de fichiers.

Cause racine : surcharge logicielle, mise en file ou contention ; pas la génération PCIe.

Correction : profilez (off-CPU time, ordonnanceur IO, système de fichiers) ; réduisez la contention ; utilisez io_uring où approprié ; scalez le CPU et ajustez l’affinité.

Listes de contrôle / plan pas-à-pas

Checklist A : avant d’acheter du matériel (arrêtez de payer pour des lanes fantômes)

1. Listez les périphériques selon leurs besoins en bande : nombre NVMe, vitesse NIC, nombre GPU, tout HBA/DPU.
2. Calculez les lanes requises par périphérique (généralement x4 par NVMe, x8/x16 par NIC/GPU selon la classe).
3. Demandez le diagramme de topologie PCIe de la plateforme pour le châssis + carte mère + option backplane exacts.
4. Identifiez où existent des switches et quelles sont les largeurs d’uplink.
5. Confirmez le support de bifurcation pour les cartes porteuses.
6. Confirmez la présence/exigences de retimers pour Gen5+ sur vos risers/backplanes prévus.
7. Décidez si vous préférez : moins de périphériques à pleine bande, ou plus de périphériques avec oversubscription.

Checklist B : mise en service d’un serveur (faites du « hardware truth » une habitude)

1. Capturez lspci -nn et lspci -t outputs.
2. Pour chaque périphérique critique : enregistrez LnkCap et LnkSta et l’état du port root upstream.
3. Consignez les versions de firmware : BIOS, BMC, NIC, NVMe.
4. Exécutez fio mono-périphérique et un petit stress multi-périphériques (dans des limites sûres).
5. Vérifiez dmesg pour les erreurs AER durant le stress.
6. Sauvegardez ce bundle dans votre CMDB ou ticket. Votre futur vous enverra une note de remerciement.

Checklist C : quand vous montez la génération PCIe (le plan « ne cassez pas la prod »)

1. Prouvez que le système actuel est limité par le lien (plateau + état du lien correct) avant de dépenser de l’argent.
2. Mettez à niveau les composants plateforme en ensemble : carte + risers + backplane/retimers + firmware. Mixer des attentes Gen5 avec des mécaniques ère-Gen4 est un hobby, pas une stratégie.
3. Validez la stabilité sous charge et température pires cas. Pas un benchmark de 30 secondes.
4. Surveillez les taux d’erreurs AER corrigées et les downtrains comme signaux SLO de première classe.
5. Si vous devez forcer une génération, faites-le seulement après validation — et documentez la procédure de rollback.

FAQ

1) Ai-je besoin de PCIe 5.0 pour NVMe ?

Seulement si votre charge peut utiliser le débit. Nombre de bases de données et services sont limités par la latence ou le CPU. Si vous faites de gros IO séquentiels ou de l’ingestion massive parallèle, Gen5 peut aider.
Autrement, Gen4 est généralement le point d’équilibre en coût, thermique et sérénité.

2) Pourquoi mon périphérique indique « downgraded » dans LnkSta ?

Parce que la négociation s’est arrêtée sur une vitesse/largeur inférieure due aux limites de la plateforme, réglages BIOS, qualité du câblage/riser ou problèmes d’intégrité du signal.
Traitez-le comme un problème de configuration/physique jusqu’à preuve du contraire.

3) Le débit PCIe est-il par direction ou total ?

Par direction. Les liens PCIe sont full-duplex. Ne doublez pas les chiffres sauf si votre charge lit et écrit à haut débit simultanément.

4) PCIe 6.0 réduit-il la latence ?

Pas automatiquement. PCIe 6 vise surtout à permettre un plus haut débit avec FLIT mode et FEC. La latence peut s’améliorer dans certains cas grâce à moins de goulets,
mais elle peut aussi rester inchangée ou être légèrement impactée par le tramage/la correction d’erreurs.

5) Un switch PCIe est-il mauvais pour le stockage ?

Non. C’est la façon de construire des systèmes NVMe denses. Le risque est l’oversubscription et les goulots uplink partagés. Si vous comprenez la largeur d’uplink et la concurrence de votre workload,
un switch est parfaitement raisonnable.

6) Mon GPU tourne à x8. Dois-je paniquer ?

Pas forcément. Beaucoup de workloads de calcul n’utilisent pas pleinement PCIe. Mais si vous streammez des données continuellement, faites des transferts host-device fréquents ou dépendez de chemins P2P,
x8 peut nuire. Mesurez votre pipeline avant de redesigner le châssis.

7) Quelle est la raison la plus fréquente pour laquelle NVMe est lent dans un nouveau serveur ?

Mauvaise négociation du lien (downtrain Gen ou réduction de largeur) ou oversubscription de topologie. Ensuite : throttling thermique, mismatch NUMA et limites de puissance CPU.

8) Dois-je forcer la vitesse PCIe dans le BIOS ?

Évitez-le sauf si vous avez une raison validée. Les réglages forcés de génération sont excellents pour la reproduction en laboratoire et terribles comme « tweak de performance » sur des canaux marginaux.
Utilisez Auto, puis corrigez les problèmes de stabilité sous-jacents.

9) Comment savoir si je suis limité par le PCIe ou par le logiciel ?

Si LnkSta est correct et que vous n’atteignez toujours pas le débit attendu, comparez mono-périphérique vs montée en charge multi-périphériques et vérifiez le CPU/NUMA/le comportement des interruptions.
Un lien propre avec une mauvaise latence p99 pointe souvent vers de la mise en file logicielle ou une surcharge CPU plutôt que PCIe.

Prochaines étapes que vous pouvez réellement exécuter

Si vous gérez des systèmes de production, la génération PCIe n’est pas une tendance. C’est une contrainte mesurable dans une topologie mesurable.
Faites ces actions suivantes :

1. Inventoriez la réalité des liens : exécutez lspci -vv pour vos 5 périphériques critiques (NICs, NVMe, GPU) et enregistrez LnkSta.
2. Créez une alerte pour les downtrains et les pics AER : les downtrains sont des avertissements précoces ; les erreurs corrigées sont la fumée avant le feu.
3. Cartographiez les domaines de contention : construisez un diagramme simple depuis lspci -t et la doc fournisseur des slots. Marquez ce qui partage un uplink ou un root port.
4. Décidez les upgrades par preuve de goulot : si vous ne pouvez pas montrer un plateau de lien correspondant à votre plafond théorique, n’achetez pas une nouvelle génération « juste parce que ».
5. Quand vous upgradez : mettez à niveau la plateforme comme un système — carte, risers, backplane/retimers, firmware — et validez sous chaleur et charge soutenue.

PCIe 3/4/5/6 ne concerne pas les droits à se vanter. Il s’agit de nourrir les périphériques pour lesquels vous avez déjà payé, sans créer une nouvelle classe de défaillance qui n’apparaît
qu’après la fin de la période de retour.