Why Is RDP Sluggish on a Fast Connection? — Investigating Input, Rendering, and the Network Separately

A speed test reports hundreds of Mbps, yet in Remote Desktop the characters you type appear slightly late. Scrolling through a photo-heavy page makes the screen stutter. A business app freezes for a few seconds only when you click its search button. Where should you start investigating this kind of “the line is fast but RDP is sluggish” situation?

RDP’s responsiveness to input is not determined by the line’s transfer rate alone. Even when the speed test is fast, the wait may occur somewhere in the network round trip, input waits in the app on the host, encoding of the screen, or decoding and display on your local device. First separate out “which operation is slow,” then compare the same operation while changing one condition at a time. Use comparisons and measurements to narrow down where to investigate, and choose UDP and GPU settings to match those results. See: The spans that connection quality measures, Performance factors on session hosts.

However, narrowing down where to investigate does not yet establish the root cause. Even if lowering the resolution helps, it changes not only the network traffic but also the graphics processing at both ends, so do not conclude that “the line was the cause.” Record the results, keeping the spans you measured separate from the spans you did not.

This article isolates input, scrolling, and app responsiveness after the connection is established. Even when symptoms look alike, there is not necessarily a single cause. Cases where “the sign-in screen takes a long time to appear” or “it stops only at authentication” are treated as a separate problem, to be investigated from the connection-establishment and authentication records.

The main audience is users and administrators who connect from Windows “Remote Desktop Connection” (mstsc) to Windows 11 or Windows Server. The command examples are for Windows PowerShell 5.1. The article assumes that you can reproduce the same operation in an established session.

Direct connections, VPN, RD Gateway, and Azure Virtual Desktop differ in their paths, the diagnostic information available, and where settings apply. The TCP 3389 check example is limited to permitted direct connections to an RDP host that uses the standard port. Do not apply the diagnostic features or GPU settings described in Azure Virtual Desktop documentation as-is to ordinary in-house PCs.

On company devices, investigate only within the scope your administrator permits. On a shared host, identify your own session and the target process, and if you need other users’ records, ask your administrator. Check for each environment whether performance counters are available, what they are called, and what permissions they require.

The checking methods shown here are based on official documentation. They are not a measured report of reproducing and resolving a failure on a particular device. Numerical examples are clearly marked as assumptions for the sake of explanation.

