No creo que el arbitraje sea el problema aquí, y ajustar su configuración requiere el soporte de la placa, así como la modificación del kernel. La interfaz de capacidad extendida de vc se maneja en parte en el kernel de Linux aquí:http://lxr.free-electrons.com/source/drivers/pci/vc.c
He escrito controladores para placas PCIe personalizadas en Linux, y el algoritmo para enrutar el tráfico entre placas no ha demostrado ser un problema en el pasado, a menos que tenga un caso de uso muy inusual:transferencias extremadamente largas con requisitos de latencia casi en tiempo real. (en cuyo caso no debería usar PCIe).
Lo que puede tener un impacto directo en este tipo de rendimiento, y se aborda mucho más fácilmente, es la topología del bus en sí, aunque el impacto suele ser apenas medible.
En la máquina, ejecute el comando lspci como:
lspci -tv
Lo que le mostrará una vista de árbol de las interfaces PCIe y la ruta a la(s) CPU(s) que toman. Con la mayoría de los procesadores, tendrá algunas ranuras que van directamente a la CPU y otras que pasan por un chip puente (consulte el conjunto de chips Intel x99
Estos puentes introducen latencia y la posibilidad de un rendimiento más lento. La CPU directa está configurada específicamente para dispositivos de alto rendimiento como tarjetas de video. Para su punto inicial, en lo profundo del microcódigo del procesador puede haber optimizaciones que degradan aún más los enlaces puenteados. Para profundizar en la evaluación del rendimiento y el enrutamiento de las ranuras PCIe, continúe en sysfs.
En /sys/bus/pci/slots/ habrá una lista de las ranuras pci (físicas) en su sistema. En él hay un archivo virtual que asocia la dirección del bus <----> ranura física.
En /sys/bus/pci/devices hay una lista de todos los dispositivos (aquí es donde lspci obtiene su información).
Al revisar cada uno de los dispositivos, puede ver toda la información expuesta por el kernel en ellos, los controladores asociados con ellos, la CPU asociada con el dispositivo (en un sistema de CPU múltiple), entre otras cosas.
Editar:no mencioné algunas cosas obvias que supongo que has descartado, pero por si acaso:
1. ¿Las diferentes máquinas tragamonedas tienen al menos tantos carriles como los tableros?
2. ¿Hay alguna discrepancia en las especificaciones, por ejemplo, la placa es pcie 3, una ranura es 3 y la otra 2?
3. ¿Ha discutido esta inquietud con el proveedor de la placa y/o el desarrollador del controlador más allá de ellos reconociendo iy? Es posible que estén al tanto de algunas erratas aleatorias al respecto.
Si proporciona detalles específicos, puedo brindarle consejos específicos.
Más allá de mirar la topología (es el dispositivo más rápido en una ruta de CPU directa, mientras que el otro no lo es), sin saber el tipo de chipset/CPU que está usando, solo puedo ofrecer consejos generales, pero tres áreas que comenzaría a buscar en son:
Latencia de interrupción:si la interrupción para la placa está asociada con una CPU/núcleo que está manejando otros dispositivos con una alta tasa de interrupción, sufrirá un impacto en el rendimiento. ¿Hay otro trabajo pesado del contexto del kernel en ese núcleo? mire /proc/interrupts para ver qué otros módulos del kernel están usando esa CPU para su manejo de interrupciones y el conteo/velocidad a la que ocurren. Intente ajustar la afinidad de la CPU para ese dispositivo en /proc/irw ... smp_affinity. La afinidad de smp es una máscara, si tuviera 8 núcleos y no especificara nada, se establecería en FF (8 1). Si lo configura, p. 0x02, eso obligará a Core 2 a manejar la IRQ. A menos que sepa que está abordando un problema específico, forzar estos cambios puede empeorar las cosas fácilmente.
Compatibilidad con interrupciones:eche un vistazo y vea si uno de los dispositivos está usando interrupciones MSI-x o MSI, mientras que el otro está usando una interrupción (eléctrica) estándar. A veces, los puentes no son compatibles con la implementación de MSI de las placas (MSI significa interrupción señalada por mensaje, en lugar de una interrupción eléctrica, es solo un paquete que se envía a través del bus). Si un dispositivo normalmente usa varias interrupciones pero tiene que operar con una sola debido a esto, puede ser difícil de detectar a menos que lo esté buscando directamente y puede causar problemas de rendimiento.
Caracterizar el desempeño. Hay muchas herramientas en el núcleo para recopilar datos de rendimiento. Lo único que todos tienen en común es que están mal documentados y, por lo general, no cuentan con respaldo. Pero dicho esto, consideraría usar Ftrace para caracterizar las transferencias de dma de cada placa y la latencia de IRQ para cada una. Puede obtener información estadística, así como detalles específicos sobre eventos atípicos. Puede comenzar a investigar eso aquí:http://elinux.org/Ftrace
En general, desaconsejo encarecidamente perder el tiempo en configuraciones de muy bajo nivel sin una comprensión tan completa como sea posible de lo que está tratando de corregir (no los síntomas a corregir, sino la causa raíz subyacente). El 99% de las veces terminará girando 'perillas' porque sí, pero sin comprender por qué o cuál es el problema original, cómo puede evaluar la efectividad de una configuración determinada (tanto inmediata como en términos de estabilidad a largo plazo) .
Utilizo mucho ftrace para la depuración general del kernel y lo recomiendo encarecidamente. Si desea que las cosas se abstraigan un poco, hay envolturas alrededor de ftrace que afirman que lo hacen más fácil de usar, pero descubrí que la abstracción adicional solo enturbia el agua:trace-cmd, kernel shark, etc. Si está en un sistema red hat puede buscar en systemtap:no es lo mismo, pero puede proporcionar datos similares (y está bien respaldado).