VNC and Superlab

[gshenaut]

Well, we are about to start our first "real" SuperLab experiment next week. In our lab, there are three testing stations, and for this study, we want to test three subjects at a time. Each station is based on a MacBook Pro. It occurred to me that rather than have the experimenter or the subjects wandering around starting and stopping experiments and blocks using the keyboard of the macbooks, we do it using Chicken of the VNC from the iMac on the exerimenter's desk. This would also allow the experimenter to monitor the status of each subject's screen in a separate window while the experiment is running, again without disturbing the subject.

I have done only enough testing to verify that I can use COTVNC on one machine to control a SuperLab experiment on another one, and that it is convenient to do so. SuperLab even accepts keystrokes as subject input over VNC. The only negative is that COTVNC apparently can't reduce the size of the screen, so at any given moment, a COTVNC window can only show a portion of the full display on the subject machines.

My concern is that it will add so much overhead to the macbook that the timing will degrade. Based on appearances, it doesn't seem to change the timing.

It is possible to reduce the screen auto-refresh frequency to a minimum. That might help with the timing, but it makes the interface somewhat harder to use.

Our experiment uses only text strings as stimuli and USB keyboard input as responses, with no multimedia.

It might be possible to get Apple's remote desktop program instead of COTVNC if that made a signficant difference in the timing accuracy.

What is the official Cedrus position on this: To VNC or not to VNC?

Greg Shenaut

[Hank]

That is the question.

Believe it or not, I use Chicken of the VNC here too. :D I have not done extensive testing of how it affects timing, as I use it for debugging purposes. I work on an Intel Mac and use it to control a PowerPC Mac mini to verify that everything is still Kosher on the older Macs. My educated (but by no means definitive) opinion at this point is that neither VNC nor ARD will affect the SuperLab timing for the person sitting at the machine. There is a rather obvious delay for the person controlling the machine over the remote connection, however.

My reasoning is as follows:

1) While running an experiment, SuperLab on OS X runs with real-time priority. It gets processor time pretty darn close to when it wants it. If any timing is affected, it will be SuperLab affecting VNC, not the other way around. (by "pretty darn close," I mean that it's virtually always within 500µs.)

2) Due to no. 1, SuperLab on OS X plays somewhat nice. It gives up tiny little slices of processor time when it doesn't need it. Whatever VNC needs will run during these slices. Again, due to no. 1, SuperLab will be returned control when SuperLab requested, regardless of whether or not VNC is done.

3) You're running on a MacBook Pro. This machine has two processor cores. SuperLab could take literally 100% of one of the cores and you would never notice. ;) If this were to happen on a single core or single processor machine, you would notice (the mouse would stop moving). If VNC needs time and SuperLab is busy, VNC will be given time on a different core.


Believe it or not, I have iTunes playing music in the background most of the time, and that doesn't even appear to affect SuperLab's timing.


caveat: The above does not apply to the Windows version of SuperLab. Windows XP and Mac OS X are completely different OSes, each with its own set of quirks. This just happens to be one of OS X's strong areas relative to Windows XP.

[gshenaut]

That's pretty cool. Well, then, I'm going to try it on this first experiment: three SuperLab experiments, each being controlled via VNC from a single machine. I'll let you know if we had any problems.

Greg