iperf 및 tcpdump를 사용한 패킷 손실률

와의 링크 품질에 대한 라인을 테스트했습니다 iperf. 측정 된 속도 (UDP 포트 9005)는 96Mbps로 두 서버가 모두 100Mbps로 인터넷에 연결되어 있기 때문에 좋습니다. 반면에 데이터 그램 손실률은 3.3-3.7 %로 나타났습니다. 고속 전송 프로토콜을 사용하여로 양쪽에 패킷을 기록했습니다 tcpdump. 패킷 손실을 계산 한 것보다 평균 0.25 %입니다. 이 큰 차이가 어디에서 오는지 설명하는 사람이 있습니까? 귀하의 의견으로는 수용 가능한 패킷 손실은 무엇입니까?

CPU가 계속 유지할 수 없기 때문에 UDP 모드에서 iPerf로 상당한 데이터 손실이 발생했습니다. 어떤 이유로 UDP를 사용하는 iPerf는 TCP를 사용하는 iPerf보다 CPU를 더 많이 사용하는 것으로 보입니다 . iPerf를 절반으로 설정했을 때 동일한 손실률이 발생합니까?

허용 가능한 패킷 손실 양에 대한 두 번째 질문에 대답하려면 실제로 실행중인 응용 프로그램, 트래픽 양에 따라 다릅니다. 실제로 대역폭 한도 미만이면 손실이 없어야합니다. 대부분의 경우, 아마 .25 %에 대해 너무 많이 불평하지는 않지만 실제로 높은 비율로 달리면 여전히 많은 손실이 있습니다.

[편집 1]이 주제에 관해 내가 생각한 다른 생각들 :

1. iPerf의 속도를 높이십시오. 어딘가에 체계적인 문제가 있다면, 비율에 관계없이 같은 비율의 손실을 경험할 것입니다. 하드웨어 한도에 도달했거나 공급자가 일종의 RED 를 수행하는 경우 특정 비율까지 손실이 없을 가능성이 높으며 그보다 높을수록 손실이 점차 커질 수 있습니다.
2. 테스트가 정확한지 확인하기 위해 iPerf 세션의 tcpdump 측정을 수행하십시오.
3. TCP로 iPerf를 사용해보십시오. 이것은 손실을보고하지 않지만 손실이 발생하면 연결을 매우 크게 확장 할 수 없습니다. 대기 시간도 이에 영향을 미치므로 가능한 한 짧은 대기 시간으로 엔드 포인트를 테스트해야합니다.
4. 연결 내부에 어떤 기어가 있는지에 따라 가능한 한 가까이 두십시오. 예를 들어 테스트 시스템과 에지 라우터간에 여러 스위치가있는 경우 직접 연결된 스위치로 이동하십시오.
5. 관리되는 스위치가있는 경우 통계가 없는지 확인하기 위해 통계를 확인하십시오. 100Mbps의 UDP 트래픽에 가까워지면 더 저렴한 스위치가 생겼습니다 (대부분 오래되고 저렴한 비 관리 형 스위치).
6. 두 개의 서로 다른 클라이언트에서 두 개의 다른 호스트로 동시에 iPerfs를 시도하여 한계가 CPU 또는 저렴한 로컬 NIC 카드의 결과가 아님을 확인할 수 있습니다.

TCP에는 하나의 흐름의 활용을 최대화하는 메커니즘이 있으며 UDP에는 없습니다. 따라서 각 응용 프로그램은 고유 한 메커니즘을 만들어야하므로 각 응용 프로그램마다 다른 접근 방식을 사용합니다. 아마도 Iperf는 정보 수신 여부에 대한주의없이 최대 가용 대역폭에 도달하려고하므로 더 많은 패킷 손실을 허용 할 것입니다. 다른 응용 프로그램은 많은 패킷을 잃지 않고 연결에서 사용 가능한 처리량으로 패킷 속도를 줄입니다.

tcpdump로 계산 한 패킷 손실이 iperf와 일치하는지 확인하기 위해 iPerf를 사용할 때 tcpdump를 사용하여 패킷 손실을 확인 했습니까?

측정 방법이 비교할 수 없음을 알게 될 것입니다.

는 iperf가 UDP에서 순서대로 도착하지 않은 패킷을 자동으로 폐기합니까? 연결에서 약간의 지터를보고있을 수 있습니다.