Extremely slow RDP into Windows 10 and Windows Server 2016

Discussion in 'Hardware' started by Zzzz1, Jan 15, 2017.

  1. Zzzz1

    Zzzz1

    I usually dont use RDP but directly access hardware resources of machines in my private lan network. But lately had a need to setup RDP (remote desktop services). It is extremely slow with noticeable lag even on machines that are connected to one and the same network on the same subnet. Pinging shows <1ms latencies but when I type text in my RDP session there is a lag almost to the tune of 1 second. It makes using the RDP session almost useless.

    I have tried all the usual suspects suspected on the net such as turning off ipv4 receive and send offload on the nic on both host and client, setting a flag for autotuning, and such forth, not much love.

    Anyone has some suggestions what else to try?

    Thanks
     
  2. Overnight

    Overnight

    Have you tried simpler suspects, like background services? Are there extra firewall/anti-virus bits inspecting everything you type/every packet you try to send? Spidey-Sense says that something is running in the background that is slowing down your TX/RX of packets, and perhaps even at a lower-level on the OSI, if that is what Win Server 2016 uses.
     
  3. Zzzz1

    Zzzz1

    Thanks but I have tried that, network speed is as expected, no bottlenecks there. I also checked to RTD the other way around from the server into the desktop workstation and it is blazing fast, no latency there. The issue is when remoting into the server.

     
  4. What are the specs of the win boxes that you are RDP into as well as the specs of the box that you remote from? Lack of physical memory on either side (your box local host and remote) could be a problem as Session Mem is needed to support the RDP session. RDP creates extra memory demands to support the session. When real mem runs low it starts using the disk to create page memory/virutal mem. Hard Disk instead of real mem is a slow down. If you don't even have a real local hard disk and are instead using a network mapped drive on a SAN then this will make it super slooooow!.There are also technical details of the Apps/DLLs that are running that can cause the memory footprint to spike greatly only during an RDP session. This could be your source of latency.
     
    Last edited: Jan 16, 2017
  5. Zzzz1

    Zzzz1

    Remote From: i76700K, 32gb memory, Win 10 64bit, OS on SSD
    Remote To: Dual Xeon E5-2690, 64 gb memory, Windows Server 2016 Standard, OS on SSD and 4x 4TB HDD in storage space as mirror.

    I would say plenty enough resources for RTD ;-)

    It is something more subtle and non-trivial I am afraid. I tried both, team viewer and vnc and both are without latency but then the technology is different as both those apps only do screen mirroring rather than creating a virtual desktop. Still, it shows that the network is plenty fast enough, and there should be no hardware limitations in play.




     
  6. Just to be sure document the resource usage on both ends before, during and after RDP.
     
  7. Zzzz1

    Zzzz1

    I do not see any particular issues with resource usage (and vnc works perfectly fine, I am almost giving up on RDP and inclined to used vnc, only). It has instead something to do with the multiple fine tuning possibilities of RDP such as autotuning, various offloads in the NIC, and the like. I thought I captured most but apparently something is still missing. Thanks for sharing your thought.

     
  8. Zzzz1

    Zzzz1

    I gave up on trying to tune RDP and instead decided to go with VNC (particularly, RealVNC). It worked out of the box and I do not experience any latency. Question will be down the road what to do with VM instances on my Xeon server box.
     
  9. I am not personally familiar with VNC. I was actually going to suggest that you try to RDP from a VM instance on your laptop and run a version of Win Server that is the same version but run it inside the VM image as well. I did not post that solution because I figured you would come up with a better solution, and it sounds like you did.
     
  10. Zzzz1

    Zzzz1

    thanks mate, I have not considered the VM route so far because I do not have the need to run VM instances. VM is not really for me because GPU passthrough for my AI research still does not fully function yet. But thanks for your advice, much appreciated.

     
    #10     Jan 17, 2017