PCIe 3/4/5/6: qué cambia para usuarios reales

Qué cambia de PCIe 3 a 6 (y qué no)

El cambio principal entre generaciones PCIe es el ancho de banda por carril. La letra pequeña es lo difícil que se vuelve entregar ese ancho de banda de forma fiable en
una placa real, con longitudes de trazas reales, risers reales, backplanes reales y expectativas empresariales reales.

Qué cambia

• Rendimiento por carril: cada generación hasta PCIe 5 duplica aproximadamente la tasa de transferencia bruta (GT/s). PCIe 6 vuelve a duplicar, pero cambia el esquema de codificación y el modelo de tramas.
• Requisitos de integridad de señal: en PCIe 5 y especialmente en 6, “simplemente enrútalo” deja de funcionar. Aparecen retimers, mejores materiales y diseños más estrictos.
• Comportamiento de errores que verás en los logs: mayores velocidades implican menos margen; los enlaces marginales aparecen como errores corregidos antes de fallar por completo.
• Economía de carriles en la plataforma: más dispositivos compiten por los lanes finitos del CPU; los proveedores recurren a bifurcación, switches y cableados de ranuras ingeniosos.
• Térmicas y consumo: un NVMe Gen5 puede ser rápido y también excelente calentando el aire de tu datacenter. El rendimiento es opcional; la física no.

Qué no cambia (mucho)

• Expectativas de latencia: las generaciones PCIe no reducen mágicamente la latencia de IO al mismo ritmo que se duplica el ancho de banda. Muchas aplicaciones “lentas” están encolando, no limitadas por el enlace.
• “x16” sigue siendo “x16 carriles”, no una garantía: un slot físico x16 puede ser eléctricamente x8 o x4, o puede reducir el ancho en tiempo de ejecución.
• La topología importa más que el marketing: dos NVMe Gen4 x4 detrás de un solo uplink pueden pelearse como hermanos en el asiento trasero.

Mi regla operativa: no actualices la generación PCIe por “velocidad” a menos que puedas señalar un dispositivo y carga de trabajo específicos que ya estén alcanzando el límite del enlace.
De lo contrario estás comprando ancho de banda opcional y complejidad obligatoria.

Broma #1: el ancho de banda PCIe es como una sala de conferencias vacía: todo el mundo asume que está disponible hasta que empieza la reunión.

Cálculos de ancho de banda que puedes hacer en tu cabeza

Si no puedes estimar el ancho de banda PCIe en 10 segundos, tomarás malas decisiones de actualización y serás presa fácil de presentaciones con diapositivas.
Aquí está el modelo mental que sobrevive a las llamadas de guardia.

Términos clave (úsalos correctamente en reuniones)

• GT/s: gigatransfers por segundo. No es lo mismo que gigabits por segundo; la codificación importa.
• Sobrehead de codificación: PCIe 3–5 usan 128b/130b (≈1.54% de overhead). PCIe 1–2 usaron 8b/10b (20% de overhead). PCIe 6 usa un nuevo esquema con FLITs y FEC.
• Ancho de enlace: x1, x4, x8, x16 carriles. Ancho y velocidad se multiplican.
• Bidireccional: el ancho de banda PCIe es por dirección. No sumes ambas direcciones a menos que tu carga realmente use lectura y escritura simultáneamente.

Regla práctica de rendimiento por carril (una dirección)

Rendimiento efectivo aproximado (después de 128b/130b) por carril:

• PCIe 3.0: ~1 GB/s por carril → x4 ≈ 4 GB/s, x16 ≈ 16 GB/s
• PCIe 4.0: ~2 GB/s por carril → x4 ≈ 8 GB/s, x16 ≈ 32 GB/s
• PCIe 5.0: ~4 GB/s por carril → x4 ≈ 16 GB/s, x16 ≈ 64 GB/s
• PCIe 6.0: se mercadea como “otra duplicación”, pero el rendimiento utilizable real depende más de la implementación, FEC y patrones de carga que en generaciones anteriores.

Traducción práctica:

• Un SSD NVMe típico es x4. Si es Gen3 x4, alcanza en el mundo real ~3–3.5 GB/s. Gen4 x4 puede llegar a ~7 GB/s. Gen5 x4 puede alcanzar ~12–14 GB/s en lecturas secuenciales—si no se reduce por termal throttling.
• Una NIC de 100GbE es ~12.5 GB/s de tasa en línea antes de overheads. Eso significa que Gen3 x16 (≈16 GB/s) puede soportarla; Gen3 x8 (≈8 GB/s) no, salvo compromisos.

