Iperf: Falta ancho de banda del receptor de salida JSON para UDP

Derecha. Este es un error muy antiguo, uno que podría haber estado presente en iperf3 desde el principio. De alguna manera me di cuenta (¿por qué no presenté un problema?) Cuando estaba trabajando en el # 562. Como señaló correctamente, las pruebas UDP no desglosan las estadísticas del lado del cliente y del lado del receptor por separado. No estoy seguro de si lo que se informa es el cliente, el remitente o una mezcla de los dos. Tampoco me queda claro por qué TCP es diferente.

Sería bueno si las pruebas UDP pudieran emitir una salida de estadísticas más parecida a TCP en este sentido (tanto del lado del remitente como del receptor por separado), aunque no estoy seguro de cómo mantener algún tipo de compatibilidad con programas que consumen el JSON existente. producción. (En el n. ° 562, arreglé la salida legible por humanos para UDP, que presentó en su primer fragmento de salida ... Estaba menos preocupado por la compatibilidad con versiones anteriores en ese caso porque los programas no deberían intentar leer esa salida de todos modos).

¿Se ha resuelto este problema para la salida UDP JSON? Estamos tratando de analizar la salida JSON, pero no estamos seguros de qué es qué. Un ejemplo de salida JSON es: -

    }],
            "sum":  {
                    "start":        0,
                    "end":  10.004644870758057,
                    "seconds":      10.004644870758057,
                    **"bytes":        4364528380,**
                    "bits_per_second":      3484585580.8672519,
                    "jitter_ms":    2.3222640079292773,
                    "lost_packets": 2102766,
                    "packets":      2989403,
                    "lost_percent": 70.34066668160834
            },

pero no estamos seguros de qué es esto de los bytes, ¿son los bytes enviados o los bytes recibidos?

¿Cuándo se arreglará? Necesito obtener los bps del receptor de la salida JSON.

¿Quizás hay alguna solución?

No está en la hoja de ruta en este momento. Arreglar esto en realidad requiere un cambio en la máquina de estado y el protocolo entre el cliente y el servidor.

¿Puedo preguntar ... Si estoy probando con UDP y analizo el json desde el lado del cliente y obtengo

end.sum.bits_per_second     AND 
end.sum.lost_packets

¿Tendré una representación justa de si la transmisión está enviando y recibiendo datos desde el lado del servidor? ¿Qué tendría que hacer para verificar que ambas direcciones de envío / recepción fueron exitosas? Analizar la salida de texto de:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec  0.000 ms  0/81 (0%)  sender
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec  0.052 ms  0/81 (0%)  receiver

@awardblvr : Depende, supongo, de cómo se defina "exitoso". Supongo que una medida podría ser que si end.sum.lost_packets es cero, entonces el receptor no detectó ningún paquete perdido. Sin embargo, existen algunos casos extremos en torno a esto, principalmente relacionados con lo que sucede con los paquetes que todavía están en vuelo cuando el cliente declara que la prueba se completó.

Gracias ..., solo quiero saber que puedo leer esta salida de ONE json y ver
BÁSICAMENTE que los paquetes transferidos desde el servidor -> cliente y los paquetes
transmitido desde el cliente -> servidor llegó y que no hubo pérdida
paquetes en cualquiera de los paquetes recibidos por el cliente:

Creo que es:

end.sum.packets.
end.sum.lost_packets
end.sum_receiver.packets <--- NUEVO con PATCH
end.sum_receiver.lost_packets <--- NUEVO con PATCH

¡Por favor, corríjame si estoy equivocado!

