Skip to main content

Live Fast, Crash Hard


Over the last few months, my friends and I are starting to find there's something very wrong in the state of Mac remote clients. I don't have a huge number of computers, but I have enough to make the use of VNC (the free screen-sharing system originally developed by Olivetti Labs at Cambridge) necessary. I used to have a mix of Macs and Windows systems, so some years ago I settled on VNC as the lowest common denominator method of connecting to one machine from another. VNC server runs as a native service on Windows, and there are mainstream clients which work well. On the Mac, it used to be that the canonical server was OSXvnc, now incorporated into Redstone's vine server. For a VNC viewer I used Chicken of the VNC. Chicken has a reputation for being very slow but very stable and my experience certainly bore this out.

Then came OS X 10.4 (Tiger) which exposed the Apple Remote Desktop (ARD) screen sharing service in the Sharing preference pane. ARD uses another version of the VNC code-base. I happily used this on the server end while continuing to use Chicken as a client. A while ago I started using Jolly's Fast VNC because it promised faster, snappier response from the far end. The promises were true, but I began to find that after a few minutes of using the Jolly Screen Client, the session would freeze. Restarting the client made no difference, nor did:

  • Stopping and starting the Apple Remote Desktop client on the server
  • Disabling and re-enabling the ethernet interface on the server
  • Unplugging and replugging the Cat5 cable on the server

Not only did it kill the workings of remote desktop access, it killed every ethernet service on the server too. It wasn't talking to the VNC client, but neither was it talking to any other IP host - by name or by IP address. Nor could I renew the server's DHCP-granted IP address, a process that uses broadcast IP datagrams. I couldn't even see the server's MAC address in a client's ARP table, showing that the whole ethernet infrastructure was dead in the water. The only thing that brought my Trappist server back to life was a complete restart. I never go to the bottom of the problem so I just gave up on Jolly's and went back to Chicken and the problems went away. Then came Leopard.

You probably know that Mac OS X 10.5 "Leopard" has a slick, Apple-written Screen Sharing app. When I upgraded most of my machines to Leopard, I got rid of my third party VNC solutions. I was happy for a good long time controlling my Mac Mini (our media machine) from my MacBook Pro, both running Leopard. Connection times were fast and performance was snappy. Then the same lockups started. I'd be using Screen Sharing over Bonjour (mDNS) to control iTunes and the screen would lock up, and network traffic on the Mini would fall to zero in both directions. As when I was using Jolly's a complete reboot of the server system was the only thing that cured the problem.

I can't find any reliable information on whether the Apple client uses the same codebase as the Jolly's client, but it's very odd that both clients offer identically brisk performance and have identically disastrous effects on the server machine. I hope the upcoming OS X 10.5.2 update brings a fix to this issue along with the many others it offers.

Technorati Tags: , , , , , , , ,

Comments

Post a Comment

Popular posts from this blog

Alien User Interface Hell

I tend to like a movie to be playing while I'm working, preferably one I know well so I can ignore it. Today Alien was up on Netflix Instant. While going to make more tea I noticed the early scene where the Nostromo 's captain goes into the command area to commune with Mother. What the hell were the designers thinking when concocting the fake system user interface that is depicted in that scene? There's a million tiny status lights , all white, set into a white background. None of them has a readable label. The whole surface of the pod is encrusted with incomprehensible but significant miniature beacons. It's been frequently pointed out that some errors on our limited space missions so far have been tied back to ambiguous or confusing information displays in spacecraft cockpits. What evolutions did Ridley Scott expect to have happened in a few decades that would allow a standard human pilot to instantly discriminate one white light from ten thousand others and act on ...
1 comment
Read more

Calendar confusion

I finally got around to posting this as an error in iTunes: When calendars are synced between iCal and iPhone via iTunes, iTunes assigns arbitrary colors to the calendars on iPhone. These colors cannot be changed, and do not match the colors chosen in iCal. On occasion, iTunes will assign two calendars the same arbitrarily-chosen color, making them functionally indistinguishable on iPhone. This is terrible user interface design because users become accustomed to the 'meaning' of the color of the calendar and use it in recognition of the calendar layout. The mental 'wrench' involved in translating color recognition between two instances of the same calendar data imposes a unnecessary cognitive load on the user. Solution Allow the user to set the color of iPhone calendars. If the intention is not to allow the user control of the calendar color, for simplicity of implementation on iPhone, then the logical solution is to use the same color as specified in iCal. If the syn...
Post a Comment
Read more