Iperf: UDP에 대한 수신기 대역폭이 누락 된 JSON 출력

권리. 이것은 아주 오래된 버그로, 처음부터 iperf3에 있었을 것입니다. 나는 # 562에 대한 작업을 할 때 그것을 깨달았습니다 (왜 문제를 제기하지 않았습니까?). 올바르게 지적했듯이 UDP 테스트는 클라이언트 측과 수신자 측 통계를 별도로 분류하지 않습니다. 보고 된 내용이 클라이언트인지, 보낸 사람인지, 아니면 둘 중 하나인지 잘 모르겠습니다. TCP가 다른 이유도 분명하지 않습니다.

기존 JSON을 사용하는 프로그램과 어떤 종류의 호환성을 유지하는 방법을 잘 모르겠지만 UDP 테스트가이 점에서 TCP와 비슷한 통계 출력을 내보낼 수 있다면 좋을 것입니다 (발신자 측과 수신자 측 모두 개별적으로). 산출. (# 562에서는 사용자가 첫 번째 출력 스 니펫에 제시 한 UDP에 대한 사람이 읽을 수있는 출력을 수정했습니다. 프로그램이 어쨌든 출력을 읽으려고하면 안되기 때문에이 경우 이전 버전과의 호환성에 대해 덜 걱정했습니다.)

UDP JSON 출력에 대해이 문제에 대한 해결 방법이 있습니까? 우리는 JSON 출력을 구문 분석하려고하지만 무엇인지 확실하지 않습니다. 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
            },

그러나 우리는이 바이트가 무엇인지 확실하지 않습니다. 전송 된 바이트입니까 아니면 수신 된 바이트입니까?

언제 수정 되나요? JSON 출력에서 ​​수신자의 bps를 가져와야합니다.

해결 방법이 있습니까?

지금은 로드맵에 없습니다. 이 문제를 해결하려면 실제로 클라이언트와 서버 간의 상태 시스템 및 프로토콜을 변경해야합니다.

물어봐도 될까요 ... UDP로 테스트하고 클라이언트 측에서 json을 구문 분석하고

end.sum.bits_per_second     AND 
end.sum.lost_packets

전송이 서버 측에서 데이터를 보내고 받는지에 대해 공정하게 표현할 수 있습니까? 양방향 전송 / 수신이 성공했는지 확인하려면 어떻게해야합니까? 다음에서 텍스트 출력을 구문 분석합니다.