Si recuerdas una sola cosa: el ancho de banda es fácil; el ancho de banda compartido es donde las carreras profesionales van a morir.

Quién se beneficia realmente: NVMe, GPUs, NICs y tarjetas raras

Almacenamiento NVMe

NVMe es el consumidor más visible del “PCIe lo hace más rápido”. Pero el enlace es solo una puerta.
Las otras puertas: controlador flash, NAND, firmware, comportamiento de profundidad de cola, sistema de archivos, tiempo de CPU por IO y el patrón de IO de tu aplicación.

• Gen3 → Gen4: significativo para SSDs de gama alta y arreglos multi-drive que hacen lecturas/escrituras secuenciales o IO paralelo intenso.
• Gen4 → Gen5: relevante para menos cargas de trabajo de las que piensas. Brilla en transferencias secuenciales grandes, actividad tipo rebuild de RAID, checkpoints rápidos y algunas canalizaciones analíticas.
• IO aleatorio: a menudo limitado por latencia del dispositivo y overhead de CPU más que por ancho de banda del enlace. Si tu latencia p99 está dominada por pilas de software, Gen5 no te salvará.

GPUs y aceleradores

Para muchas cargas de GPU, PCIe no es la vía de datos principal una vez que los datos están en la tarjeta. Pero “una vez que los datos están en la tarjeta” implica mucho trabajo.
El entrenamiento puede ser menos sensible que las tuberías de inferencia que transmiten datos constantemente, y la comunicación multi-GPU puede usar NVLink/Infinity Fabric en lugar de PCIe.

• PCIe x8 vs x16: en mucho cómputo puede que no lo notes. En tuberías hambrientas de datos, sí lo notarás.
• Peer-to-peer: la topología PCIe determina si las GPUs pueden hacer P2P eficientemente. Un switch o un root complex equivocado puede arruinar la fiesta.

Redes (25/100/200/400GbE)

Redes es donde las ideas equivocadas sobre PCIe se vuelven caras. Una NIC no solo necesita ancho de banda de línea; necesita eficiencia DMA, moderación de interrupciones, localidad de CPU y suficiente margen PCIe para evitar que micro-bursts se conviertan en pérdidas.

• 100GbE: cómodo en Gen4 x8, límite en Gen3 x16 para sistemas ocupados, y mala idea en Gen3 x8 a menos que estés dispuesto a sacrificar rendimiento.
• 200/400GbE: básicamente estás planificando una topología PCIe, no “añadiendo una NIC”. Gen5 y una asignación cuidadosa de carriles se vuelven parte del diseño de red.

HBAs, tarjetas RAID, DPUs, tarjetas de captura, “ese FPGA”

Las tarjetas especializadas a menudo tienen restricciones extrañas: anchos de enlace fijos, requisitos estrictos de slot, grandes mapeos de BAR, bugs de firmware y una habilidad para fallar de maneras que parecen “problema de Linux”.
Con PCIe 5/6, las tarjetas también pueden requerir retimers para ser estables a plena velocidad.

Topología: carriles, root complexes, switches y por qué tu x16 slot miente

Las generaciones PCIe son límites de velocidad. La topología es la red de carreteras. La mayoría de los problemas de rendimiento del mundo real no son “el límite de velocidad es bajo” sino “enrutaste la autopista por un estacionamiento”.

Presupuesto de carriles: la única hoja de cálculo que deberías mantener

Los CPUs exponen un número finito de carriles PCIe. Esos carriles se dividen entre puertos raíz (root complexes). Las placas luego mapean ranuras físicas y dispositivos integrados a esos puertos.
Añade un segundo CPU y obtendrás más carriles—y además complejidad NUMA y tráfico entre sockets.

Consecuencias prácticas:

• Una ranura x16 puede compartir carriles con dos conectores M.2.
• Dos ranuras x16 pueden convertirse en x8/x8 cuando ambas están pobladas.
• Un 10/25/100GbE “onboard” puede estar consumiendo carriles valiosos que creías libres.
• Los backplanes frontales de unidades NVMe suelen usar switches PCIe para repartir carriles; esos switches pueden oversubscribir los uplinks.

