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.252` 
>
> For 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,21 `
>
> On 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.252`
>
> This 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 :)


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/218#issuecomment-745233711