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:
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.
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.
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)