- - - - - - - - - - - - - - - - - - - - - - - - -
[ 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 : "성공"을 정의하는 방법에 따라 다릅니다. 한 가지 측정 값은 end.sum.lost_packets 이 0이면 수신자가 손실 된 패킷을 감지하지 못한 것입니다. 그러나 클라이언트가 테스트가 완료되었다고 선언 할 때 여전히 비행중인 패킷에 발생하는 상황과 관련된 일부 예외적 인 경우가 있습니다.

감사합니다 ...,이 ONE json 출력을 읽고 볼 수 있다는 것을 알고 싶습니다.
기본적으로 서버-> 클라이언트 및 패킷에서 전송 된 패킷
클라이언트에서 전송-> 서버가 도착했으며 손실이 없음
클라이언트가 수신 한 패킷의 패킷 :

나는 그것을 믿는다 :

end.sum.packets.
end.sum.lost_packets
end.sum_receiver.packets <--- NEW PATCH
end.sum_receiver.lost_packets <--- NEW PATCH

내가 틀렸다면 나를 고쳐주세요!

"종료": {
"sum": {
"종료": 10.00,
"초": 10.00,
"bits_per_second": 1058280.26,
"바이트": 1322892,
"패킷": 81,
"시작": 0,
"jitter_ms": 0.056,
"lost_packets": 0,
"lost_percent": 0
},
"스트림": [
{
"udp": {
"종료": 10.00,
"소켓": 5,
"초": 10.00,
"bits_per_second": 1058280.26,
"바이트": 1322892,
"패킷": 81,
"out_of_order": 0,
"시작": 0,
"jitter_ms": 0.056,
"lost_packets": 0,
"lost_percent": 0
}
}
],
"sum_sender": {<--- NEW with PATCH
"종료": 10.00,
"초": 10.00,
"bits_per_second": 1058280.26,
"바이트": 1322892,
"패킷": 81,
"시작": 0,
"jitter_ms": 0,
"lost_packets": 0,
"lost_percent": 0
},
"sum_receiver": {<--- NEW with PATCH
"종료": 10.00,
"초": 10.00,
"bits_per_second": 1058271.16,
"바이트": 1322892,
"패킷": 81,
"시작": 0,
"jitter_ms": 0.0568,
"lost_packets": 0,
"lost_percent": 0
}

감사

-ㅏ

2018 년 9 월 13 일 목요일 오전 10:04 Bruce A. Mah [email protected]
썼다 :

@awardblvr https://github.com/awardblvr : 그것은 당신이 어떻게
"성공"을 정의하십시오. 한 가지 방법은
end.sum.lost_packets가 0이면 수신자가 손실을 감지하지 못했습니다.
패킷. 그러나 이와 관련된 몇 가지 예외적 인 경우가 있습니다.
클라이언트가
테스트가 완료되었음을 선언합니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/esnet/iperf/issues/584#issuecomment-421079759 또는 음소거
실
https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa
.

UDP에 대한 독립적 인 Tx / Rx B / W가 부족하여 유사한 문제가 발생했습니다.
다른 접근 방식을 취했습니다.

TxRate 및 Drop %를 사용하여 RxMbps를 계산했습니다.

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

서버 --- 10Mbps --- SRX (라우터) --- 5Mbps ----- 클라이언트
(SRX 인터페이스에 적용된 트래픽 셰이퍼)

나는 20Mbps에서 양방향을 테스트합니다.

iPerf3 UDP 업로드 :

원격 : 10.8.8.100
로컬 : 10.9.9.222
프로토콜 / 포트 : UDP / 33333
시작 시간 : 2021 년 1 월 10 일 일요일 03:51:23 GMT
기간 (초) : 10
전송 속도 : 20.0Mbps
수신 속도 : 9.58Mbps
지터 : 0.7ms
분실 된 패킷 : 8990
손실 비율 : 52.07 %
로컬 CPU : 9.03 %
원격 CPU : 0.76 %

iPerf3 UDP 다운로드 :

원격 : 10.8.8.100
로컬 : 10.9.9.222
프로토콜 / 포트 : UDP / 33333
시작 시간 : 2021 년 1 월 10 일 일요일 03:51:38 GMT
기간 (초) : 10
전송 속도 : 20.0Mbps
수신 속도 : 4.82Mbps
지터 : 0.49ms
분실 된 패킷 : 13172
손실률 : 75.9 %
로컬 CPU : 2.5 %
원격 CPU : 8.26 %

@ hakujin22 , "_RxMbps = TxMbps-(TxMbps * (result.lost_percent / 100)) _"은 일반적으로 작동 하지 않을 것입니다. 이는 데이터가 원격 끝이 아닌 로컬에서만 수집되기 때문입니다. 예를 들어 전송 한 데이터에서 서버-클라이언트 종단 간 링크 대역폭은 5Mbps입니다. 그러나 업로드가 서버 대 클라이언트라고 가정하면 서버에서 10Mbps를 얻습니다. 이는 서버에서 SRX 처리량에 대한 측정치이며 종단 간이 아니기 때문입니다.

@ bmah888 , --server-output 사용하여 서버 데이터를 수신 할 수 있으므로 UDP JSON 요약 통계 문제에 대한 솔루션 / 해결 방법으로 다음 접근 방식을 사용할 수 있습니다.

1. "_sum_received_"및 "_sum_sent_"JSON 섹션이 서버와 클라이언트의 UDP _end_ 요약에 추가됩니다. 이 섹션은 _sum_ 섹션을 대체 하지 않습니다 .
2. "_sum_received_"에는 수신자의 0이 아닌 데이터 만 포함됩니다. 예를 들어 클라이언트는 -R 또는 양방향이 사용될 때이를 설정하지만 송신자 만있는 경우 0으로 설정합니다.
3. "_sum_sent_"는 유사한 규칙을 사용하여 설정되지만 발신자 또는 양방향에 대해 설정됩니다.

이 접근 방식은 현재 솔루션과 역 호환되는 것 같습니다. 이것이 유용한 접근 방법이 될 수 있음을 승인한다면 나는 그것을 구현하려고 노력할 것입니다.