Switches PCIe: útiles, no mágicos

Un switch PCIe es un dispositivo de fan-out: un enlace upstream, múltiples enlaces downstream. Permite muchas bahías NVMe sin dedicar x4 por unidad todo el camino al CPU.
Pero también introduce:

• Oversubscription: 16 unidades detrás de un switch con un uplink x16 significa que las unidades comparten ancho de banda. Puede estar bien, o puede ser el cuello de botella.
• Latencia adicional: usualmente pequeña, a veces perceptible para cargas ultra-bajas en latencia.
• Modos de falla: un switch o su firmware puede colgarse y llevarse todo un segmento con él.

Bifurcación: la función del BIOS que decide tu destino

La bifurcación divide un enlace más ancho en múltiples enlaces más estrechos (por ejemplo, x16 en 4×x4). Es como ejecutas tarjetas portadoras quad-NVMe sin un switch.
Pero la bifurcación requiere soporte de plataforma y ajustes correctos del BIOS.

Si enchufas una tarjeta 4×M.2 esperando cuatro unidades y solo ves una, eso no es Linux de mal humor. Es que no activaste la bifurcación.

Localidad NUMA: el asesino silencioso del rendimiento

En sistemas dual-socket, un dispositivo PCIe está conectado al root complex de un CPU. Si tu carga se ejecuta en el otro socket, cada DMA y cada interrupción puede cruzar el interconector.
Los síntomas parecen “PCIe es lento”, pero la solución es afinidad de CPU y colocación correcta del dispositivo, no una placa nueva.

PCIe 6.0: por qué no es “simplemente el doble de rápido”

PCIe 6.0 es donde la industria deja de fingir que la señalización a mayor frecuencia es un almuerzo gratis.
En lugar de solo subir GT/s, PCIe 6 cambia cómo se empaquetan los datos (modo FLIT) y añade corrección de errores hacia adelante (FEC).

Qué significa eso operativamente

• Más resiliencia al ruido, más complejidad: FEC ayuda a sostener mayores velocidades pero añade trabajo de codificación/decodificación y cambia la visibilidad de errores.
• Diferentes compensaciones de latencia: FEC y el framing FLIT pueden añadir una pequeña latencia, mientras permiten que el sistema en conjunto funcione más rápido. Si “sientes” PCIe 6 depende de la sensibilidad de la carga.
• La integridad de señal se vuelve más estricta: placas, risers, cables y backplanes deben diseñarse para ello. “Hace POST en Gen6” no es lo mismo que “funciona estable en Gen6 bajo carga por 18 meses”.

La mayoría de organizaciones deberían tratar PCIe 6 como una elección de plataforma que adoptas cuando tu ecosistema lo requiere (NICs de próxima generación, aceleradores, infraestructura componible),
no como una “actualización de almacenamiento” casual.

Hechos interesantes y breve historia (para fijar el modelo mental)

1. PCIe reemplazó a PCI/AGP al volverse serial: los carriles seriales de PCIe fueron un giro respecto a buses paralelos anchos que tenían problemas de clocking y desalineación de señal.
2. PCIe 1.0 y 2.0 usaron 8b/10b: “perdías” 20% del ancho de banda bruto por overhead de codificación. 128b/130b de PCIe 3.0 fue un gran salto práctico.
3. NVMe no solo “usó PCIe”: fue diseñado para reducir overhead de software y soportar colas profundas comparado con AHCI, que estaba pensado para discos giratorios.
4. M.2 es un factor de forma, no un protocolo: M.2 puede transportar SATA o PCIe/NVMe. Confundirlos es un error clásico de compras.
5. “x16 slot” se volvió un artefacto cultural de las GPUs: los servidores conservaron el estándar físico, pero el cableado eléctrico varía mucho entre proveedores y SKUs.
6. Los retimers se volvieron mainstream con Gen5: generaciones anteriores a menudo se apañaban con re-drivers o nada; Gen5 empuja los sistemas hacia el acondicionamiento activo de señal.
7. Los switches PCIe habilitaron en silencio la era del servidor NVMe: las bahías NVMe densas suelen ser una historia de diseño de switch, no de “muchos carriles”.
8. Resizable BAR pasó de niche a mainstream: mapeos de BAR más grandes mejoran patrones de acceso de CPU para algunos dispositivos; el soporte de plataforma maduró con el tiempo.
9. Los errores corregidos no son “inofensivos”: los sistemas empresariales monitorizan cada vez más las tasas de errores corregidos AER porque predicen inestabilidad futura a mayores velocidades.