You can read about the mechanism in order, starting with the next section, “Transfer Rate and Round-Trip Time.” If you want to start from the symptom, go to “Choosing the First Comparison by Symptom.” The hands-on procedures are in “Comparing One Condition at a Time” and “Measuring Where the Wait Is.”

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (7 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

Transfer Rate and Round-Trip Time

RDP (Remote Desktop Protocol) is the protocol that exchanges input, screen information, and other data between your local device and the host. It carries not only the screen and input but also information for device redirection, printing, and the like. See: What RDP transfers.

The line’s transfer rate expresses how much data it can carry per second. The “500 Mbps” from a speed test is a figure about this amount. It is not a figure that shows the time from performing an action until the response arrives. See: RDP bandwidth requirements.

flowchart TB
    accTitle: What a speed test figure represents
    accDescr: Shows that the 500 Mbps from a speed test is a figure for the amount of data that can be carried per second, a different figure from the time between performing an action and the response arriving.
    A["Speed test: 500 Mbps"] --> B["Data carried per second"]
    B -.->|"A different figure"| C["Time until the response arrives"]

Figure 1: A speed test figure shows how much can be carried, not how long a response takes to arrive.

Round-trip time (RTT) is the time it takes for a transmission to reach the other end and come back. The difference between raising the transfer rate and shortening the round-trip time is like the difference between adding lanes to a road and shortening the distance to the destination. Even if the capacity to carry large numbers of files grows, the wait for a response to an action remains as long as the round-trip time stays the same. See: RTT and screen display latency.

flowchart TB
    accTitle: Transfer rate and round-trip time compared to a road
    accDescr: A diagram that compares raising the transfer rate to adding lanes to a road, and shortening the round-trip time to shortening the distance to the destination.
    A["Raise the transfer rate"] -->|"On a road"| B["Add lanes"]
    B ~~~ C["Shorten the round-trip time"]
    C -->|"On a road"| D["Shorten the distance"]

Figure 2: Adding lanes does not shorten the distance to the destination.

The Round Trip for One Character

Consider typing one character into Notepad on the remote machine. Notepad runs on the host. For the sake of explanation, if we assume 50 milliseconds for the input to arrive and 50 milliseconds for the resulting screen information to come back, the time spent on the network totals 100 milliseconds, or 0.1 seconds. Processing time at both ends is left out of this example.

flowchart TB
    accTitle: Example of network time until one character's result comes back
    accDescr: An example that assumes 50 milliseconds each way for the sake of explanation. It excludes processing time at both ends and does not represent the number of packets per key.
    A["Type one character locally"] -->|"Out: 50 ms"| B["Host receives the input"]
    B --> C["Send the updated screen"]
    C -->|"Back: 50 ms"| D["Result arrives locally"]

Figure 3: Assuming 50 milliseconds out and 50 milliseconds back, the network alone takes 0.1 seconds. These are not measured values.

Even if the line can carry more, this 0.1 seconds remains as long as the round-trip time does not change. Figure 3 is a conceptual diagram for understanding the processing. It does not mean that an independent round trip of packets is sent for each key. The path to the speed test server also differs from the path to the RDP host, so take into account VPNs, gateways, the upstream link on the host side, and congestion along the way. See: How to think about RTT, Network and host performance.

Building and Delivering the Screen

Interaction delay, as used here, is the wait from performing an action locally until you see the result. Not only RTT but also the app’s processing and the work of building and delivering the screen play a part. It is also distinct from the latency of the screen transfer span alone. See: The measured span from screen capture to display.

When input reaches the host from your local device, the app on the host processes the input and updates the screen, the encoded screen information is carried over the line, and your local device decodes and displays it. Before and after the network leg, there is also work handled by separate PCs. See: Processing from screen capture to display.

flowchart TB
    accTitle: Screen processing happens on both sides of the line
    accDescr: The flow from local input reaching the host, the host app processing it and building and compressing the screen, to the screen information carried over the line being turned back into a displayable form and displayed locally.
    I["Local: enter input"] --> J["Line: carry the input"]
    J --> K["Host: app processes it"]
    K --> A["Host: build, compress screen"]
    A --> B["Line: carry screen data"]
    B --> C["Local: restore displayable form"]
    C --> D["Shown on the local screen"]

Figure 4: Processing and compression on the host, carrying over the line, and restoring for display locally. Each is work done in a different place.

Encoding, in this article, is the processing on the host that converts and compresses the screen into a form that is easy to send. Separately from the transfer over the line, it takes processing time on the host. See: Encoding time on the host.

Decoding, in this article, is the processing that turns the screen information that has arrived back into a form that can be displayed locally. It is distinct from decryption in the sense of removing encryption. See: Local decoding and display time.

If compression on the host takes time, sending waits for it to be ready even when the line is idle. Even when the information has arrived, updates are delayed if local decoding or display cannot keep up. It is not necessarily true that “the office PC is powerful, so any local device will do.” Headroom on the line and headroom in the processing at either end of it are separate things. See: Performance counters for graphics processing.

flowchart TB
    accTitle: Delays when processing at either end cannot keep up
    accDescr: Shows that if compression on the host takes time, sending waits for it even when the line is idle, and that if local decoding or display cannot keep up, updates are delayed even after the information has arrived.
    A["Host compression takes time"] --> B["Waits to send despite idle line"]
    B ~~~ C["Local decoding falls behind"]
    C --> D["Updates lag even after arrival"]

Figure 5: Even with headroom on the line, screen updates are delayed if processing at either end cannot keep up.

Typing Versus Scrolling

When you add one character in Notepad, only a small part of the screen changes. When you scroll through a photo-heavy page, a wide area of the display changes in quick succession. RDP keeps traffic down by transferring the changed parts and by compression and caching suited to the content. It does not send the whole screen uncompressed every time. The amount of work varies with the screen content and how often it updates. See: Screen content and bandwidth.

flowchart TB
    accTitle: How the screen workload differs between typing and scrolling
    accDescr: A small change of one character and continuous updates over a wide area differ in the nature of the work of building and sending the screen.
    A{"Screen change"} -->|"Add one character"| B["Small area"]
    A -->|"Scroll"| D["Wide area, continuously"]
    B --> E["Compress, send per change"]
    D --> E

Figure 6: Even on the same connection, the workload differs between adding one character and a wide area that keeps moving.

Even if a static document is light, graphics transfer may run out of headroom while you scroll. Increasing the remote resolution or the number of monitors also enlarges the screen to be processed. A comparison that lowers the resolution is an experiment to see whether motion recovers when the work of building and sending the screen is reduced. It is not a calculation that determines traffic from the pixel count alone. See: Effects of resolution, screen updates, and compression.

Waiting in the App

If only the business app’s search freezes for a few seconds while you can type normally in Notepad in the same session, check what that app is waiting for. The app on the host may in turn ask a separate database to run a search or read files from a shared folder, and then wait for the reply. That is a different path from the RDP traffic between your local device and the host. See: Traffic from the host to back ends.

flowchart TB
    accTitle: There are other parties beyond RDP
    accDescr: Shows a case where, separately from the traffic between the local device and the host, the app on the host waits for a reply from a business server.
    A["Local device"] -->|"RDP"| B["Business app on the host"]
    B -->|"Search, file request"| C["Database, shared folder"]
    C -->|"Awaited reply"| B

Figure 7: The business app beyond RDP may in turn wait for a reply from yet another server.

When the processing responsible for the screen and input takes on a long job, the next input and screen update are delayed. In WPF, for example, responsiveness suffers when the UI thread is occupied for a long time. Low overall CPU usage alone does not rule out waits on a particular UI thread. See: The Dispatcher and the UI thread.

flowchart TB
    accTitle: The processing for the screen and input gets stuck
    accDescr: Shows that when the processing responsible for the screen and input takes on a long job, the next input and screen update are delayed, and that low overall CPU usage alone does not rule out that wait.
    A["Processing for screen and input"] --> B["Takes on a long job"]
    B --> C["Next input, update delayed"]
    C -.- D["Low total CPU doesn't rule it out"]

Figure 8: Overall CPU usage alone cannot rule out waits on the UI thread.

Choosing the First Comparison by Symptom

How much can be carried, how long you wait for a response, and how long it takes to build and display the screen are separate things. If you keep this distinction, you can start investigating from the operation that is slow right now, instead of putting “RDP is sluggish” down to a single cause.

flowchart TB
    accTitle: Separate the three before investigating
    accDescr: Shows not putting “RDP is sluggish” down to a single cause, but separating how much can be carried, the time spent waiting for a response, and the time to build and display the screen, and investigating from the operation that is slow now.
    A["“RDP is sluggish”"] --> S
    subgraph S["Look at separately"]
    direction TB
    B["How much can be carried"] ~~~ C["Time waiting for a response"]
    C ~~~ D["Time to build, display screen"]
    end
    S --> E["Start from the slow operation"]

Figure 9: Separating how much can be carried, the time spent waiting for a response, and the time to build and display the screen lets you start from the operation that is slow right now.

The goal of isolating the problem is to limit where you look for the slowness. Changing settings all at once and making things faster by chance is not the goal. By using differences such as “Notepad works but only search freezes” or “typing is normal but only scrolling is sluggish,” you can choose where to start investigating even before changing any network settings.

The following table is a starting point for investigation. It is not a table for determining the cause. Compare operations in the same session first, then change the device, path, or display conditions as needed.

Characters Lag in Several Apps

If characters lag one by one in several apps in the same session, compare the same operation from another device or over another permitted path as well. Cross-check the round-trip time, input waits on the host, and the overall load on the host, and do not decide the cause from a single number.

Only Scrolling Stutters

Even if typing is normal, scrolling through a photo-heavy page produces a continuous run of wide-area screen updates. Change the remote resolution or the number of monitors one at a time and compare on the same page. If it improves, compression on the host, graphics transfer, and local decoding are the next things to investigate. Resolution alone does not tell you which of these three is the cause. See: Load from screen content and resolution.

Only One App Freezes

If only the business app in which you clicked search freezes, compare whether Notepad or other apps in the same session respond. If other apps are working, first investigate the target app’s processing, the disk, and requests to databases or shared folders. Operating the app over RDP is not the same thing as RDP traffic being the cause of the wait. See: Performance factors in apps and back ends.

Everyone Slows Down When More Users Log On

If several users slow down during the same time period, check with your administrator about the state of the other sessions. Cross-check the load on the shared host’s CPU, memory, and storage and on the shared line against the times of the symptom. Do not access other users’ records or processes without permission, and do not stop their jobs. See: Shared host resources and the number of users.

Slowdowns While Copying or Printing

If the trouble coincides with the time you started your own copy or print job, pause only the transfers you are permitted to stop, and compare. Record whether things recover after pausing and whether they slow down again when resumed, and investigate contention with non-screen transfers and device redirection. Do not run comparisons that disable all the devices needed for work at once. See: Impact of device redirection.

Comparing One Condition at a Time

You do not need to change every setting in turn. First establish a baseline for comparison, then choose only the checks that fit the symptom. Before changing settings or reconnecting, save your work and record the original values and how to restore them. If you lack the necessary permissions or features, do not force them on; hand over to your administrator.

Local operation and operation over RDP are not necessarily the same conditions. Being fast on the host’s physical screen is a useful reference, but the session and rendering conditions may differ. Match the user, data, and app state, and do not pin the cause on the line just because “it is fast on the physical screen.”

Comparing the Same Operation

Prepare the same user, data, and operation. On a shared host, confirm your own session, and do not stop other users’ apps or processes. Using another device or another path is also limited to what your administrator permits.

1. Reproduce the slow operation with the original settings, and record the time and the symptom.

   In Notepad in the same remote session as the problem app, type about the same amount of text. Distinguish whether it is only one app or the whole session.

2. Check the load on the host and on your local device during the same time period.

   In Task Manager, look at the target app’s CPU, memory, and disk on the host, and at the RDP client’s load on your local device. Check the target process, not just the overall CPU figure. See: What to examine for load.

3. Change only one condition (another device, another permitted path, or the display conditions), and repeat the same operation.

   In comparisons where the state of the host or the app also changes at the same time, record that difference too. Do not treat the result of changing several conditions as the effect of a single condition.

4. Return to the original conditions, and recheck the same operation.

   If it stays fast even after reverting, a temporary change in load or something similar is also possible. Do not assume that the change worked; record the conditions under which the symptom reproduces.

With results for the original state, the changed state, and the reverted state in hand, you can compare which conditions correspond to the symptom. A condition that brought improvement is a clue for the investigation; on its own it does not prove the root cause.

flowchart TB
    accTitle: Limit the conditions changed at once
    accDescr: A flow that fixes an operation that reproduces in the original state, changes only one condition to compare, and also checks the result after reverting.
    A["Same operation, original settings"] --> B["Change only one condition"]
    B --> C["Repeat the same operation"]
    C --> D["Revert and recheck"]
    D --> E["Record the improving condition"]

Figure 10: Repeat the same operation in the original state, after the change, and after reverting, and record the condition that made a difference.

Comparing the Remote Resolution

Use this comparison when screen updates, such as scrolling, are sluggish. Record the resolution and number of monitors before the change, save your work, and then reconnect. Do not go on using, as-is, settings that impair the screens or the text legibility needed for work.

1. Change only one of the two: the number of monitors or the resolution.

   In mstsc, you can compare by using the “Display” settings before connecting or by specifying the width and height. See: Display options in mstsc.

2. Confirm that the actual size of the host’s desktop has changed, then scroll the same page.

   If you only shrink the local window, it may simply be showing a large desktop scaled down. Distinguish dynamic resolution from smart sizing, and check the conditions your client supports. See: Desktop resolution and display scaling.

3. Return to the original settings, repeat the same operation, and compare the load at both ends and the motion on the screen.

   If you switched to a low resolution and a single monitor together, the comparison is only a rough one. If it improves, revert them one at a time to separate their effects.

If it improves, there is a clue within the scope of graphics processing and graphics transfer. 3840×2160 has four times the pixels of 1920×1080, but traffic does not always become four times larger. It varies with the changed areas and compression, and changing the resolution also affects the processing at both ends. See: Pixel count and traffic, Checking graphics processing.

flowchart TB
    accTitle: What a lower-resolution comparison can tell you
    accDescr: Lowering the remote resolution can change the load of both graphics processing and transfer, so an improvement alone cannot pin the cause on the line.
    A["Lower the remote resolution"] --> S
    subgraph S["Processing that changes"]
    direction TB
    B["Graphics processing on host"] ~~~ C["Amount of data sent"]
    C ~~~ D["Local display processing"]
    end

Figure 11: Changing the resolution is a comparison that affects not only the line but also graphics processing on the host and on the local device.

Cross-Checking Copying and Printing Against the Symptom

Pause only processing you are permitted to stop, such as transfers you started yourself. Do not stop company backup or security processing, or other users’ jobs. Do not disable redirection of all the audio and input devices needed for work at once.

1. Record the same operation and the load before and during a copy, cloud sync, or print job.

   Besides the screen, RDP also carries information for drives, printers, and similar devices. Redirection, which lets the host use your local devices, can increase network and processing load while it is in use. See: Impact of device redirection.

2. Pause the transfer in question within the permitted scope, and recheck the same operation.

   If you can resume it and compare, record the symptom after resuming as well. If you also experiment with unneeded device redirection, change one item at a time and make sure you can restore the original settings.

You can judge whether the start of a transfer lines up with the trouble, and whether pausing lines up with recovery. If you see a correspondence, cross-check non-screen transfers and the load on shared resources against your administrator’s records.

flowchart TB
    accTitle: Viewing before and after the trouble on one timeline
    accDescr: Record the same operation and load before a transfer, during it, and after stopping it, and compare how the trouble relates to the work.
    A["Operation, load before transfer"] --> B["Operation, load during transfer"]
    B --> C["Operation, load after stopping"]
    C --> D["Do trouble and recovery match?"]

Figure 12: Look at how the slowness of the same operation and the load change before the transfer, during it, and after stopping it.

Measuring Where the Wait Is

From your local device, examine the network round trip and the TCP connection; on the host, examine the input queue wait and screen updates. Every one of these numbers covers only a limited span, so read the results against the table in “What the Measurements Cover.”

Checking ICMP and the TCP Connection

Run this on your local Windows device. It covers only configurations that connect directly, over the corporate LAN or a permitted VPN, to an RDP host that uses the standard TCP 3389. For configurations that go through RD Gateway or Azure Virtual Desktop, or that use a custom port, decide with your administrator what to check. Do not expose ports or change the firewall.

1. Enter a permitted host, and record the ICMP response and TCP connection results.

   $target = Read-Host 'Name or IP address of the RDP host you are permitted to investigate'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Specify the host to connect to.'
   }
       
   # Check ICMP response times over several attempts. Do not judge RDP unreachable from a failure alone.
   ping.exe -n 20 $target
       
   # A check limited to configurations that connect directly to the standard TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Cross-check the results from slow periods and from normal times against the times of the symptom and the actual connection path.

   Twenty ping attempts are a short observation. Record fluctuations in the values and missing responses, but keep in mind that ICMP may be blocked. Do not rule out intermittent stalls from the average alone; use the connection information and your administrator’s network records. See: What ping measures.

