Tasa de pérdida de paquetes con iperf y tcpdump

Probé una línea por su calidad de enlace con iperf. La velocidad medida (puerto UDP 9005) fue de 96 Mbps, lo cual está bien, porque ambos servidores están conectados a 100 Mbps a Internet. Por otro lado, se demostró que la tasa de pérdida del datagrama era de 3.3-3.7%, lo que encontré demasiado. Utilizando un protocolo de transferencia de alta velocidad, grabé los paquetes en ambos lados tcpdump. De lo que calculé la pérdida de paquetes - promedio 0.25%. ¿Alguien tiene una explicación, de dónde puede venir esta gran diferencia? ¿Qué es una pérdida de paquetes aceptable en su opinión?

He experimentado una gran cantidad de daños con iPerf en modo UDP como resultado de que la CPU no puede mantenerse al día. Por alguna razón, iPerf con UDP parece ser mucho más intensivo en CPU que iPerf con TCP. ¿Experimenta los mismos porcentajes de pérdida cuando configura iPerf a la mitad de la tasa?

Para responder a su segunda pregunta sobre cuánta pérdida de paquetes es aceptable, realmente depende de qué aplicación esté ejecutando, cuánto tráfico tenga. Realmente, no debería haber ninguna pérdida si está por debajo de su límite de ancho de banda. Para la mayoría de las cosas, probablemente no me quejaría demasiado acerca de .25%, pero eso sigue siendo una gran pérdida si se está ejecutando a tasas realmente altas.

[EDITAR 1] Algunas otras ideas que he tenido sobre el tema:

1. Intente incrementar las tasas de iPerf. Si hay un problema sistémico en algún lugar, es probable que experimente el mismo porcentaje de pérdida sin importar la tasa. Si se encuentra en los límites de su hardware, o su proveedor hace algún tipo de RED , entonces es probable que no haya pérdidas hasta una cierta tasa, y luego una pérdida incrementalmente peor cuanto mayor sea su nivel.
2. Realice la medición de tcpdump de la sesión de iPerf, solo para verificar que sus pruebas sean precisas.
3. Prueba iPerf con TCP. Esto no informará pérdida, pero si está teniendo pérdida, entonces la conexión no podrá escalar muy alto. Dado que la latencia también afectará esto, asegúrese de probar hasta un punto final con la menor latencia posible.
4. Dependiendo de qué equipo tenga en el interior de su conexión, asegúrese de estar lo más cerca posible. Por ejemplo, si tiene varios interruptores entre su sistema de prueba y el enrutador de borde, muévase a un interruptor conectado directamente.
5. Si tiene un interruptor administrado, verifique las estadísticas en él para asegurarse de que la pérdida no ocurra allí. Me he encontrado con algunos conmutadores más baratos que comienzan a caerse cuando te acercas a 100Mbps de tráfico UDP (principalmente conmutadores no administrados viejos y baratos).
6. Pruebe iPerfs simultáneos de dos clientes diferentes a dos hosts diferentes, de modo que pueda estar seguro de que el límite no es el resultado de una CPU o una tarjeta NIC local barata.

Bueno, con TCP hay mecanismos para maximizar la utilización de un flujo, con UDP no. Por lo tanto, cada aplicación tiene que crear sus propios mecanismos, por lo que probablemente cada aplicación utilice un enfoque diferente para hacerlo. Probablemente, Iperf permitirá que se pierdan más paquetes porque está tratando de alcanzar el ancho de banda máximo disponible sin importar si la información se recibe o no. La otra aplicación probablemente intentará no perder muchos paquetes y reducirá la tasa de paquetes al rendimiento disponible en la conexión.

¿Ha utilizado tcpdump para verificar la pérdida de paquetes al usar iPerf para asegurarse de que la pérdida de paquetes que calcula con tcpdump coincide con iperf?

Puede descubrir que sus métodos de medición no son comparables.

¿iperf descarta automáticamente los paquetes que llegan fuera de secuencia con UDP? Es posible que esté viendo un poco de inquietud en la conexión.