Tres mini-historias corporativas desde el terreno

Mini-historia #1: el incidente causado por una suposición errónea

Una empresa mediana desplegó nuevos hosts de base de datos con “Gen4 en todas partes”. El objetivo era simple: más ancho de banda NVMe para consultas analíticas más rápidas.
Los hosts eran dual-socket, con U.2 NVMe en las bahías frontales y una NIC robusta para replicación.

La suposición errónea: cada unidad NVMe tenía un camino x4 dedicado al CPU. En realidad, el backplane frontal usaba un switch PCIe con un solo enlace upstream.
Bajo OLTP normal, nadie lo notó. Durante trabajos por lotes nocturnos, todo el clúster se convirtió en una trompeta triste: tiempos de consulta duplicados, lag de replicación aumentado
y los paneles de “utilización de disco” parecían arte moderno.

El ingeniero de guardia hizo el ritual habitual: culpó al sistema de archivos, al kernel, al proveedor de almacenamiento, a la fase de la luna.
Luego ejecutaron un par de pruebas dirigidas: una unidad sola alcanzó el rendimiento esperado; muchas unidades juntas se estancaron en un número sospechosamente redondo que coincidía con el uplink.
La meseta fue topología, no las unidades.

La solución fue aburrida: reequilibrar qué bahías se poblaban por dominio de switch, mover la NIC de replicación fuera del root complex compartido y aceptar que el servidor
estaba diseñado para densidad de capacidad, no para saturación total de ancho de banda. También actualizaron su checklist de compras interna para exigir un diagrama de topología PCIe publicado.
De pronto “Gen4 en todas partes” se convirtió en “Gen4 donde importa”, y los incidentes cesaron.

Mini-historia #2: la optimización que salió mal

Un equipo que ejecutaba inferencia con GPU quería exprimir latencia. Vieron que las GPUs negociaban en Gen4 y pensaron: “Forcemos Gen5 en el BIOS. Enlace más rápido, inferencia más rápida.”
La plataforma lo soportaba, las GPUs lo soportaban y el cambio tomó unos 30 segundos.

Durante un día todo parecía bien. Luego comenzaron fallos intermitentes: errores CUDA ocasionales, reinicios de driver y bloqueos raros de nodos bajo carga máxima.
Los logs tenían spam AER—errores corregidos al principio, luego algunos no corregidos. Reiniciar “arreglaba” temporalmente, lo cual sabe a que volverá durante la próxima festividad.

La causa real fue el margen de señal. Los nodos usaban risers largos y un chasis denso. A velocidades Gen5, el enlace operaba con menos holgura que una aerolínea económica.
FEC no estaba en juego (Gen5), y los errores corregidos fueron una advertencia temprana de que el canal físico era marginal.

El rollback fue inmediato: dejar las ranuras en Auto/Gen4, reducir las tasas de error a prácticamente cero y recuperar la estabilidad. La latencia neta mejoró de todos modos porque
el sistema dejó de reintentar y bloquearse. Más tarde desplegaron una plataforma Gen5 validada con retimers adecuados cuando realmente necesitaron el ancho de banda para ingest multi-GPU.

Mini-historia #3: la práctica aburrida pero correcta que salvó el día

Un equipo de almacenamiento empresarial tenía una política que parecía molesta y burocrática: antes de que cualquier host entrara en producción, capturaban un “paquete de verdad de hardware”.
Incluía topología PCIe, velocidades/ancho de enlace negociados, versiones de firmware y un perfil fio base en cada NVMe.

Meses después, un lote de servidores empezó a reportar timeouts NVMe esporádicos. No suficientes para fallar chequeos de salud. Justo los necesarios para arruinar la latencia p99 y enfurecer al equipo de bases de datos.
El proveedor insistió en que era un “problema de software” porque las unidades pasaban SMART.

El equipo de almacenamiento comparó el paquete de verdad actual con la línea base. Un detalle saltó: varias unidades ahora negociaban a menor ancho de enlace que antes.
No velocidad—ancho. x4 se había convertido en x2 en un subconjunto de bahías.

