Hi Jason,

MS Remote Desktop (RDP) has many issues in combination with VEP. On specific plugins as well as MIR the OpenGL driver crashes and with it VEP. Therefore I highly suggest to use an alternative solution.

Best, Ben

See this thread for more information about Remote Desktop alternatvie:

https://www.vsl.co.at/community/posts/t53613-Can-t-connect-to-VEPro-on-new-PC-from-MAC#post290429

I also much prefer MS Remote Desktop and use it whenever possible.  I have only run into a few glitches with it, and it wasn't neccessarily OpenGL giving me problems, it was Plogue Bidule as a plugin inside VePro.   most stuff seems to work fine.  I would need to move my MirPro license over to this slave in order to test that, so I can't vouche for what MirPro is or isn't doing.  But I did run some OpenGL benchmarking tools on this slave and didn't have any problem...  that doesn't mean that there might not be some obscure OpenGL scenario with MirPro causing a problem.

I don't know why you're having the local adminstrator account permissions problems. I haven't experienced that yet and not sure what might be going on there, but that seems solvable with some windows OS configuration, of which I am not expert enough to give advice, sorry.

VNC or teamviewer are other alternatives instead of MS Remote Desktop, but I find them both appaling to use, so I just keep using MS Remote Desktop, but granted I have not spent hours and hours working that way and if I started to have any graphics related problems I would definitely switch to VNC.

"The RDP protocol just seems more efficient."

So, after some tests I'm going to contradict myself. RDP is actually a resource hog compared to VNC (at least, in my case). Here are a series of tests I performed, comparing the performance of both protocols (RDP vs. VNC). Note that this was just my specific scenario, and your mileage may vary. 

TEST SETUP:
MacPro (VNC/RDP client) connected via 1Gbps Ethernet to Windows 10 (VNC/RDP server).

VNC:
CPU usage max at 10% and Ethernet traffic spikes to about 25 Mbps. 

RDP:
CPU usage max at 15% and Ethernet traffic spikes to 160 Mbps.

So, given all of this it would make sense that RDP has a more responsive feel, because it is basically rendering a higher frame rate. I know the protocols work in quite different ways. Perhaps RDP is built to utilize max bandwidth? Given the much higher overhead of RDP on the NIC card is probably reason enough to stay away from it. Going to keep looking at some other options and I will report back.

Regards,
Jason Todd Shannon

I'm measuring the CPU and NIC on the slave Windows machine. 

I understand (from a high level) the differences in the protocols VNC/RDP. Upon further thought, I think that the difference in the CPU load has to do with the fact that VNC offloads the render to the GPU on the slave machine, whereas with RDP it is rendered on the local machine.

In terms of the network traffic, I think VNC is sending pictures/video so it is a "sustained bandwith" stream whereas RDP is sending bursts of traffic (the drawing instructions). So, although RDP is measuring instantaneously higher bitrates, it is likely sending much less data than VNC. It just depends on how WIN10 is measuring it. 

The difference in CPU usage is worth noting, however, especially given the fact that alot of sample libary slaves are really working the CPU. 

Neither one of those solutions is ideal, but given the differences in CPU load and the OpenGL errors/crashes I'm probably going to stick with VNC until I find something better. I left a VNC session open to monitor a VEPro slave for 12 hours, and it didn't crash, whereas it will crash about 90% of the time on RDP if left open/idle for more than about 2 hours. Anyway, I hope this thread is helpful to folks out there trying to get to the bottom of all of this.  

Regards,
Jason Todd Shannon

Originally Posted by: Jason T. Shannon

, whereas it will crash about 90% of the time on RDP if left open/idle for more than about 2 hours. Anyway, I hope this thread is helpful to folks out there trying to get to the bottom of all of this.  

What specifically are you running or doing when it crashes?  MirPro? Any other particular plugins?

I went deep into the rabbit hole on this one, and found a really well performing VNC configuration that I think works every bit as well (if not better, in many ways) than RDP. It takes a little bit of config, but hopefully what I'm sharing here will help others that are trying to make this work. 