TcpTestSucceeded: True means that a TCP connection to the specified port succeeded. It does not measure bandwidth, UDP, operation after authentication, or screen smoothness. Test-NetConnection has no -UDP switch for checking UDP. See: Test-NetConnection syntax and output.

Keep differences in path and service in view when you judge. With RD Gateway and similar, the path of ICMP or a direct TCP connection to the host may not match the actual RDP path. Azure Virtual Desktop provides per-connection RTT and bandwidth estimates, but that diagnostic feature is specific to that service. Do not rule out short stalls from averages alone. See: Connection quality logs in Azure Virtual Desktop.

flowchart TB
    accTitle: The path you checked and the actual RDP path
    accDescr: In configurations that use RD Gateway or similar, the path of ICMP or a direct TCP connection from the local device to the host may not match the actual RDP path.
    A["Local device"] -->|"ICMP, direct TCP"| C["RDP host"]
    A -->|"Actual RDP"| B["RD Gateway, etc."]
    B --> C

Figure 13: ICMP or a direct TCP connection to the host and the actual RDP traffic may not follow the same path.

Measuring the Input Queue Wait

User Input Delay measures the wait on the host from when input enters the queue until a process takes it out. It is not the total time from pressing a key until you see the character. See: Definition of User Input Delay.

Examine this inside the remote session on the host. Microsoft’s supported conditions are Windows 10 version 1809 or later and Windows Server 2019 or later. On these targets, no registry entry needs to be added to enable it. Check the display names, the permissions, and whether the counters exist; if they are unavailable, record that fact and consult your administrator. See: Supported conditions and setup.