Eso apuntó directamente a un problema físico: asientos en el conector del backplane, un cable marginal o un retimer fallando. Abrieron el chasis,
volvieron a asentar la conexión del backplane y los enlaces volvieron a x4 con contadores de error limpios. Los timeouts desaparecieron.
No hubo depuración heroica. Solo evidencia y una línea base con la que compararla.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son comprobaciones probadas en campo. Cada una tiene: el comando, lo que deberías ver y la decisión que tomas.
Ejecútalas en hosts Linux donde sospeches un cuello de botella PCIe o un enlace mal negociado.

Task 1: Identify the device and its PCIe address

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]

Significado: Ahora tienes direcciones BDF (domain:bus:device.function) como 0000:01:00.0.
Decisión: Usa la BDF en comandos subsecuentes para inspeccionar ancho/velocidad del enlace y contadores de error para el dispositivo exacto que te importa.

Task 2: Check negotiated link speed and width (the thing everyone forgets)

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)

Significado: El dispositivo es capaz de Gen4 x4 (16GT/s x4) pero actualmente corre a velocidad Gen3-ish (8GT/s) y ancho x2.
Decisión: Trata esto como una mala configuración o un problema de integridad de señal, no como un “SSD lento.” Revisa cableado de slot, bifurcación, BIOS, risers y errores AER.

Task 3: Find the parent port and see if the bottleneck is upstream

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

Significado: Ves un árbol: root complex → bus → dispositivo. Esto te ayuda a entender qué comparte un enlace upstream.
Decisión: Si múltiples dispositivos pesados están detrás del mismo puerto upstream o switch, planifica la contención o mueve dispositivos a root complexes diferentes si es posible.

Task 4: Confirm NVMe link information via sysfs (fast and 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

Significado: Misma historia que lspci, pero más amigable para automatizar.
Decisión: Construye una comprobación de flota que alerte cuando dispositivos críticos negocien por debajo de la velocidad/ancho esperado.

Task 5: Check for PCIe AER errors in the kernel log

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

Significado: Errores corregidos significan que el enlace se está recuperando de problemas a nivel físico. A menudo esto se correlaciona con degradaciones, reintentos o inestabilidad bajo carga.
Decisión: Si los errores corregidos son frecuentes, deja de “optimizar” y empieza a estabilizar: vuelve a asentar, cambia risers, actualiza firmware o reduce la velocidad negociada (Auto/Gen4 en vez de forzar Gen5).

Task 6: Inspect PCIe capabilities and max payload settings

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

Significado: El dispositivo soporta payload 512B, pero está configurado a 256B. Esto puede importar para dispositivos de alto rendimiento (a menudo NICs).
Decisión: No ajustes esto al azar en producción. Si tienes un problema probado de throughput y guía del proveedor, alinea tamaños de payload a lo largo del camino. De lo contrario, déjalo como está.

Task 7: Confirm NVMe drive capabilities and current performance ceiling

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

Significado: Tienes la revisión de firmware e identificación del modelo para soporte del proveedor, y MDTS da pistas sobre tamaños máximos de transferencia.
Decisión: Si ves degradaciones de enlace, ahora tienes la identidad exacta del dispositivo para correlacionar con problemas conocidos de firmware o listas de compatibilidad de la plataforma.

Task 8: Measure real throughput with fio (and interpret it correctly)

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)

Significado: ~6.1 GiB/s sugiere que Gen4 x4 es plausible; Gen3 x4 normalmente se quedaría más abajo.
Decisión: Si el rendimiento está muy por debajo de lo esperado, correlaciona con ancho/velocidad del enlace. Si el enlace está bien, mira termal throttling, saturación de CPU, sistema de archivos o capa RAID.

Task 9: Check for NVMe thermal throttling signs

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

Significado: La unidad pasó tiempo significativo por encima de su temperatura de advertencia. Eso suele significar que se está reduciendo térmicamente durante benchmarks o trabajos por lotes.
Decisión: Mejora el flujo de aire, añade disipadores, reduce la densidad de unidades por chasis o acepta menor rendimiento sostenido. Actualizar a Gen5 sin refrigeración es autoboicot.

Task 10: Check NIC PCIe link and ensure it matches line-rate ambitions

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

