Iperf: Saída JSON sem largura de banda do receptor para UDP

Direito. Este é um bug muito antigo, que pode estar presente no iperf3 desde o início. Eu meio que percebi (por que não registrei um problema para isso?) Quando estava fazendo o trabalho no # 562. Como você observou corretamente, os testes UDP não separam as estatísticas do lado do cliente e do lado do receptor separadamente. Não tenho certeza se o que foi relatado é o cliente, o remetente ou uma confusão dos dois. Também não está claro para mim por que o TCP é diferente.

Seria uma coisa boa se os testes UDP pudessem emitir uma saída de estatísticas que é mais parecida com o TCP neste aspecto (ambos os lados do emissor e do receptor separadamente), embora eu não tenha certeza de como manter algum tipo de compatibilidade com programas que consomem o JSON existente resultado. (Em # 562, eu corrigi a saída legível por humanos para UDP, que você apresentou em seu primeiro trecho de saída ... Eu estava menos preocupado com a compatibilidade com versões anteriores nesse caso porque os programas não deveriam estar tentando ler essa saída de qualquer maneira.)

Existe alguma resolução feita para este problema para a saída UDP JSON? Estamos tentando analisar a saída JSON, mas não temos certeza do que é. Um exemplo de saída JSON é: -

    }],
            "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
            },

mas não temos certeza do que é essa coisa de bytes, são bytes enviados ou bytes recebidos?

Quando será consertado? Preciso obter os bps do receptor da saída JSON.

Talvez haja alguma solução alternativa?

Não está no roteiro agora. Corrigir isso realmente requer uma mudança na máquina de estado e no protocolo entre o cliente e o servidor.

Posso perguntar ... Se estiver testando com UDP e eu analisar o json do lado do cliente e obter

end.sum.bits_per_second     AND 
end.sum.lost_packets

Terei uma representação justa se a transmissão está enviando e recebendo dados do lado do servidor? O que eu preciso fazer para verificar se as duas direções de envio / recebimento foram bem-sucedidas? Analise a saída 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 : Acho que depende de como você define "sucesso". Suponho que uma medida pode ser que, se end.sum.lost_packets for zero, o receptor não detectou nenhum pacote perdido. No entanto, existem alguns casos extremos em torno disso, principalmente relacionados ao que acontece com os pacotes que ainda estão em vôo quando o cliente declara o teste concluído.

Obrigado ..., eu só quero saber se posso ler este ONE json saída e ver
BASICAMENTE que os pacotes transferidos do servidor -> cliente e os pacotes
transmitido do cliente -> servidor chegou e que não houve perda
pacotes nos pacotes recebidos pelo cliente:

Eu acredito que seja:

end.sum.packets.
end.sum.lost_packets
end.sum_receiver.packets <--- NOVO com PATCH
end.sum_receiver.lost_packets <--- NOVO com PATCH

Por favor corrija-me se eu estiver errado!

"fim": {
"soma": {
"fim": 10,00,
"segundos": 10,00,
"bits_per_second": 1058280,26,
"bytes": 1322892,
"pacotes": 81,
"start": 0,
"jitter_ms": 0,056,
"lost_packets": 0,
"lost_percent": 0
},
"streams": [
{
"udp": {
"fim": 10,00,
"soquete": 5,
"segundos": 10,00,
"bits_per_second": 1058280,26,
"bytes": 1322892,
"pacotes": 81,
"out_of_order": 0,
"start": 0,
"jitter_ms": 0,056,
"lost_packets": 0,
"lost_percent": 0
}
}
],
"sum_sender": {<--- NOVO com PATCH
"fim": 10,00,
"segundos": 10,00,
"bits_per_second": 1058280,26,
"bytes": 1322892,
"pacotes": 81,
"start": 0,
"jitter_ms": 0,
"lost_packets": 0,
"lost_percent": 0
},
"sum_receiver": {<--- NOVO com PATCH
"fim": 10,00,
"segundos": 10,00,
"bits_per_second": 1058271.16,
"bytes": 1322892,
"pacotes": 81,
"start": 0,
"jitter_ms": 0,0568,
"lost_packets": 0,
"lost_percent": 0
}

Obrigado

-UMA

Na quinta, 13 de setembro de 2018 às 10h04, Bruce A. Mah [email protected]
escrevi:

@awardblvr https://github.com/awardblvr : Depende de como você
definir "sucesso". Suponho que uma medida pode ser que se
end.sum.lost_packets é zero, então o receptor não detectou nenhuma perda
pacotes. Existem alguns casos extremos em torno disso, no entanto, principalmente tendo que fazer
com o que acontece com os pacotes que ainda estão em vôo quando o cliente
declara o teste concluído.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/esnet/iperf/issues/584#issuecomment-421079759 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa
.

Encontrou um problema semelhante com a falta de Tx / Rx B / Ws independentes para UDP.
Teve uma abordagem diferente.

Calculei RxMbps usando TxRate e Drop%.

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

Servidor --- 10 Mbps --- SRX (roteador) --- 5 Mbps ----- Cliente
(Traffic shapers aplicados nas interfaces SRX)

Eu testo ambas as direções @ 20Mbps.

Upload iPerf3 UDP:

Remoto: 10.8.8.100
Local: 10.9.9.222
Protocolo / porta: UDP / 33333
Horário de início: dom, 10 de janeiro de 2021, 03:51:23 GMT
Duração (seg): 10
Taxa de transmissão: 20,0 Mbps
Taxa de recepção: 9,58 Mbps
Jitter: 0,7 ms
Pacotes perdidos: 8990
Porcentagem perdida: 52,07%
CPU local: 9,03%
CPU remota: 0,76%

Download do iPerf3 UDP:

Remoto: 10.8.8.100
Local: 10.9.9.222
Protocolo / porta: UDP / 33333
Horário de início: dom, 10 de janeiro de 2021, 03:51:38 GMT
Duração (seg): 10
Taxa de transmissão: 20,0 Mbps
Taxa de recepção: 4,82 Mbps
Jitter: 0,49 ms
Pacotes perdidos: 13172
Porcentagem perdida: 75,9%
CPU local: 2,5%
CPU remota: 8,26%

@ hakujin22 , "_RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100)) _" provavelmente não funcionará em geral. Isso ocorre porque os dados são coletados apenas localmente e não também da extremidade remota. Por exemplo, nos dados que você enviou, a largura de banda do link de ponta a ponta do servidor para cliente é de 5 Mbps. No entanto, supondo que o upload seja do servidor para o cliente, você obteve 10 Mbps no servidor. Isso ocorre porque essa é a medida do servidor para a taxa de transferência de SRX e não de ponta a ponta.

@ bmah888 , uma vez que os dados do servidor podem ser recebidos usando --server-output , a seguinte abordagem pode ser usada como uma solução / alternativa para o problema de estatísticas de resumo JSON UDP:

1. As seções JSON "_sum_received_" e "_sum_sent_" serão adicionadas ao resumo UDP _end_ no servidor e no cliente. Esta seção não substituirá a seção _sum_.
2. O "_sum_received_" incluirá dados diferentes de zero apenas de um receptor. Por exemplo, o cliente irá defini-lo quando -R ou bidirecional forem usados, mas irá definir zero quando apenas um remetente.
3. "_sum_sent_" será definido usando regras semelhantes, mas para remetente ou bidirecional.

Essa abordagem parece ser compatível com as versões anteriores da solução atual. Se você aprovar, esta pode ser uma abordagem utilizável, tentarei implementá-la.