• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 611
  • Last Modified:

Remote Desktop Performance

I apologise in advance if this question is too complex to answer with a single post, however we are trying to optimise our remote desktop performance to our clients which I have some gaps in my understanding of I guess the basics of how the packets are flying around. So some background info:

-We have multiple virtual servers at our office which clients connect into via RDP
-We have an 80Mbps fibre link of which its bandwidth is never more than 20%

Why is it that slower ADSL internet connections (say less than ~5Mbps) have very poor RDP performance, yet when monitoring bandwidth utilisation on the WAN port of the router, traffic never gets higher than about 20% of the bandwidth with an occasional spike here and there..
Whereas faster ADSL connections (say ~10Mbps+) have much better general performance  but on the router, traffic still never gets higher than about 2Mbps with occasional spikes

We use Ericom Blaze RDP server/client which compresses the data a bit and definitely helps with performance to a small degree, especially when scrolling.

-In all our cases latency to our server is the same with maybe up to 5ms difference
-In the cases I am taking into account similar load at the clients end
-I thought it may be failings with the routers we use however tests with various brands still yield the same results
-Am i wrong in assuming that if I am at the clients end and performance is generally slow from say scrolling a graphics rich web page, shouldn't I expect to see their Internet connection being used to it's full potential?

And one more thing, this only applies to ADSL connections, with Fibre connections, usage is utilised as expected for their bandwidth.

Thanks in advance
1 Solution
There are 3 things that influence remote network performance:

- bandwidth
- latency
- packet loss

If latency or packet loss are high, you will usually see that bandwidth is not fully used. ADSL usually has higher latency and packet loss than fiber links and low end ADSL is worse is those aspects.
QlemoBatchelor and DeveloperCommented:
If packet loss happens too often, e.g. because of overly used fragmentation or wrong MTU, than indeed the bandwidth utilized overall goes down, because of timeouts and TCP/IP reducing its send/receive window sizes. (The latter leads to the stack waiting more often for packet acknowledgements, stopping transferring meanwhile).

Wrong MTU can be a big issue. Slower ADSL lines might have smaller max. packet sizes, which allows for better mixing of the different data streams of the ISP. Also, upstream and priorization of packets (e.g. ACK in preference over big packets) is involved.

There are many factors, making it difficult to tell in general why one connection is slower than another. But you can't say slow ADSL is much worse than faster ADSL.
progressitAuthor Commented:
Thanks Qlemo, your answer helped put us on the right track, MTU was indeed part of the solution. We optimised our MTU based on our connection on both the router and the workstations for our PPPoE connections. We also tweaked the QoS guaranteed and burstable bandwidth options in our router and applied it to a rule specific to RDP data, even when it doesn't compete with other traffic, this still seems to help (for Cyberoam's at least).

Whilst the slower ADSL connections still don't use the maximum bandwidth, we have managed to at least optimise them so that Remote Desktop performance is much more responsive now.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now