VEP slave machine: Tight VNC Server
DAW/VEP master machine: RealVNC Viewer

I had to play with the different VNC encodings, but I found HEXTILE and ZRLE2 to work really well for high bandwidth LAN scenarios. You will find the encodings selection in a drop down menu in the "Expert" tab of the RealVNC Viewer configuration.  

This configuration comes at a cost of bandwidth consumption, but I'm on a Gigabit LAN and it isn't a big concern. CPU usage was about the same as RDP, slightly lower because of the GPU offload on the remote. 

Note that VNC doesn't just work "out-of-the-box" like RDP. The major benefit of RDP is the ease of use because it works with your native display resolution with no fuss. VNC is a different animal. Because it is rendered on the remote machine, you need to make sure that the resolution/aspect ratio doesn't conflict in any way with your native display. I found resolution mismatches to not only make the screen difficult to navigate and look awful, but it would cause visual artifacts and screen lags also. What really worked well for me was forcing the remote machine to render the display in the same resolution as my native display. Once you do this and get your encoding set to HEXTILE or ZRLE2 you will see a huge performance increase and a virtual display that looks and acts like your native desktop.

So, there you have it. With a little bit of configuration work and experimentation you can replace RDP with something that doesn't crash VEPro or give you startup errors. Best of luck! 

Regards,
Jason Todd Shannon

DEWDMAN, thanks for those results! Those were many of my experiences with VEPro/MIR/RDP.  

I forgot about the hassle of having to match my monitor display resolution to that of VNC which is a headache for me as I have a small monitor attached for emergencies but I do NOT want that to be the size I have to use remotely. I know there is a way to force a virtual session at a different size but I vaguely recall it’s difficult at best to setup; if at all.

That is another huge advantage of RDP for me, I can have my little emergency monitor plugged in and still use MS Remote Desktop at 4k, my main desktop resolution. My current pc doesn’t have an hdmi port on it but in the future I wonder if its possible to have both a real small emergency display as well as a larger virtual hdmi dongle and have VNC serve only the large virtual mirror? There could still be some weirdness with that I think most likely it would end up being possible to move the mouse cursor into the small displays area and then the remote VNC session would lose the cursor. Just thinking out loud, I don’t have any way to try it.

The problem is that if you have a real monitor and a dongle plugged in, that looks to the system like a dual monitor setup.  So then basically on my mac, i woudl see ONE of the two monitors.  Any window that inadventurantly gets sent to the other monitor, would not be visible to me on my remote session or if I accidentally moved the mouse curser over on to it...I would not see the mouse cursor any more, etc.. 

Anyway, its way too much work for me to mess around with that at this time, I don't use MirPro, so the problems you're having with RDP don't effect me and I would much rather stick with RDP for several different reasons, but I remember when I was experiementing with this months ago on VNC I ran into road blocks related to exactly this issue and I tried a lot of different htings, consumed a lot of time and in the end never reached a satisfactory solution, though I did not try to buy one of those HDMI dongles...and I don't plan to try that now..I'm fine with what I have.  The dongle could work fine for a totally headless scenario, but I like to have a real monitor attached so that when there is a problem I am not stuck with a headless box.  VNC is based on X windows technology and it may be possible to do some fancier tricks to  create a virtual desktop session that is not directly attached to the physical monitor.  But honestly I'm not needing to spend so much time figuring that out.

VNC is cool too because you can literally use a web browser to access your windows desktop.  its pretty cool tech, but aside from MirPro incompatbilities, I find RDP much nicer in general and for me anyway, it works now without the monitor size headaches I would have yet to resolve. 

Sounds like a decent solution if you need to use MirPro and don't have a physical monitor attached to the slave or don't mind using the same resolution as the physical monitor.

I tried this: https://knowledge.civilgeo.com/knowledge-base/enabling-gpu-rendering-for-microsoft-remote-desktop

But is seems VEP is hardcoded to not let the program start over Remote desktop when a MIR license is detected. So it is not possible for me to test if my configuration could run with this option enabled.

Wonder if this is tested by VSLs developers?