trouble with subliminal presentation times

[I][edited by moderator][/I]
i have just completed running an experiment that involves subliminal priming. when reviewing the log files i found that, for about 30% of the participants, some stimuli were presented for more then 10 times the requested time. i am attaching the log file of one such particpant. as the file shows, most of the time dRT did present the stimuli for the requested time (35ms), but sometimes (unexpectedly) for 200ms and even 400ms. i have no idea if ps were aware of these presentation when the occured as i debrief them only 40min later. do you have other reports of this phenomenon?

Those are some very strange data, I have never seen anything like that. Here is what I can tell you..

First thread to check out is here:

[URL]http://www.empirisoft.com/support/showthread.php?t=55[/URL]

Also see the trouble shooting section in the guide. In particular the section titled: [I]System or Software Trouble[/I], following the advice regarding narrowing down any potential correlates--e.g., certain computers, different versions of DirectRT, etc. Also, check out the bit about sending us a dxdiag.txt file from one of your machines. The section is also online here:

[URL]http://www.empirisoft.com/directrt/help/directrt_troubleshooting.htm[/URL]

With that said.. In looking at your data file, my guess is that you have some system event happening occasionally [I]outside[/I] of DirectRT that is limiting the processing capacity of other programs. If you sort your trials by the "Order" column, it looks like these trials are occurring in clusters. Of course, I'm look at just one file so maybe validate this with your other files.

If this is the case, the first thing I would look into is what else you have running on your systems at the same time. There can be a lot of stuff running that is not immediately apparent. Do you have an IT person there who can help you track down the other processes that are running during your sessions?

I would also look at disconnecting from the network during sessions. I have heard of this causes momentary interruptions in processing capacity.

See also: [URL="http://www.empirisoft.com/Support/showthread.php?t=70"]www.empirisoft.com/Support/showthread.php?t=70[/URL]

Most of all, I would highly recommend to always look at log files of test sessions before running actual subjects. Remember that DirectRT can not handle any given set of presentation times just because it's told to do so. A number of factors can have an impact on timing, and the log files are there to show you whether or not you can get what you want on the computers you have.

Also, just curious, what version of DirectRT is running on these machines and are these the same machines you had the previous graphics issues with (see [URL="http://www.empirisoft.com/Support/showthread.php?t=600"]www.empirisoft.com/Support/showthread.php?t=600[/URL])?

We have tested the log files beforehand. The problem isn't that our system cannot produce the requested presentation times - it can. The problem is that it does so irregularly (~30% of the participants have off times). We have now obtained the same pattern from a number of experiments, computers and labs. Debugging the program would require hours of monitoring in order to exclude the multiple programs which could interfere with dRT. What do you suggest?
Sincerally,
Baruch, Maxim & Daniella

I would just start with excluding [I]all[/I] other programs and see if that makes a difference. If not, then there is no point taking hours to isolate one program or another. Here is a link to a freeware (donation optional) utility that you can use to prevent any or all activity during startup:

[URL="http://www.empirisoft.com/support/showthread.php?p=2124"]www.empirisoft.com/support/showthread.php?p=2124[/URL]

My best guess is that this is an interaction between your particular computer setup there and DirectRT. This is what I was trying to get to in referring you to the trouble shooting section of the user's guide, but I'll try to be more explicit here. Let's try some basic causal attribution:
[LIST][*]Do you have [I]any[/I] machines that do not show this behaviour at all or does [I]every one[/I] do this at least occasionally? This is a very important question to answer because we can then look to the differences between machines for potential causes of the issue.[*]Is there anything about the lab situation that the problem sessions have in common--e.g., time of day, day of the week, experimental conditions, experimenters, etc. Did it start happening around a certain date or has it been happening ever since your origional testing and first subjects? These questions would require some investigative work looking at file dates and times.[*]If you disconnect from the network, can you produce these same results? If not, that would imply that the computers are fine and that there is some network interference at work.[*]If you do not load [I]any other software[/I] or start [I]any other processes[/I] aside from DirectRT, can you produce the problem? That would point the finger toward competing processes within the same computer.[*]If you run the session in another lab or on a home computer can you produce this problem?[*]If you sort log data file by the Order column, do the times in fact occur at predictable times and/or in clusters? If so, are the clusters spaced in time in some predictable way?[*]Finally, I don't think I ever saw your style file--what resolution are you running your sessions in (as defined under [I]Options[/I] in the style file)?[/LIST]OK, that's it. This is by no means an exhaustive list of things to check. It's just supposed to illustrate the kinds of things you might think about in the process of trying to figure out what's going on.

Please remember that what you are looking for here is probably not a bug in the software. It is possible for other programs or processes to demand all of your system's processing resources. In such cases, whether it's for 1ms or 1000ms, then DirectRT may not be able to operate during those moments. If that ever occurs, then all DirectRT can do is tell you about in the log file--and you can always count on it to do so.

In fact, I'm curious about one thing. You mention that this happens frequently and on most machines and most experiments.. but that you also test the sessions ahead of time and look at the log files. Are you saying that this never happened during the test sessions and happened only when running actual participants? If so, that would be very useful to know.