높은 대역폭과 지연으로 인해 tc로 트래픽 셰이핑이 정확하지 않습니다.

Question

트래픽 셰이핑을 위해 tc과 커널 2.6.38.8을 사용하고 있습니다. 대역폭 제한이 작동하고 지연이 추가되지만 대역폭을 지연으로 구성 할 때 한계가 1.5Mbps를 초과하면 달성 대역폭은 항상 한계보다 훨씬 낮습니다.

예 :

tc qdisc del dev usb0 root 
tc qdisc add dev usb0 root handle 1: tbf rate 2Mbit burst 100kb latency 300ms 
tc qdisc add dev usb0 parent 1:1 handle 10: netem limit 2000 delay 200ms 

201 밀리 초 (핑)에서 지연하지만 (iperf)에서 단지 1.66 Mbps의 용량을 산출한다. 지연을 제거하면 대역폭은 정확히 2Mbps입니다. 대역폭을 1 Mbps 및 200 ms RTT로 지정하면 모든 것이 작동합니다. 나는 ipfw + dummynet도 시도해 봤는데 비슷한 결과가 나왔다.

Kconfig에서 HZ=1000으로 커널을 재구성하려고 시도했지만 문제가 해결되지 않았습니다. 다른 아이디어?

Answer 1

실제로 문제가 아니며 정상적으로 작동합니다. 200ms 레이턴시를 추가 했으므로 전체 2Mbps 파이프는 완전한 잠재력을 발휘하지 못합니다. TCP/IP 프로토콜에 대해 좀 더 자세히 공부 해보길 권합니다.하지만 여기에 iperf에 대한 간단한 요약이 있습니다. 기본 창 크기는 아마 3 패킷 (각각 1500 바이트) 일 것입니다. 파이프를 3 개의 패킷으로 채우지 만, 지금은 확인 응답을 얻을 때까지 기다려야합니다 (이것은 혼잡 제어 메커니즘의 일부입니다). 200ms 동안 전송을 지연하기 때문에 시간이 걸릴 것입니다. 이제 창 크기가 두 배로 커지고 다음에 6 패킷을 보낼 수 있지만 다시 200ms를 기다려야합니다. 그러면 창 크기가 다시 두 배가되지만 창문이 완전히 열려있을 때까지 기본 10 초의 iperf 테스트가 끝나고 평균 대역폭은 분명히 작아집니다. 이 같은 그것의

Answer 2

생각한다

는 1 시간에 당신의 대기 시간 및 2 메가 비트/s의 속도를 설정하자.

2Mbit/s는 TCP ACK에 대해 (예를 들어) 50Kbit/s를 필요로합니다. ACK가 소스에 도달하는 데 1 시간 이상 걸리므로 소스가 2Mbit/s로 계속 전송할 수 없습니다. TCP 윈도우가 첫 번째 승인을 기다리는 동안 여전히 멈춰 있기 때문입니다.

지연 시간과 대역폭이 생각보다 비슷합니다 (적어도 TCP에서는 UDP가 다른 이야기입니다)