[visionegg] time and OS es

Dear list members,
In investigating time and operating systems one might wish to look at some papers by Joe MacInnes that appeared in BRMIC not too long ago. He does some operating system timings using a method similar to that published on this mailing list.

I am currently writing to address some "chicken little" style concerns about losing many milliseconds of CPU time from your process. First, if you really want to investigate the potential impact of this issue then attempt to store, and then write out, what is happening in every single millisecond of an experiment. You can really get at what the issue means for your experiment. For an hour experiment and 100 bytes /msec that's still only about 6 meg – nothing these days, really.
Some people pine for the old days in System 6 and DOS where you never lost milliseconds to something else because nothing else was going on. Or, perhaps Posner's lab in the late 60's where a single computer could run a half dozen experiments in a high level language with perfect timing (anyone know where the code for THAT is?). But I am here to tell you things are probably not all that bad these days.
During an experiment a typical trial lasts about 2 seconds. I'm going to describe a worst case scenario for today's computer in a typical situation. Sometimes in that 2 seconds one does a lot of things. Perhaps for half of it one might be updating the screen on every single refresh with something new. Given a very fast monitor that is 200 critical milliseconds. Then, one needs to get a response out of that. Sometimes it is continuously monitored. In that case you may need another 2-400 critical milliseconds. In the run of a given trial there will be about 600 critical milliseconds. For experiments like that modern computers can often be problematic. You need to be able to guarantee relatively large chunks of time (note -I've found the RT services in OS X pretty good for this).
But, what about more generic experiments where there is one response and about half a dozen presentations at most on a trial. In that case the critical milliseconds might be 7. Or, even a perception experiment where the critical milliseconds might only be about 200 (10%) because a speeded response isn't even required.
Now let's go back and look at the data used to suggest that Linux isn't very good for running experiments. One of the typical methods is to let a program run in a loop for several minutes monitoring every single millisecond and recording when it loses some. Worst case scenario in that situation on a standard Linux install will be something like 100 msec. Maybe it might even be close to 200 msec. If you look through the data at how often this happens (just based on things like the timing in VisionEgg) you'll notice that it is very infrequent.
What has not been done by anyone testing these issues, and what really needs to be published, is a paper on the odds of actually losing a critical millisecond. I suggest, based on casual observation that, A: it is very rare, B: it only adds a small amount of variance, and C: even if it does occur it is catchable through the same method as used to verify the machine timing.
I don't have any solid answers here but I hope that as you think about these issues you realize that an absolute statement about timing is hard to come to and that you can probably have pretty crappy CPU availability in some kinds of studies and still have generally great timing.

John Christie
=====================================The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: