iperf3: Multiple user Streams test does not start

Question

Im trying to use iperf3 to test where issues lie at a client that uses RDP to connect to our terminal-server. Their issue is that the RDP window freezes (mouse clicks mostly still go trough). Sometimes minimizing an maximizing the RDP windows helps, most times they need to disconnect and reconnect.

So im trying to use iperf3 to test both TCP and UDP protocols. As such I tried multiple tests, to see where the issue may be:

1. iperf3 -c SERVER -u -b 100M -l 500 -t 60 -R --get-server-output --interval 1 --udp

   The result was that all running RDP sessions froze - my fault since they only had a 40mbit contract with their ISP. Max Mbit/s was around 34-36.

2. iperf3 -c SERVER -u -b 35M -l 500 -t 60 -R --get-server-output --interval 1 --udp

   Result was about 33% Packet loss

   With this:
   iperf3 -c SERVER -u -b 35M -l 50 -t 60 -R --get-server-output --interval 1 --udp
   I only had 2 packets lost at the very beginning and then 0 afterward.

3. Then I tried to run multiple parallel simulations with the -P 5 options. (5 Parallel streams)

   iperf3 -c SERVER -u -b 35M -l 500 -t 60 -P 5 -R --get-server-output --interval 1 --udp

   The test started by saying the standard

   Connecting to host SERVER, port 5201 Reverse mode, remote host SERVER is sending

Otherwise I get a line for each second like this:

[  4]  47.00-47.43  sec  3.25MBytes   27.8Mbits/sec   0.085ms   798/3774 (21%)

but then nothing happened for a minute. Neither on the server nor on the client device.

To test what the issue is i reduced every possible variable and ended up at this:
iperf3 -c SERVER -u -b 1M -l 50 -t 60 -P 2 -R --get-server-output --interval 1 --udp
Bandwidth: 1Mbit
Packet Size: 50 byte
Parallel streams: 2\

And even with these low requirements I still just got the message about the connection being established without anything more happening.

I don't know enough about networks, RDP, UPD and iperf3 to pinpoint a specific cause of this issue. So my question is primarily how to interpret this happening?

• Do any of you have such issues?

Is it an iperf3 issue? (Don't think so, it worked with other customers and when testing beforehand if this even works with out Terminalserver setup)

• Do you have experience with such issue?

If so, was it the network being a bad setup or slow internet connection from ISP?

Currently Im assuming that there is an issue with the local network, since my understanding of Network would otherwise need to require me to believe that a 35Mbit/500Byte Packet size test is less straining than a 1Mbit/50Byte Packet size x2 test, which seem very much not possible. So I believe that the issue is more likely that a router or switch that the customer has may not be able to handle multiple parallel streams.

But as you can probably read: Im new to this and am happy for any input you guys may have!

If you need more info, just ask me!

EDIT:

I changed out the local Network switches hoping that would change something, since I assumed something locally might be the problem. After testing the issue when everything was done, I came across these results, that confused the hell out of me:

iperf3 -c SERVER -u -b 35M -l 500 -t 60 -R --get-server-output --interval 1

-> Package loss of 18-20% (marginally better than before)

iperf3 -c SERVER -u -b 35M -l 2000 -t 60 -R --get-server-output --interval 1

-> 0.x% Package loss.

iperf3 -c SERVER -u -b 35M -l 5 -t 60 -R --get-server-output --interval 1

-> Only messages about receiving packages out of order

I also tested iperf with the TCP protocol - which I hadnt done before because changing all the connection to TCP made things even worse before. But when I did it worked even with the multiple streams at the same time: iperf3 -c [server IP] -b 35M -l 1M -P 5 -t 60 -R --get-server-output --interval 1

Maybe to make the question more concrete: What can there be to make UPD RDP sessions work worse if we rediuve the bandwidth - which I did over the past few days to hopefully reduce the problem, but now I think it may have worsened it? (got to ask about this tomorrow more specifically)

Answer 1

I did not answer the question, but I at least solved the issue with RDP disconnects:

Based on the Results of the Tests, I manually increased the Bandwidth used for RDP to 10mbit/LAN instead of lowering it or leaving it at automatic. This solved the problem - so far: Instead of RDP windows freezing multiple times an hour it didn't happen for most of the day today.

Question still remains though: Why on earth would the test with UPD multiple users (-P 5) not start beyond the establishement of the connection . So if anybody can help with that, Id still appreciate it!