"final": {
"suma": {
"fin": 10.00,
"segundos": 10,00,
"bits_por_segundo": 1058280.26,
"bytes": 1322892,
"paquetes": 81,
"inicio": 0,
"jitter_ms": 0.056,
"paquetes_perdidos": 0,
"porcentaje_perdido": 0
},
"streams": [
{
"udp": {
"fin": 10.00,
"enchufe": 5,
"segundos": 10,00,
"bits_por_segundo": 1058280.26,
"bytes": 1322892,
"paquetes": 81,
"out_of_order": 0,
"inicio": 0,
"jitter_ms": 0.056,
"paquetes_perdidos": 0,
"porcentaje_perdido": 0
}
}
],
"sum_sender": {<--- NUEVO con PARCHE
"fin": 10.00,
"segundos": 10,00,
"bits_por_segundo": 1058280.26,
"bytes": 1322892,
"paquetes": 81,
"inicio": 0,
"jitter_ms": 0,
"paquetes_perdidos": 0,
"porcentaje_perdido": 0
},
"sum_receiver": {<--- NUEVO con PATCH
"fin": 10.00,
"segundos": 10,00,
"bits_por_segundo": 1058271.16,
"bytes": 1322892,
"paquetes": 81,
"inicio": 0,
"jitter_ms": 0.0568,
"paquetes_perdidos": 0,
"porcentaje_perdido": 0
}

Gracias

-A

El jueves 13 de septiembre de 2018 a las 10:04 a. M. Bruce A. Mah [email protected]
escribió:

@awardblvr https://github.com/awardblvr : Depende, supongo, de cómo
definir "exitoso". Supongo que una medida podría ser que si
end.sum.lost_packets es cero, entonces el receptor no detectó ninguna pérdida
paquetes. Sin embargo, existen algunos casos extremos en torno a esto, que en su mayoría tienen que ver
con lo que sucede con los paquetes que todavía están en vuelo cuando el cliente
declara la prueba completada.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/esnet/iperf/issues/584#issuecomment-421079759 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa
.

Encontré un problema similar con la falta de Tx / Rx B / W independientes para UDP.
Tomó un enfoque diferente.

Calculé RxMbps usando TxRate y Drop%.

TxMbps = result.Mbps
RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100))

Servidor --- 10 Mbps --- SRX (enrutador) --- 5 Mbps ----- Cliente
(Modeladores de tráfico aplicados en las interfaces SRX)

Pruebo ambas direcciones a 20 Mbps.

Carga de iPerf3 UDP:

Remoto: 10.8.8.100
Local: 10.9.9.222
Protocolo / Puerto: UDP / 33333
Hora de inicio: dom, 10 de enero de 2021 03:51:23 GMT
Duración (seg): 10
Velocidad de transmisión: 20,0 Mbps
Tasa de recepción: 9.58Mbps
Jitter: 0,7 ms
Paquetes perdidos: 8990
Porcentaje perdido: 52,07%
CPU local: 9.03%
CPU remota: 0,76%

Descarga de iPerf3 UDP:

Remoto: 10.8.8.100
Local: 10.9.9.222
Protocolo / Puerto: UDP / 33333
Hora de inicio: dom, 10 de enero de 2021 03:51:38 GMT
Duración (seg): 10
Tasa de transmisión: 20.0 Mbps
Tasa de recepción: 4.82Mbps
Jitter: 0,49 ms
Paquetes perdidos: 13172
Porcentaje perdido: 75,9%
CPU local: 2,5%
CPU remota: 8.26%

@ hakujin22 , "_RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100)) _" probablemente no funcionará en general. Esto se debe a que los datos se recopilan solo localmente y no también desde el extremo remoto. Por ejemplo, en los datos que envió, el ancho de banda del enlace entre el servidor y el cliente es de 5 Mbps. Sin embargo, asumiendo que la carga es de servidor a cliente, tiene 10 Mbps en el servidor. Esto se debe a que esta es la medida del rendimiento del servidor a SRX y no de un extremo a otro.

@ bmah888 , dado que los datos del servidor se pueden recibir usando --server-output , el siguiente enfoque puede usarse como una solución / solución para el problema de estadísticas de resumen UDP JSON:

1. Las secciones JSON "_sum_received_" y "_sum_sent_" se agregarán al resumen de UDP _end_ tanto en el servidor como en el cliente. Esta sección no reemplazará a la sección _sum_.
2. El "_sum_received_" incluirá datos distintos de cero solo de un receptor. Por ejemplo, el cliente lo establecerá cuando se utilicen -R o bidireccional, pero lo establecerá en cero cuando solo haya un remitente.
3. "_sum_sent_" se establecerá utilizando reglas similares, pero para remitente o bidireccional.

Este enfoque parece ser compatible con versiones anteriores de la solución actual. Si aprueba, este puede ser un enfoque utilizable, intentaré implementarlo.