Significado: Gen4 x8 es una buena base para 100GbE; para 200GbE serías más cauto dependiendo de overhead y patrones de tráfico.
Decisión: Si una NIC 100GbE muestra Gen3 x8, espera problemas bajo carga. Muévela a una ranura mejor o ajusta expectativas.

Task 11: Verify NUMA node locality for a PCIe device

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

Significado: La NIC está conectada al nodo NUMA 1. Si tus hilos de red corren en CPUs 0–31, estás pagando penalizaciones cross-socket.
Decisión: Fija IRQs y hilos de aplicación al nodo NUMA local para rutas de alto throughput o baja latencia.

Task 12: Inspect interrupt distribution (spot the “everything on CPU0” classic)

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

Significado: Las interrupciones están repartidas entre CPUs. Si ves un CPU haciendo todo el trabajo, el throughput cae y la latencia sube.
Decisión: Si hay desequilibrio, ajusta afinidad de IRQ (o habilita irqbalance con criterio) y alínea con la localidad NUMA.

Task 13: Check CPU frequency throttling that masquerades as “PCIe bottleneck”

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

Significado: Si Avg_MHz está muy por debajo de lo esperado bajo carga, límites de energía o throttling térmico pueden capar el procesamiento de IO.
Decisión: No compres carriles PCIe 5 para arreglar un CPU que corre a mitad de velocidad. Arregla refrigeración, límites de energía y perfiles BIOS primero.

Task 14: Verify negotiated speed on the root port too (catch upstream downgrades)

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

Significado: Incluso si el endpoint se ve bien, un puerto upstream puede estar corriendo a menor velocidad, limitando todo lo que hay debajo.
Decisión: Busca ajustes del BIOS que forcen una generación, problemas de firmware o integridad de señal que afecten a todo ese segmento.

Broma #2: Forzar Gen5 en el BIOS es como conducir más rápido en la niebla porque el velocímetro marca más.

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando el rendimiento es malo, necesitas una secuencia implacable que te lleve al factor limitante rápidamente.
Aquí está la versión para on-call.

Primero: verifica que el enlace sea lo que crees

• Comprueba LnkSta speed/width para el dispositivo sospechoso y su puerto upstream (lspci -vv).
• Comprueba sysfs current_link_speed/current_link_width para obtener la verdad scriptable.
• Decisión: Si hay degradación, para. Arregla topología/físico/BIOS antes de benchmarkear cualquier otra cosa.

Segundo: busca inestabilidad de capa física y reintentos

• Escanea dmesg en busca de errores AER corregidos; correlaciónalos con periodos de carga.
• Decisión: El spam de errores corregidos no es “aceptable.” Es el sistema quemando margen. Reduce la velocidad (Auto), vuelve a asentar, intercambia risers, actualiza firmware.

Tercero: aísla si el límite es el dispositivo o la plataforma

• Benchmark de un solo dispositivo (fio en un NVMe; iperf o prueba de tráfico en una NIC; pruebas memcpy GPU para host->device).
• Benchmark a escala (muchos NVMe concurrentes, múltiples colas NIC, múltiples GPUs) y busca una meseta.
• Decisión: Una meseta en un número redondo que coincide con un uplink o ancho de root port grita “cuello de botella compartido” (switch, uplink o root port).

Cuarto (si hace falta): revisa NUMA y overhead de CPU

• Nodo NUMA del dispositivo y distribución de interrupciones.
• Frecuencia/potencia de CPU bajo carga.
• Decisión: Si hay tráfico cross-socket o throttling de CPU, arregla afinidad y energía de plataforma antes de culpar a la generación PCIe.

Una cita para mantenerte honesto: La esperanza no es una estrategia. La parte útil es el mensaje: mide y luego decide.

Errores comunes: síntomas → causa raíz → solución

1) “Mi SSD Gen4 rinde como Gen3”

Síntomas: lecturas secuenciales se estancan alrededor de ~3 GB/s; fio nunca lo supera; la unidad corre fría y sana.

Causa raíz: el dispositivo negoció en Gen3 o ancho reducido (x2) debido a cableado de slot, bifurcación, riser o BIOS forzando compatibilidad.

Solución: revisa LnkSta; mueve la unidad/tarjeta a una ranura conocida buena; habilita bifurcación; pon PCIe speed en Auto; actualiza BIOS y firmware del backplane.

