Apple Remote Desktop sure is slow.

Is there a way to tell OSX to stop throbbing the "OK" buttons on dialog boxes? I think that's what's slowing it down the most, as it spends all of its time slavishly updating those animations.
Tags: , , ,

21 Responses:

  1. badc0ffee says:

    If you're using 10.6 or earlier, try OSXvnc (Vine Server) in place of Screen Sharing. You can use it with lower color depths and that seems to improve the speed a lot.
    (I've only ever had success connecting to Screen Sharing with full 24-bit color).

  2. seminiferous says:

    Doubtful. But unless you need ARD specifically, try enabling VNC in Screen Sharing and use JollysFastVNC. I've found this combination to be faster than anything else, even over a crappy home broadband line.

  3. xrayspx says:

    I use the following script to use VNC over an ssh tunnel to my home machine, which has made Screen Sharing "mostly useful", I still wouldn't want to do a full day of work over it, since you can't dial back the quality/color depth, but I can log in and it's not entirely the most dog slow thing ever. Couple things, I use the following applescript to hide the Terminal window that pops up when you run the script. It hides all terminal.apps, but like most civilized people, I use iTerm, so this isn't a problem:

    tell application "Finder"
    set visible of process "Terminal" to false
    end tell

    You do need the sleep that's in there, for whatever reason, you can't set up the ssh tunnel and then immediately use it. This is OK, since it gives time to enter my keychain password anyway if it's my first boot. I got the .inetloc by putting vnc:// in a Safari URL bar and dragging it to the desktop. The ssh -c flags should be the fastest (weakest) crypto.

    All the other stuff is just to make absolutely sure all the processes are cleaned up at exit, and if I run two copies or if it hangs or something, kill the old one and continue. I'm sure it could be de-uglified considerably, but the ssh compression really does seem to help:

    #! /bin/bash

    osascript ~/Documents/hidefinder.scpt

    for pid in `ps -A | grep\:5900 | grep my.dyndns.fqdn | awk '{print $1}'`
    kill $pid
    ssh -c arcfour,blowfish-cbc -N -L 5904: myuser@my.dyndns.fqdn &

    sshpid=`jobs -p`
    # echo "SSH is: $sshpid"
    shellpid=`echo $$`
    # echo "Shell is: $shellpid"
    sleep 10

    arch -i386 /System/Library/CoreServices/Screen\\ Sharing /Users/myuser/Documents/RDC\ Connections/msrdp/.vnc--

    kill $sshpid
    kill $shellpid

    • xrayspx says:

      Oh, and when running Screen directly you really do need to set arch -i386. I can't even remember anymore what screws up when it's running in 64-bit, but it isn't pretty, and I'm unfortunately not in a position to try it out.

      • brainfire says:

        64-bit screen sharing gives you a blank display a lot, in my experience. That might be what you're thinking of.

    • jwz says:

      Aside from the "arch -i386" bit, isn't this the same as A) setting up the ssh tunnel, and B) selecting "Go / Connect to Server" from Finder and entering "vnc://localhost:5904" as the URL?

      Also you can probably accomplish the -i386 part by doing Get Info on "" and selecting "Open in 32-bit mode".

      • xrayspx says:

        Yeah pretty much. The main thrust was "tweak the crypto settings, gain some speed", and have compression on. If the connection method you're moving from is "have port 5900 open on your firewall and permit traffic from those locations you want to VNC from", this should be a bit faster. If you're already using ssh tunneling, it won't matter much. I really wish they'd just let us choose color depth, this all works great with Linux at 8-bit color.

        The point of scripting it all is so I only have to do one thing, rather than set up a tunnel, then go and run Screen Sharing or click the .inetloc or whatever.

        • Michael says:

          Chicken, and its sort-of still developed ancestor Chicken of the VNC, is a VNC client that permits selection of color depth in its Profile Manager (as I recall all VNC clients should).

          Since Chicken does not speak Apple's Remote Desktop protocol it needs VNC preparations on the server side, under System Preferences, Sharing, Computer Settings…. The usual warnings about VNC's weak authentication etc. applies. Normally you want to restrict the VNC port to listen on localhost only, to be connected to via ssh tunnel. I do not know if the ARD daemon does that. Perhaps the Firewall can help.

          A standalone VNC server is Vine Server (4.0 Beta updated for Lion), formerly OSXvnc (ancient, 3rd-party downloads only).

          All said, while I did use VNC extensively in the past I found Screen Sharing much less of a hassle to set up, maintain, and use daily.

          • badc0ffee says:

            A Lion update for OSXvnc is in the works. (The website also calls it Vine Server, and I'm not sure what the relation is - is OSXvnc the open-source version of Vine Server?)

        • Michael says:

          BTW, to script opening a Screen Sharing or VNC connection, you do not want to muck with absolute paths but rather do this:
          open vnc://localhost:$someport/

          • xrayspx says:

            Should this be happening in Applescript? I can't see how to pass a URL to Screen from the shell. If Screen Sharing is launched from Applescript, presumably it respects the 32-bit mode setting in the Get Info pane of the app? This would be pretty swell, since it would be much easier to just pass it host/port as variables rather than have a separate .inetloc / .vncloc for each.

            • Michael says:

              That's shell syntax, though I am sure one can loquaciously convince AppleScript to do the same thing.

              Open will not honor arch but I think the need for 32bit in your setup is an indication of something else being awry.

    • Michael says:

      While I'm at it, let me put on a beard and some suspenders. … Here we go.

      Young man, it's not so much the terminal app that counts but rather what one types into it.

      – "grep | grep | awk" is not how one goes about ANDing regexes. That's right up there with the "useless use of cat (UUOC)".

      – If you really want to go on a killing spree, use more than one pid. Hence, e.g.:
      awk '/regex1/ && /regex2/ {print $whatever}' | xargs kill

      … not to mention lsof(8) or killall(1).

      – To kill the last descendant, one sets a trap on exit, something like this:

      trap '{ kill -HUP $!; sleep 1; kill -0 $! && kill -KILL $!; } 2> /dev/null' EXIT

      Single quotes are intentional. Add or remove seasonings to taste.

      Share and enjoy.

  4. Michael says:

    TinkerTool does not offer it but bears watching. It keeps reasonably pace with known plist hacks. E.g., when Lion came out, there was a great deal of angst about the ubiquitous window opening animations. Promptly, TT now offers a setting for that.

    I am pretty sure that ramping up compression or using VNC has occurred to jwz. In any case, the respondents above who swear by VNC may not realize that Apple's ARD is a notch up from OS X's built-in ScreenSharing. It supports lossy compression (as does Screen Sharing) but also dialing down color depth. There was a hack in Leopard to enable the color depth toolbar item but that ceased to work in Snow Leopard.

    • jwz says:

      Actually I don't know how to adjust compression on VNC (aside from adjusting the ssh tunnel itself) since I just use Screen via Finder, and it has no useful preferences. I use this infrequently enough that I've never really dug into it very far.

      • Michael says:

        Screen Sharing has menu entries View, Adaptive Quality and Full Quality; nothing about color depth, though. Adaptive is what I normally use over some 16+ Mbit/s down, 4 Mbit/s up, and that's good enough - I figured I don't need to get into the hassles of using a VNC server, client, or both.

        Here's some bandwidth usage data which may surprise you.

        I'm using Screen Sharing on a 27-inch iMac, connecting to a 30" Cinema display (2560 x 1600), Lion on both sides. Numbers in kB/s (kilobytes, as reported by Activity Monitor), eyeball-rounded to nearest 10 kB/s.

        – Baseline: 0 down, 0 up

        – Scaling ON, ADAPTIVE Quality:
        Static screen: 5 down, 3 up
        "Go" button in focus and throbbing: 190 down, 130 up
        "Go" button out of focus: same as static

        – Scaling ON, FULL Quality:
        Static screen: 2 down, 1.5 up
        "Go" button in focus and throbbing: 130 down, 90 up

        – Scaling OFF, ADAPTIVE Quality:
        Static screen: 5 down, 3 up
        "Go" button in focus and throbbing: 170 down, 120 up

        – Scaling OFF, FULL Quality:
        Static screen: 2 down, 1.5 up
        "Go" button in focus and throbbing: 130 down, 90 up


        (1) Scaling does not change what goes over the wire (as expected).

        (2) For the specific problem posed, a throbbing Aqua button on an otherwise staid window, Screen Sharing with Full Quality reduces bandwidth over Adaptive Quality by 33%.

        (3) Yanking focus from the application that produced the button stops throbbing and minimizes bandwidth to sustainment level.

        Not considered: influence of a bouncing dock icon.

        There you have it.

  5. Michael says:

    PS: forgot to mention - to bring up a throbbing Aqua button I used the Go To... dialog in Finder (Shift-Command-K).