1. In PowerShell in the same session, note the time and the session ID.

   Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
   (Get-Process -Id $PID).SessionId
   query.exe session
       
   

   Querying other users’ sessions may require additional permissions. The standard instance name for a target process is SessionID:ProcessID <Process Image>. Do not go by the session ID alone and end up mixing in values from other users or from processes with the same name. See: Permissions for query session, Identifying instances.

2. In perfmon.exe, add whichever of User Input Delay per Process or User Input Delay per Session is available.

   Select the target process or session, and start by observing at the default one-second interval. Distinguish the aggregate instance, which combines several sessions, from the values for individual sessions.

3. Reproduce the operation in which input is slow, and compare the queue wait with the times of the symptom.

   For an individual measurement target, the value shows the maximum wait within the measurement interval. Even when the value is low, the processing after the app takes the input out and the delay until the result comes back to your local device remain.

You can find out whether input is waiting in the input queue on the host. It is a different metric from the perceived time, which includes the network round trip and display on your local device. See: What the maximum value and the measurement interval mean.

flowchart TB
    accTitle: The span that User Input Delay measures
    accDescr: The measured span runs from the input queue on the host until the app takes the input out; the network and screen display before and after it are not included.
    A["Input arrives from local device"] --> B["Enters host's input queue"]
    B -->|"Measured here"| C["App takes the input out"]
    C --> D["App processing, screen transfer"]
    D --> E["Displayed locally"]

Figure 14: What is measured is the wait in the host’s input queue. It is not the total time until you see the result locally.

Checking Screen Updates and Why Frames Are Skipped

Prepare an operation with continuous screen updates, such as scrolling. Whether the RemoteFX Graphics counters are available, and where they are measured, needs to be checked for your OS, host configuration, and permissions. Here you only read counters that are available. This is not a procedure for installing or enabling the old RemoteFX features. See: Where the Graphics counters apply.

1. Use query session or qwinsta to confirm the target session name, and select the corresponding counter instance.

2. During an operation with screen updates, compare Input Frames/Second and Output Frames/Second.

   If output is lower than input, frames are being skipped along the way. Check the Frames Skipped/Second values broken down by insufficient resources on the host, the network, and the client.

3. Cross-check the reasons for skipping against the load at both ends and on the network, and also check Average Encoding Time.

   If the encoding time is long, investigate the compression processing on the host. If the frame count is already low on the input side, the app may simply not be updating the screen often. A low frame count on a static screen is not abnormal in itself.

From the input and output during screen updates, the reasons for skipping, and the encoding time, you can narrow down where to investigate. The counter categories are clues; judge them together with the actual load and the connection configuration. See: Reading frame counts and encoding time.

flowchart TB
    accTitle: Narrowing the investigation from skipped frames
    accDescr: During an operation with screen updates, compare input and output frame counts and, using the skip-reason counters as clues, cross-check against processing, network, and display load.
    A["Compare in/out while scrolling"] --> B["If output is low, check skips"]
    B --> C["View counters by reason"]
    C --> D["Check host, network, local load"]

Figure 15: Compare input and output while scrolling, and cross-check the reasons for skipping against the load on the host, the line, and the local device.

Do not generalize conceptual diagrams of graphics transfer or old documentation to every configuration. Some configurations transfer video and audio through a separate mechanism. The Graphics counter documentation also describes older configurations, so do not reinterpret the figures it gives as a common specification such as “all RDP is capped at 30 fps.” Check where each feature and figure applies before using it. See: Graphics transfer and workloads, Graphics counter documentation.

What the Measurements Cover

Do not equate a low number with comfortable operation. You can check the scope of each metric in the Microsoft documentation cited in the procedures.

Network and GPU Settings

Choose UDP and GPU settings to match what you learned from comparisons and measurements. If the network is suspect, first check the transport and the path; if graphics processing is suspect, first check the stages at which the GPU is used.

Checking TCP/UDP and the Connection Path

When comparisons and measurements point to the network, check with your administrator which client, path, and applied policies are in use. Even when a settings change is needed, keep it within the approved scope, and record the previous values and how to restore them. Do not disable the firewall or authentication, and do not expose the RDP port directly to the internet.

1. Confirm the TCP/UDP actually in use and the path from the connection information, the product’s diagnostic logs, and your administrator’s network records.

   RDP uses TCP or UDP depending on the configuration and network conditions. “Select RDP transport protocols” lets you choose between a setting that uses either UDP or TCP and a TCP-only setting. Because RDP can also fall back to TCP when a UDP connection cannot be established, a successful connection alone does not tell you the transport. See: Choosing the RDP transport and fallback.

2. Cross-check the path and transport against the times of the symptom, and compare only the necessary settings, one at a time.

   Do not make a blanket change on the assumption that “turning off UDP will make it faster.” Compare with the VPN and gateway conditions, the operation, and the display conditions matched, and revert changes that are not needed.