2) “Va rápido solo pero lento con muchas unidades”

Síntomas: una NVMe alcanza el rendimiento esperado; 8+ unidades juntas alcanzan un techo duro; la latencia sube con la concurrencia.

Causa raíz: oversubscription del switch PCIe o ancho de uplink/root port compartido.

Solución: mapea unidades a dominios de switch; distribuye carga; usa más uplinks (depende de la plataforma); acepta la oversubscription y ajusta la programación de la carga.

3) “Después de una actualización de firmware, obtenemos errores PCIe raros”

Síntomas: nuevos errores AER corregidos; resets ocasionales de dispositivo; downtrains del enlace.

Causa raíz: cambiaron parámetros de equalización o nueva velocidad Gen por defecto; ahora se expone un canal marginal.

Solución: revertir/avanzar firmware según guía del proveedor; poner Auto en vez de forzar velocidad; revisar compatibilidad de retimer/backplane.

4) “100GbE no alcanza tasa de línea”

Síntomas: throughput se topa ~60–80Gbps; uso de CPU alto; pérdidas o pausas bajo carga.

Causa raíz: la NIC está en una ranura Gen3 x8; interrupciones no repartidas; mismatch NUMA; payload demasiado pequeño o ajustes subóptimos.

Solución: pon la NIC en Gen4 x8 o Gen3 x16; alinea NUMA; verifica interrupciones; solo ajusta payload si sabes por qué y puedes probar de forma segura.

5) “El entrenamiento GPU va bien, la inferencia es errática”

Síntomas: la utilización de cómputo cae; las transferencias host->device dominan; p99 de latencia sube.

Causa raíz: ancho de enlace PCIe reducido (x8), root complex compartido con NVMe o DMA cross-socket.

Solución: valida ancho/velocidad de GPU; mueve dispositivos a root complexes distintos; fija hilos de CPU al NUMA local; evita contención de almacenamiento pesada en el mismo segmento.

6) “Todo parece bien, pero la latencia p99 IO es mala”

Síntomas: tests de ancho de banda se ven bien; aun así la p99 de la aplicación es alta; la CPU está ocupada en softirq o rutas del sistema de archivos.

Causa raíz: overhead de software, encolamiento o contención; no la generación PCIe.

Solución: perfila (off-CPU time, planificador de IO, sistema de archivos); reduce contención; usa io_uring donde convenga; escala CPU y ajusta afinidad.

Listas de verificación / plan paso a paso

Checklist A: antes de comprar hardware (deja de pagar por carriles de fantasía)

1. Lista dispositivos por necesidades de ancho de banda: conteo NVMe, velocidad NIC, cantidad de GPUs, cualquier HBA/DPU.
2. Calcula carriles requeridos por dispositivo (usualmente x4 por NVMe, x8/x16 por NIC/GPU según clase).
3. Pide el diagrama de topología PCIe de la plataforma exacta + chasis + opción de backplane.
4. Identifica dónde existen switches y cuáles son los anchos de uplink.
5. Confirma soporte de bifurcación para cualquier tarjeta portadora.
6. Confirma presencia/requisitos de retimers para Gen5+ en tus risers/backplanes previstos.
7. Decide si prefieres: menos dispositivos a ancho completo, o más dispositivos con oversubscription.

Checklist B: puesta en marcha de un servidor (haz del “paquete de verdad” un hábito)

1. Captura lspci -nn y lspci -t outputs.
2. Para cada dispositivo crítico: registra LnkCap y LnkSta y el estado del puerto root upstream.
3. Registra versiones de firmware: BIOS, BMC, NIC, NVMe.
4. Ejecuta fio de un solo dispositivo y una pequeña prueba de estrés multi-dispositivo (dentro de límites seguros).
5. Revisa dmesg por errores AER durante estrés.
6. Guarda este paquete en tu CMDB o ticket. El tú futuro te agradecerá.

Checklist C: al actualizar la generación PCIe (el plan “no romper prod”)

