PRA Jump Client and RDP session latency for AutoCad and other GPU-rendered use cases

Where is the remote connection being made in relation to the appliance?  ie, is the remote target on one coast and the appliance on the other?  Another country?

I would think that screen scraping HD/4k is going to expect some latency, simply due to the resolution.

There are options in the access to console to render/lower the resolution to assist performance.

In the console, select File > Settings > Screen Sharing > Default Quality

Hope this helps.

Todd

In my experience with those types of use cases, external BYOT RDP is the only option. We use it for GIS / high-res mapping applications and the built-in native bomgar jump client and desktop access console method is unusable. The screen scraping method that is used is just not ideal for this type of application. However, when we use Microsoft’s native RDP via the external BYOT RDP feature, we see much better results and it is very usable. 

As a test, you should try to use native RDP from one part of your network (ideally replicated your BT PRA if possible, but as close as you can) TO the same graphics workstations you’re referring to and see what that performance is like using your applications. I am saying do not involve BT PRA at all to get a baseline. If that doesn’t work well already then adding anything else (no matter what the remote access product is), you probably can’t do what you’re trying to do. Or you have to use an entirely different approach like Teradici, Horizon, VDI built for 3D modeling, etc. 

May be unrelated, but we've seen similar performance issues when remoting into physical workstations with no monitor connected. Installing HDMI dummy dongles improved performance significantly.

We've also seen different results between BT Remote RDP and Jump Client console access.

In some cases, using a local Jumpoint/gateway server on the same network as the target endpoint has also improved performance.