tohojo
commented
3 years ago olg33 notifications@github.com writes:
Hi,
We are installing a new satellite link and we are using flent to run bandwidth testing. The idea is to saturate the link with marked and unmarked packets.
However initial results show that the test was not able to reach the maximum bandwidth downstream supported by the link which is about 60Mbps.
For unmarked traffic we ran the following test:
flent rrul -H 10.111.40.252For marked traffic we used the following test:
flent rrul_var -H 10.111.40.252 --test-parameter bidir_streams=5 --test-parameter markings=11,13,15,19,21On both cases we reached no more than 50% of the link capacity.
To rule out any problem with the link itself, we ran the following test:
flent tcp_12down -H 10.111.40.252This time. we were able to reach saturation levels (60Mbps) of downstream traffic. Also ran iperf3 and obtained the same results
Do you see any reason why the rrul and rrul_var tests aren't being able to generate enough traffic to saturate the link? Maybe any parameter I'm missing or something? Or maybe that's normal, anyhow, I'd appreciate any comment on this matter.
Hmm, when you say satellite link, I assume this has really high RTT, right? This usually makes it really difficult for TCP to saturate the connection; I believe providers try to improve on this with various kinds of "accelerators" that mess with the TCP connection to try to alleviate this problem. That could be failing when there's bidirectional traffic?
Another thing to note is that when you're running bidirectional traffic the bulk traffic will be competing with ACKs in each direction. In particular, if there's a lot of queueing delay in the upstream, that will delay the ACKs which can prevent TCP from ramping up properly on the downstream. What kind of queueing is on the bottleneck link, and are you seeing the latency increase?
By my guess the latter effect would be most likely, or maybe a combination? You may be able to see something interesting if you capture the traffic and look at some tcptrace plots of the transfers.
The RRUL test is deliberately designed to stress connections to induce these sorts of weird failure cases, so I guess you could say it's not unexpected. But obviously it's not an ideal functioning of the link :)
flent-users
olg33
Hi,
We are installing a new satellite link and we are using flent to run bandwidth testing. The idea is to saturate the link with marked and unmarked packets.
However initial results show that the test was not able to reach the maximum bandwidth downstream supported by the link which is about 60Mbps.
For unmarked traffic we ran the following test:
flent rrul -H 10.111.40.252For marked traffic we used the following test:
flent rrul_var -H 10.111.40.252 --test-parameter bidir_streams=5 --test-parameter markings=11,13,15,19,21On both cases we reached no more than 50% of the link capacity.
To rule out any problem with the link itself, we ran the following test:
flent tcp_12down -H 10.111.40.252This time. we were able to reach saturation levels (60Mbps) of downstream traffic. Also ran iperf3 and obtained the same results
Do you see any reason why the rrul and rrul_var tests aren't being able to generate enough traffic to saturate the link? Maybe any parameter I'm missing or something? Or maybe that's normal, anyhow, I'd appreciate any comment on this matter.
Thanks.