1. Comprueba que el sistema actual esté limitado por el enlace (meseta + estado de enlace correcto) antes de gastar dinero.
2. Actualiza componentes de plataforma como un conjunto: placa + risers + backplane/retimers + firmware. Mezclar expectativas Gen5 con mecánica de era Gen4 es un hobby, no una estrategia.
3. Valida estabilidad bajo carga y temperatura de peor caso. No un benchmark de 30 segundos.
4. Monitorea tasas de errores AER corregidos y downtrains del enlace como señales SLO de primera clase.
5. Si debes forzar una generación, hazlo solo después de validación—y documenta el procedimiento de rollback.

Preguntas frecuentes

1) ¿Necesito PCIe 5.0 para NVMe?

Solo si tu carga puede usar ese ancho de banda. Muchas bases de datos y servicios están limitados por latencia o CPU. Si haces IO secuencial grande o ingest paralelo intenso, Gen5 puede ayudar.
De lo contrario Gen4 suele ser el punto óptimo en coste, térmicas y cordura.

2) ¿Por qué mi dispositivo dice “downgraded” en LnkSta?

Porque la negociación se resolvió en menor velocidad/ancho debido a límites de plataforma, ajustes del BIOS, calidad de cableado/riser o problemas de integridad de señal.
Trátalo como un problema de configuración/físico hasta que se demuestre lo contrario.

3) ¿El ancho de banda PCIe es por dirección o total?

Por dirección. Los enlaces PCIe son full-duplex. No dupliques números a menos que tu carga lea y escriba a altas tasas simultáneamente.

4) ¿PCIe 6.0 reduce la latencia?

No automáticamente. PCIe 6 se centra en habilitar mayor throughput con modo FLIT y FEC. La latencia puede mejorar en algunos casos por menos cuellos de botella,
pero también puede permanecer igual o verse ligeramente afectada por la framificación y corrección de errores.

5) ¿Un switch PCIe es malo para almacenamiento?

No. Es la forma de construir sistemas NVMe densos. El riesgo es la oversubscription y el cuello de botella de uplink compartido. Si entiendes el ancho de uplink y la concurrencia de tu carga,
un switch es perfectamente razonable.

6) Mi GPU corre a x8. ¿Debo entrar en pánico?

No por defecto. Muchas cargas mayormente de cómputo no saturan PCIe. Pero si transmites datos constantemente, haces transferencias frecuentes host-device o dependes de rutas P2P,
x8 puede perjudicar. Mide tu pipeline antes de rediseñar el chasis.

7) ¿Cuál es la razón más común por la que NVMe es lento en un servidor nuevo?

Mala negociación de enlace (downtrain de Gen o reducción de ancho) o oversubscription de topología. Después de eso: throttling térmico, mismatch NUMA y límites de energía de CPU.

8) ¿Debería forzar la velocidad PCIe en el BIOS?

Evítalo a menos que tengas una razón validada. Los ajustes forzados de generación son geniales para reproducir en laboratorio y terribles como “tweak de rendimiento” en canales marginales.
Usa Auto y arregla los problemas de estabilidad subyacentes.

9) ¿Cómo sé si estoy limitado por PCIe vs por software?

Si LnkSta es correcto y aún no alcanzas el throughput esperado, compara escalado single-device vs multi-device y revisa CPU/NUMA/comportamiento de interrupciones.
Un enlace limpio con mala latencia p99 suele señalar encolamiento de software o overhead de CPU en lugar de PCIe.

Siguientes pasos que puedes ejecutar

Si manejas sistemas en producción, la generación PCIe no es una vibra. Es una restricción medible en una topología medible.
Haz esto a continuación:

1. Inventario de la realidad de enlaces: ejecuta lspci -vv para tus 5 dispositivos críticos (NICs, NVMe, GPUs) y registra LnkSta.
2. Construye una alerta para downtrains y picos de AER: los downtrains son advertencias tempranas; los errores corregidos son humo antes del fuego.
3. Mapea dominios de contención: construye un diagrama simple desde lspci -t y docs del proveedor de slots. Marca qué comparte uplink o root port.
4. Decide actualizaciones con prueba de cuello de botella: si no puedes mostrar una meseta de enlace que coincida con tu techo teórico, no compres una nueva generación “porque sí”.
5. Cuando actualices: actualiza la plataforma como sistema—placa, risers, backplane/retimers, firmware—y valida bajo calor y carga sostenida.

PCIe 3/4/5/6 no es para lucirse. Es para alimentar los dispositivos por los que ya pagaste, sin crear una nueva clase de falla que solo aparece
después de que caduque la ventana de devolución.