I use RDP windows to windows PC and it works perfect. No problems. It could be the Mac app.

Thanks, Dewdman. That thread was really informative. 

I have TightVNC Server running on the Windows PC slave and a VNC client on the Mac master. It isn't ideal, but it works. VNC is always laggy and not terribly responsive, but I guess that is the nature of VNC. It was easy to setup and get working. It seems reliable. 

I didn't try any of the commercial products, but my guess is that most of them are just fancy wrappers for VNC and will be prone to some of the same laggy UI issues. 

It would be great if this problem with RDP/OpenGL/MIR was eventually solved. RDP just works much better and is more responsive. The RDP protocol just seems more efficient. 

Regards,
Jason Todd Shannon

"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

Thanks for reporting your results!

I'm more inclined to think that VePro in particular simply does not work well with RDP..including the bandwidth issues..as I do not have any network or cpu problems or spikes or any problem at all when using RDP for non-VePro tasks.

I unilaterally find RDP much preferable over VNC.   But I have not been using VePro slaves other then occassionly for short periods of time..so...  

I do not think there is anything inherently flawed in RDP technology.  Apparantly VePro does not always play well with it, so the less efficient VNC protocol is perhaps more reilable in that case.

@Jason T. Shannon said:

, 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 was curious, so I moved my MirPro license over to my VePro slave to see what would happen.  Not good results, but will report here in case in helps VSL or anyone.

• Upgraded VePro from 7.0.954 to 7.0.973

• Launching VePro takes about 7 minutes to start up, without any plugin scanning, which is ridiculous.  Not sure what is going on there.  This happens regardless of whether I am using any remote desktop solution, or directly from the actual machine without remote desktop.  CPU showing near 0% the whole time.  Just very long wait, 7 minutes or so.

• When I try to connect to vePro instance from my mac with LogicPro, the vePro server does not show up on the list of available servers.  Typing in the IP address manually connects, but only to a new instance, it will not let me choose a pre-existing instance.

• With MirPro installed and activated, now I am getting the same error about local administrator account needed.  So that appears to be a MirPro issue of some kind.  Its kind of annoying.  This must be because MS Remote Desktop uses proper windows authentication, whereas VNC cheats around that.  Anyway, without MirPro, I don't get that.  All you have to do is disconnect from the remote machine and reconnect MS Remote Desktop, VePro appears to have some autoamtic stuff to start itself up that way and once you do that you can connect with remote desktiop and use it.  Annoying, but not a deal breaker.  I don't know why MirPro requires this step, but that appears to be a MirPro depencency, which is why I was not seeing it before.

• Attempting to create a channel with Synchron, immediately crashes VePro when done through MS Remote Desktop.  However, if I create the synchron channel using the slave machine's own monitor (without remote desktop), then once that has been done, I can connect with Remote Desktop and after that i can create many new channels of Synchron and pull up the MirPro screen and everything else, in fact I couldn't get it to crash again after that.  It seems to only happen when trying to click on the synchron button to create the first synchron channel in the instance, and also, this only happens if and when MirPro is installed.  Its not happening after uninstalling MirPro.   I don't expect this to help any users, because anyone using MirPro should probably just forget about using MS Remote Desktop for now unless VSL can figure it out.  But I am just passing this information along in case it helps VSL debug the problem.

So bottom line, MirPro in VePro doesn't play well with MS Remote Desktop, which is very unfortunate.  I really hate using VNC.  But at least in the near term I don't plan to buy another license for MirPro on any VePro slaves...so I can probably live with it still.  Also, the latest version of VePro appears to have something else funny going on in terms of taking forever to start up and not appearing on the list over on the mac when trying to connect to it. 

I don't have VNC stuff installed right now to easily compare, but I use a high resolution display and I expect VNC to be an absolute network hog dealing with that many pixels.  So for me personally I will continue using MS remote desktop without MirPro.  But if I needed to put MirPro here, I'm sure I could make VNC work, though I hope VSL will someday figure out that issue and get it working with RDP.  Its probably beause of the fact that it has to startup a seperate process or something, just speculating.

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

Thanks!

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

Here is another tip for VNC. If you need to force a specific resolution in your remote machine without fuss, you might find a Headless HDMI dongle a useful tool: https://tinyurl.com/y78j83f4

These are handy if you don't use a monitor on your remote, or if you want to force VNC to use a display resolution that doesn't match the one that you've got connected. 

Again, I got much better results with VNC once I matched up the display resolutions between the local/remote and changed the encoding on the VNC viewer to HEXTILE or ZRLE2. The bandwidth consumption here isn't terrible because it only sends screen/pixel updates. Should be very manageable for VEPro monitoring and control! 

I now have a VNC session that has survived without crashing on an open VNC session for 18 hours. New experience for me! 

JS

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.

In RealVNC Viewer, you can select from multiple monitors on the attached server, but I haven't tested it. My VEPro slave doesn't have a monitor attached, but I'm using the headless HDMI dongle and it is actually rendering this crazy 3,440 x 1,440 widescreen display resolution for my primary really well. If you get a dongle which has resolution capability to match your primary display, I'd think that would work with your second monitor still plugged in? I may have something I can test it with later. I will report back if I do. 

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.

Understood, and good luck! Please report back your experiences with RDP over time. I'm interesting in hearing how things progress. Hopefully all of this gets simplified over time. 

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?

Anydesk 2.6.1 is a game changer. Simple to setup. You will forget you are using remote into the system. Every studio I manage uses Anydesk for slave installations. Find the older version 2.6.1 if you don't want bloat. Works flawless. Crushes every other utility.