Malla MCX516A-CCAT sobre DAC de 100G: lshw dice 40Gbit/s y un solo flujo de iperf3 tope a 21 Gbit/s
Corremos un clúster de tres nodos con los nodos cableados directamente entre sí sobre DAC de 100G, sin switch en la ruta, y las interfaces puestas en un bond broadcast para que el tráfico de replicación tenga su propio fabric. Antes de meterle carga real quería una línea base, y los números no coinciden entre sí.
- 3x Mellanox ConnectX-5 EN, MCX516A-CCAT, doble puerto QSFP28
- un DAC de 100G entre cada par de nodos
- hosts AMD EPYC, Proxmox en los tres
ethtool está perfectamente contento:
# ethtool ens1
Settings for ens1:
Supported link modes: 100000baseCR4/Full
Advertised link modes: 100000baseCR4/Full
Speed: 100000Mb/s
Duplex: Full
Link detected: yeslshw no lo está:
# lshw -class network
*-network
description: Ethernet interface
vendor: Mellanox Technologies
capacity: 40Gbit/sY iperf3 entre dos de los nodos se queda en aproximadamente 21 Gbit/s, que no se acerca a ninguna de las dos cifras.
Ya hecho:
- moví el cable al segundo puerto en ambas tarjetas, sin cambio
- probé con otro DAC del mismo tipo, sin cambio
- el enlace se mantiene arriba todo el tiempo, sin errores subiendo en los contadores
Así que ¿cuál de las dos herramientas me está mintiendo, y debería ir tras el cable, la tarjeta o el driver?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Nada de lo que publicaste apunta al DAC. Hay dos cosas no relacionadas ocurriendo aquí.
Primero, la discrepancia.
lshw -class networkimprime una cifra de capacidad que calcula por su cuenta, y en estas tarjetas dirá alegrementecapacity: 40Gbit/ssobre un enlace que subió a 100G. La tasa negociada es lo que reportaethtool, y la tuya diceSpeed: 100000Mb/scon100000baseCR4/Fullanunciado. Ese lado está bien, no hay nada que arreglar.Segundo, el rendimiento. Revisa el slot antes de tocar cualquier otra cosa:
Si
LnkStaentrenó a 2.5GT/s mientrasLnkCapdice 8GT/s, estás limitado muy por debajo del cable y ningún cambio de cable va a ayudar. Reasienta la tarjeta y asegúrate de que esté en un slot realmente cableado para el ancho completo.Luego deja de medir con un solo flujo:
Alrededor de 21 Gbit/s es más o menos lo que un solo núcleo te va a dar en esta clase de host, así que esa cifra por sí sola te dice muy poco. Observa la CPU durante la corrida y mira también qué están haciendo los estados de inactividad: núcleos cayendo en C-states profundos entre ráfagas te cuestan ancho de banda real a esta tasa.
Antes de pedir reemplazo de nada, publica la línea
LnkStadelspci -vvpara esa tarjeta y la línea de comando exacta de iperf3 que usaste. Un flujo a 100G mide un solo núcleo de CPU, no el enlace, y la gente se quema días con esto. Y confirma que el segundo puerto realmente esté llevando la otra pata de la malla mientras pruebas, y no esté inactivo: un solo slot alimentando dos puertos de 100G activos es un presupuesto distinto de uno solo. Yo dejaríalshwa un lado por ahora, no es la herramienta para esta pregunta.Una corrección sobre la parte de los C-states: si los hosts son EPYC, los ajustes de
intel_idleque se pegan en cada uno de estos hilos no te hacen nada, ese driver no está en la ruta en AMD para nada. La palanca que me funcionó fueprocessor.max_cstate=2en la línea de comandos del kernel. Misma idea, plataforma distinta. El resto de esa publicación se mantiene, en particular no leer una tasa negociada delshw.Fallo ligeramente distinto, misma familia de hardware, vale la pena descartarlo una vez resuelto el slot: una malla directa de puertos ConnectX-5 QSFP28 es muy fácil de equivocar en la capa 3. Tenía tres nodos en MCX516A-CCA_Ax, firmware 16.35.4030 con el driver DOCA 2.8.0, cableados con DAC de cobre MCP1600-C003E30L de 3 m. Todos los enlaces reportaban activo a 100 Gbps y ni un solo ping cruzaba. Las seis interfaces de la malla tenían direcciones de una sola subred 10.5.5.x sin ningún switch en la ruta, así que el kernel no tenía forma de decidir a qué puerto físico pertenecía un destino dado. Una subred por par de nodos, 10.5.5.x, 10.5.6.x y 10.5.7.x, y empezó a funcionar. Vale la pena correr
ip aeip routeen los tres equipos antes de que alguien culpe al cobre.Ambos puntos dieron en el blanco.
lspci -vvmostró la tarjeta entrenada a 2.5GT/s contra unLnkCapde 8GT/s, así que ese fue el sospechoso número uno. Moví las tarjetas a otros slots en los tres equipos,LnkStaahora sube a 8GT/s, y coniperf3 -P 8el mismo par de nodos de inmediato superó la cifra de un solo flujo.También abandoné el bond broadcast y reconstruí la malla en Open vSwitch con RSTP. Con iperf repartido en tres hilos de CPU y ambos puertos estoy midiendo unos 95 Gbit/s ahora, que se acerca lo suficiente a la tasa de línea para lo que hace este clúster.
lshwsigue insistiendo en 40Gbit/s y he dejado de mirarlo.