With the transport and the path understood, you can record how changes relate to the symptom. Switching to TCP only does not always speed things up.

flowchart TB
    accTitle: Check the transport before comparing network settings
    accDescr: Distinguish ordinary direct connections from connections through gateways or services, check the actual path and transport, and then make permitted comparisons.
    A["Client in use, connection setup"] --> B["Check actual path, TCP or UDP"]
    B --> C["Match against symptom times"]
    C --> D["Compare needed settings singly"]

Figure 16: Confirm the transport and path in use, match them against the symptom, and only then compare the settings that are needed.

RDP Shortpath is an Azure Virtual Desktop mechanism. It establishes a UDP path for that service and, depending on the configuration, uses a direct path or a relay. If the path cannot be established, it falls back to a TCP-based connection. It cannot be put in the same settings table as a direct mstsc connection to an in-house PC. See: RDP Shortpath paths and fallback.

flowchart TB
    accTitle: RDP Shortpath paths and fallback
    accDescr: RDP Shortpath in Azure Virtual Desktop tries to establish a UDP path; if established, it uses a direct path or a relay depending on the configuration, and if not, it falls back to a TCP-based connection.
    A["RDP Shortpath"] --> B{"UDP path"}
    B -->|"Established"| C["Direct or relay"]
    B -->|"Not established"| D["Fall back to TCP-based"]

Figure 17: If RDP Shortpath cannot establish a UDP path, it falls back to a TCP-based connection.

Checking GPU Use in Graphics Processing

Check this when comparisons and measurements point to graphics processing. Review the graphics processing measurements together with the supported OS, drivers, policies, and client. Do not change settings merely because a GPU is installed. Obtain your administrator’s approval and prepare to revert before you start.

1. Separate rendering in the host app, RDP encoding, and local decoding, and choose the suspect stage.

   Even with a GPU, not every stage necessarily uses it. Microsoft’s configuration documentation for Azure Virtual Desktop also configures and verifies rendering in the remote session and hardware encoding of frames separately. See: GPU configuration and verification for rendering and encoding.

2. Following the target product’s procedures, confirm the actual usage, and measure the same operation before and after any necessary change.

   If compression time is long, look into GPU use for encoding. Changing the encoding settings for an app that is waiting in the input queue targets the wrong place. Text legibility and smooth video also call for different trade-offs among image quality, traffic, and processing load. See: Differences by workload.

Going beyond whether a GPU is present, you can record whether the GPU is used at the stage in question and how the load and responsiveness of the same operation changed. Revert changes that bring no improvement, after confirming with your administrator.

flowchart TB
    accTitle: Check GPU use stage by stage
    accDescr: Separate rendering in the host app, RDP encoding, and local decoding, and because not every stage necessarily uses the GPU even when one is present, check its use at the suspect stage.
    A["Rendering in the host app"] --> B["RDP encoding"]
    B --> C["Local decoding"]
    C -.- D["Check GPU use per stage"]

Figure 18: Even with a GPU, rendering, encoding, and decoding do not necessarily all use it.

Rechecking and Handing Over

Confirm an improvement by checking that, after the change, the same operation can be done without trouble and that the necessary image quality, devices, and business functions are preserved. Also cross-check against the result after reverting to the original conditions. If the recovery is only momentary, do not settle the cause; record it, including busy periods and concurrent processing.

flowchart TB
    accTitle: The order for confirming an improvement
    accDescr: Shows confirming that the same operation works without trouble after the change and that the necessary image quality, devices, and business functions are preserved, cross-checking against the result after reverting, and not settling the cause on a momentary recovery alone.
    A["Try same operation after change"] --> B["Check quality, devices, functions"]
    B --> C["Compare with reverted result"]
    C -.- D["Momentary recovery settles nothing"]

Figure 19: Besides the result of the same operation, also cross-check the necessary functions and the result after reverting.

Handing Over When Unresolved

No improvement, no reproduction, or unavailable counters are also useful results. Separate the comparisons you were able to carry out from the checks you could not, and hand over to your administrator or developers with the following memo. Remove business information not needed for the investigation, such as user names and host names, from shared logs.

Time and time zone when the symptom occurred:
Host OS, client in use, and its version:
Direct connection / VPN / RD Gateway / Azure Virtual Desktop, etc.:
Slow operation and app; response of other apps in the session:
Remote resolution and number of monitors:
Copying, printing, etc. running at the same time:
The one condition changed, and the result after reverting:
Load and counters observed on the host and locally:

Also add whether the TCP/UDP actually in use could be confirmed, which items could not be checked because of insufficient permissions or similar reasons, and which settings are acceptable for the business. Saying “typing in Notepad is normal, but it freezes when I scroll through photos” rather than “the line is slow” lets the next person investigate under the same conditions.

Users keep a record of the operation that reproduces the problem and of the comparison results, and administrators cross-check the records of the connection path, shared host, and sessions. The mere fact that you are waiting over RDP does not mean that the processing keeping you waiting is RDP itself. See: Division of work between the host and back ends.

App developers log the receipt of input events, the start and end of database and file processing, and the reflection in the UI separately. They also consider a design that does not leave heavy work sitting on the UI thread. However, a processing-complete log on the host does not record that display has completed on the local device. See: Separating work to keep the UI responsive.

Related Articles

• How to Think About Windows Session Isolation
• Isolating a Windows Disk at 100% Safely
• Why Does ‘1 Second Remaining’ Take So Long?

References

These are primary sources on Microsoft Learn. The referenced content was checked on September 17, 2026. When reading them, distinguish the conditions that apply to each product, and keep in mind that they are not measurements carried out for this article.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. The distinction between RTT and the latency from screen capture on the host to display on the local device. The diagnostic feature itself is for Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. How screen content, resolution, frame updates, compression, and caching relate to traffic.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. How to check screen input and output, the reasons for skipped frames, and encoding time. Because it includes descriptions of older configurations, do not generalize its numeric limits to all RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Load on shared hosts, traffic from the host to back ends, and the impact of device redirection.
• Microsoft Learn, Threading model. The WPF UI thread and Dispatcher, and separating work to keep the UI responsive.
• Microsoft Learn, mstsc. Specifying the Remote Desktop width and height and multiple monitors.
• Microsoft Learn, Supported RDP properties. The distinction between desktop resolution, dynamic resolution, and smart sizing. Check the supported clients and the conditions that apply to each product.
• Microsoft Learn, ping. Checking responses with ICMP Echo, and its options.
• Microsoft Learn, Test-NetConnection. TCP connection checks and what the output means.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. The span User Input Delay measures, the target OS versions, instances, and what the maximum value means.
• Microsoft Learn, query session. Session information and the permissions required to query other sessions.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Choosing the TCP or UDP transport that RDP uses, and fallback.
• Microsoft Learn, RDP Shortpath. UDP paths for Azure Virtual Desktop, and the behavior when one cannot be established.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. GPU configuration and verification that treat rendering and frame encoding separately.

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These are topic pages close to this theme. Starting from the article, you can go on to related services and other articles.

Services Connected to This Topic

This article leads to the following service pages. Start from the entry point closest to your situation.

Frequently Asked Questions

Questions commonly asked at the time of consultation about the topic of this article.

A speed test shows hundreds of Mbps, so why is RDP input slow?

How fast large amounts of data are carried and how long it takes for a response to an action to come back are different things. Sending the input, processing by the app on the host, compressing the screen, transferring it, and displaying it on your local device are all involved. The network path also differs between the speed test server and the RDP host.

Typing works normally, but only scrolling stutters. Is that a network problem?

You cannot narrow it down to the network alone. When screen updates increase, rendering and compression on the host, the network, or decoding and display on your local device may fail to keep up. Change the remote resolution or the number of monitors one at a time and compare, and if necessary examine the graphics-related counters.

If ping is fast, is RDP communication working normally?

That alone is not enough to judge. ping measures responses to ICMP; it does not measure RDP graphics transfer or app processing. In configurations that use RD Gateway or similar, the path may not match either. If there is no response, distinguish ICMP being blocked from RDP itself being unreachable.

Is User Input Delay the time from pressing a key until the character appears?

No. It is a counter that measures the wait on the host from when input enters the queue until a process takes it out. It is not the perceived delay that includes the network round trip, the app processing after the input is taken out, and compressing, decoding, and displaying the screen.

Should I disable UDP when RDP is slow?

We do not recommend it across the board. First check the actual transport, the path, and the policies applied. UDP may be unavailable and the connection may have fallen back to TCP, and switching to TCP only does not always make things faster. Compare under matched conditions with your administrator's permission, and revert changes that are not needed.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and bug investigation, with particular strength in projects where existing assets remain and in investigating failures whose cause is hard to see.