Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Best Remote Pairing Settings

I am a remote employee at Pivotal, so I do a lot of remote pairing, and I’m always trying new options. Here’s a quick writeup on what I’ve found to work best.

This is specifically for working over a WAN. If you are on a LAN, other options will be better (and you should just get on the same machine as your pair anyway!). Remote pairing is pretty usable unless bandwidth is causing problems. CPU also makes a big difference – performance on an iMac is a lot better than on a Mac mini, especially the 1.6Mhz mini. I’m using the term “server” to mean the machine running the VNC server, and “client” to mean the machine running the VNC client.

Mac Server:

OSXVNC (Vine Server) with default settings. Turn on shared VNC connections if you want.

Windows server:

UltraVNC with the Video Driver Hook seems to work best; it’s almost as fast as Windows Remote Desktop, but it requires that you use the UltraVNC client, which is only available for Windows. However, sometimes you get screen redraw issues with the video driver hook. This seems to be due to network or CPU issues, because it works great most of the time on most machines. If this happens, you can fall back to the Tight protocol on the client.

The “WinVNC Current User Properties” I use for the UltraVNC server are:

  • Poll Full Screen (Ultra Fast)
  • Poll Foreground Window
  • Poll Windows Under Cursor
  • System Hook DLL
  • Video Hook Driver
  • Low Accuracy (Turbo Speed)
  • DON’T CHECK Poll Console Windows Only
  • DON’T CHECK Poll on Event Only

Windows Client for server with a single monitor:

If you are using the UltraVNC windows server with the video driver hook, then you should use the UltraVNC client, with the “Ultra” encoding and 256 colors, with CopyRect and Cache encoding enabled.

If you are not using the UltraVNC video hook on your server, then UltraVNC is still a good client, with these settings:

  • Tight Encoding
  • 256 colors (less colors don’t seem to help that much)
  • Use CopyRect Encoding
  • Use Cache Encoding
  • Zip/Tight Compression enabled, set to 9
  • Jpeg (Tight) Quality, set to 1
  • Track Remote Cursor Locally
  • Viewer Scale (whatever works for you)

Windows Client for a server with a dual monitor and a client with a dual monitor:

UltraVNC client has a bug where it scales, but will still not show any more width than one of the client’s monitors, even though you make the window bigger. RealVNC does not have this problem, so it’s probably a better client in this situation, even though it doesn’t allow configuration of all the above options like UltraVNC does (at least not from the GUI).

Mac Client:

  • Chicken of the VNC is OK, but it doesn’t do scaling, and doesn’t allow you to specify ports via the double-colon syntax (only displays, which means you have to do math if you are ssh tunneling)
  • Free RealVNC is OK, but it doesn’t do scaling
  • Enterprise RealVNC does scaling
  • There are several other mac clients such as VNCThing and VNCDimension, but they don’t work on my mac for some reason, and don’t seem to have any more features than Chicken of the VNC or RealVNC.

Linux server and client:

I’ve not been too impressed with the VNC linux servers or clients. They seem to be slow and crash a lot (both RealVNC and TightVNC). Your mileage may vary.

Alternatives I’ve tried and found to be inferior:

  • The built in VNC server in OSX (slow and unconfigurable)
  • Apple Remote Desktop (which is really just VNC too, and just as slow and unconfigurable)
  • Timbuktu Pro (no faster than VNC, and had refresh issues)
  • NoMachine NX (server only runs on Linux. It’s a great option if you are connecting to Linux)
  • Windows Remote Desktop/rdesktop (logs off server GUI, so unusable for remote pairing)

Other Notes:

I’ve read that running VNC over a compressed SSH tunnel will help performance. However, I think with the latest VNC protocols, which already do compression, this doens’t make much of a difference.


Most of these observations are from running different clients side-by-side. They are very subjective, because bandwidth and CPU are always affecting the performance. Let me know what your experiences are, and if you have any different ideas.

  1. David Goudreau says:

    Excellent. Thanks for saving the rest of us all that legwork. Now, do you have any insight into what the best iChat/Skype/audio/video software is to use with your pair?

  2. Chad Woolley says:

    Dave said:

    Now, do you have any insight into what the best
    iChat/Skype/audio/video software is to use with your pair?

    Just for you Dave, I wrote a separate post on this topic:

  3. Nathan Sobo says:

    At the top of the feature list for my editor is the facility to share buffers remotely with support for multiple insertion points. If it runs system shells as inferior processes inside of these buffers, then the only thing that can’t be looked at in parallel is the web browser. But if the remote pair just points his own web browser at the development server then that almost doesn’t matter.

  4. Chad Woolley says:

    Nathan, if you wrote an editor like that with multiple buffers and multiple insertion points, I’d name my first-born son after you. Wait, I already have my first-born son. Well, I’d do something really nice for you anyway :)

    — Chad

  5. Alex Chaffee says:

    Just apply the “Rename Subclass” refactoring :-)

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *