Medí la latencia y el rendimiento de una Ethernet entre dos computadoras de placa única Raspberry Pi Modelo B con la herramienta de referencia NetPIPE . El benchmark prueba una variedad de tamaños de mensajes entre dos procesos. Se ejecutó una vez usando solo TCP como protocolo de extremo a extremo y una vez usando la biblioteca de capas de paso de mensajes de Open MPI.
La conexión no es un enlace directo. Un conmutador de capa 2 no administrado (Ethernet de 10/100 Mbps) se encuentra entre ambos dispositivos.
MTU=1500 bytes.
Las cifras muestran que usar MPI (que también usa TCP como protocolo de capa de transporte) es una sobrecarga que tiene un impacto negativo en el rendimiento y la latencia. El mejor rendimiento medido cuando se utiliza MPI es de 65 Mbit/s. Cuando se usa solo TCP, el rendimiento alcanza hasta 85 Mbit/s.
Siempre que la carga útil se ajuste a un solo segmento TCP, la latencia cuando se usa MPI es aproximadamente diez veces peor que cuando se usa solo TCP. La unidad de transmisión máxima (MTU), que especifica la carga útil máxima dentro de una trama Ethernet, es de 1500 bytes en nuestro clúster. En consecuencia, el tamaño máximo de segmento (MSS), que especifica la carga útil máxima dentro de un segmento TCP, es de 1460 bytes.
Algunas preguntas:
¿Por qué los gráficos MPI tienen más valores atípicos en comparación con el gráfico TCP? Esto se puede ver claramente en la figura inferior izquierda. ¿Es esto debido a la programación de procesos del sistema operativo? La pila TCP es parte del kernel de Linux y, por lo tanto, se ejecuta en el espacio del kernel. La biblioteca MPI se ejecuta en el espacio del usuario.
¿Por qué la latencia es una constante de tiempo más larga cuando se usa MPI en comparación con TCP? Se puede ver claramente en la figura superior derecha.
¿Hay más explicaciones para los resultados que perdí?
Por cierto: el bajo rendimiento general de Ethernet probablemente se deba a que el controlador Ethernet de 10/100 Mbit de la Raspberry Pi está conectado internamente al concentrador USB 2.0.
Actualizar
Las caídas de rendimiento, especialmente alrededor de 4 MB de tamaño de carga útil, probablemente se deban a los recursos limitados de la CPU de los nodos Raspberry Pi. Verifiqué la utilización de la CPU con htop y cuando ejecuté el punto de referencia MPI, se utilizó casi por completo.
la caída del rendimiento de alrededor de 512 KiB se debe al protocolo MPI:
Consulte: https://computing.llnl.gov/tutorials/mpi_performance/#EagerVsRendezvous El punto predeterminado cuando cambia la configuración depende de la implementación de MPI elegida. También hay variables de configuración para cambiarlo y, en su caso, debería cambiar más tarde de ávido a rendevouz. La latencia adicional hace que el rendimiento vuelva a mejorar lentamente hasta un tamaño de transferencia de 1 MiB. La caída de rendimiento posterior no está clara para mí.