This article is designed to help customers assess the symptoms of the impact of latency, packet loss, and bandwidth on the RDP user experience. Most importantly, this article provides options and recommends robust tools that you can use to troubleshoot issues that undermine RDP user experience.

Latency describes the length of time it takes for a packet of data to go from the computer hosting the user desktop to the RDS Host and back, known as round-trip-time (RTT). It is also referred to as ping and expressed in milliseconds in one second (ms).

The ideal latency for the best user experience over RDP is less than 100ms. Good user experience can be maintained even after latency increases up to 120ms. The user experience will begin to deteriorate when the latency is more than 150ms. High latency increasingly becomes problematic as networks expand to include remote desktops and connect to cloud servers to deliver virtual workspaces.

The main symptom of high latency is “laggy” performance and response, which manifests as:

The fact that the RDP user experience is very latency-sensitive means that you can only improve RDP user experience by addressing network latency. So, you have to measure network latency.

Checking your network latency should be the first step you take after lags in performance and response undermine the user experience. How do you check your network latency using Windows?

The milliseconds attained from this basic latency measurement are the RTT between the user's device affected by lags and the host. Latency can also be measured as the time it takes for the first byte of data in the user's request to be received by the RDS Host known as Time to First Byte (TTFB).

If the RTT attained in this latency measurement procedure is higher than the ideal latency required to deliver good RDP user experience, you will have to employ some tactics to reduce network latency.

Reducing high latency in your network requires an assessment of the different steps you can take at various points across the network to eradicate or suppress the impact of the factors contributing to high latency. So, what are the factors to suppress or eradicate?

Based on this analysis, you can troubleshoot network latency issues to suppress or eliminate the impact of these and other factors contributing to high latency on your network.

When it comes to addressing problems due to multifaceted factors, you start with the basic factors and move towards more complex contributors.

If the bad latency-related experience persists, latency issues are coming from the larger network connecting the RDS Host to the user desktop. You have to test the latency of the network connecting the user’s desktop host to the RDS host. The most effective approach is to measure the user's latency to the GCP Region hosting the RDS Host.

We recommend using www.gcping.com, a highly effective online-based tool developed especially to measure latency and test GCP connectivity. Once you open the GCP, the browser on the user's device hosting RDP makes HTTP requests to instances in different GCP regions and displays the median time between request and response.

If the test determines that latency to the GCP Region hosting the RDS Host is more than 100ms, you may have to move the customer to a GCP Region that is closer.

Information is transmitted as packets containing discrete units of data, which are meaningless individually until they all come together to recreate the content or message being transmitted. During transmission, packets can be lost or delayed as the message being transmitted moves from one hub to the other on the network. The main causes of packet loss include faulty cables, insufficient bandwidth, congestion, software issues, and insufficiency of hardware components like switches, routers, and firewalls.

Packet loss negatively affects RDP user experience by stalling data in the network before it is delivered to the user. To maintain reliable and orderly delivery of data, TCP requires any lost packets to be retransmitted by the sender and creates a queue for lost packets awaiting retransmission. All packets sent after the lost packet are held in the user’s TCP queue and can’t be delivered until the lost packet is retransmitted, which leads to stalling known as Head of Line Blocking.

Since all the packets are held, packet loss manifests as a black screen due to a lack of data input flowing into the user's device. Using the black screen as the symptom of packet loss, you can use it as a diagnostics yardstick to eliminate potential causes.

First, you eliminate physical connections and software then proceed to network connections. To rule out physical connections and software as the cause of packet loss, you have to:

Whenever you execute any of these checks, and the black screen persists, it eliminates physical connection, hardware, or software as the cause of packet loss. If the black screen persists, you can proceed to test packet loss on your wireless coverage and the larger network connection.

You can test packet loss caused by issues either with wireless signal coverage or the larger network connection. If you are using Windows 10 connected to a standard Wi-Fi domestic network, you can test packet loss in two steps:

First Step: Command Prompt

Second Step: Testing packet loss

If the results indicate 100% success and 0% fail, you can eliminate Wi-Fi as the cause of package loss and proceed to test packet loss due to issues on the larger network connection.

There are several online tools you can use to test packet loss on the larger network. For one, you can use Google.com to test the internet connection against potential congestion. If these tests do not reveal the cause of packet loss, you can retest by changing the device, time, or location.

Network bandwidth refers to the capacity of a wired or wireless network to transmit the maximum amount of data from one point to another per second and is measured as kbps. Even though speed and bandwidth are used interchangeably, they do not mean the same. Speed is the rate at which data is sent, while bandwidth is the capacity of the network at a given speed. Bandwidth consumption on a network can undermine the capacity of the network leading and reduce the volume of data transmitted.

Bandwidth consumption increases when too many users are downloading or streaming large and heavy content on the network. The overload leads to:

Although these are the symptoms of excessive bandwidth usage, you still need to identify the activities consuming bandwidth.

This task can be accomplished using built-in bandwidth-usage monitoring tools available in the user’s Windows.

Once you identify the devices and processes consuming large amounts of bandwidth, turn them off or ask the users of these devices to refrain from activities that consume too much bandwidth. If the problem persists, contact your service provider.

RDP is designed impeccably to consume as little bandwidth as possible without affecting user experience. RDP attains very low bandwidth usage in two ways:

For standard business applications, RDP delivers the best user experience with a connectivity of as low as 256kbps. For instance, if users are working on Excel and Word, they will be sending out just a few Kbps of bandwidth.

When it comes to improving user experiences, latency is more important than bandwidth. For one, the importance of bandwidth in improving user experience is restricted to applications that send or receive large amounts of data. For example, bandwidth is important for downloading videos, watching videos on Netflix, uploading videos to YouTube, and so on. In other applications that don't involve a large amount of data, latency plays a bigger role in the user experience. From web browsing to online gaming, video conferencing, and chatting, latency enhances the performance of applications that are more interactive or real-time. Also, you can increase bandwidth drastically by reducing latency.

Sometimes, improving user’s experiences can come down to the basics, either more CPU or RAM or both. We recommend monitoring and alerting tools for Compute resources.

At itopia, we provide historical resource utilization insights fromthe VM Instances module under the Cloud manager section. You can access Compute utilization insights easily by just clicking on the problematic server. Using itopia’s VM Instances module, you can select the day from the calendar, and the Compute utilization graph for the RAM and CPU will be displayed instantly. If real-time alerting is needed, then Google Stackdriver is the way to go.