Millisecond Forums

Hi Sean,

many thanks for giving this another look and your detailed response. Here are my observations as requested:

(1) / audit = true had nothing to do with my initial observation. In fact I never even ran the script with auditing turned on.

(2) / separatefiles = true doesn't resolve the issue for me. In fact it makes the delay even worse (~45ms mean).

Thanks again,

~Dave

P.S.: Can you replicate the empty stimulusonset property issue?

I've tested the script with /postrialpause=0 and am seeing intermittent delays between 30-34 ms.

Any resemblance these numbers have to the refresh rate is purely coincidental given that there is no stimulus erasure happening with your test script. At the end of the trial, Inquisit does a few things, including:

1) Captures the screen and saves it to disk (if applicable)
2) Erase stimuli and show feedback stimuli (if applicable)
3) Update stats for the expt, block, and trial
4) Evaluates any /ontrialend expressions
5) Writes trial data to the file
6) Erases any feedback stimuli (if applicable)
7) Releases any video memory used by shapes or pictures (if applicable)
8) Clear any pending input messages from the relevant response buffer

The only item in this list that could possibly require 30ms is 5 - writing the data to disk. Sure enough, when I removed the /audit command from the <data> element and replaced it with /separatefiles=true (which causes Inquisit to save the data in memory and then write it all at once to disk at the end of the experiment), the 30ms delay goes away. I'd love to know if you see the same thing.

Anyway, I think we have our culprit - disk access.

-Sean

Sorry to keep dragging this on, but I'd like to point out that all stims in the testscript are set to '/erase=false', i.e. Inquisit shouldn't have to erase anything ever. The only thing remaining is the "other minor cleanup" (resetting trial properties and such, I assume). And yet -- with posttrialpause=0 -- approx. 2 additional frames are added to each trial. Granted, I'd also expect some (very) small delays for the minor cleanup, but I don't see why this should take 2 frames (~34 ms) because there is no screen / display erasing involved whatsoever. Considering the sheer number of processor and memory operations modern PCs can perform within microseconds, I'd expect the minor cleanup to be virtually undetectable. I definitely don't understand why it adds 2 frames (even one frame would be too much, IMO). Any input is greatly appreciated!

~Dave

P.S.: As mentioned previously, I think there may be a bug involving the 'stimulusonset' property: 'shape.myshape.stimulusonset.1' always returns an empty value on my system (Inquisit 3.0.5.0), despite the stimulus having been displayed and thus having an onset to report.

A little more info on the timing optimization - there were circumstances in which Inquisit would resynchronize with the vertical retrace rate more than one time while erasing stimuli - i.e., it would wait for the paint cycle to start, erase a stimulus, then wait for the next paint cycle to start, erase the next stimulus, etc. The fix ensure that it would only wait for 1 paint cycle before erasing all stimuli (which means there still may be a delay between trials, but it will usually smaller than before).

A posttrialpause gives Inquisit a fixed time buffer after the trial to erase stimuli and do some other minor cleanup. With a posttrialpause defined, you shouldn't see any delay from erasing stimuli. Without the posttrialpause, I would expect to see some small delays.

As for pretrialpause, that should not affect the overall length of a trial who's trialduration is set to a fixed value. However, it could push stimulus presentation back if preparing the stimuli requires some time. In most cases, we're talking a few milliseconds to prepare a stimulus, but it could become significant on a slow machine with lots of stimuli.

Hope this clarifies things.

-Sean

Oh, btw, while coming up with the time auditing bits for the test script I also briefly experimented with the stimulusonset property (e.g. '/ ontrialend = values.myonset = shape.green_circle.stimulusonset.1'). However, the returned value always appeared to be empty. Any hint?

Thanks,

~Dave

Interesting info, thanks. However, things go seriously kerfuffle on my system if I set the posttrialpause to be zero. Seems like Inquisit needs at least two frames for cleanup at the end of any given trial. So there might be room for further improvement. What happens on your systems when you run the test script with posttrialpause = 0?

LOL.

~Dave

Yes, since that old build, I added some optimizations in the way that Inquisit synchronizes with the refresh cycle to erase stimuli, as I recall. The previous behavior could insert some time in between trials.

-Sean

That's because it's still a little rough around the edges and somewhat incomplete. Besides, secret features add a sense of mystery to a product. [H]

-Sean

Hmm, looking at the data file you posted there's something fishy going on with respect to the posttrialpause column. Only the first trial reports a value of 100 (~6 frames), the remaining trials report 0. According to my tests, the posttrialpause matters as Inquisit apparently needs some refractory period to do some memory cleanup at the end of a given trial. I believe that's where your additional frames creep in. Which exact build / version of Inquisit are you running?

~Dave

EDIT: I see you're running 3.0.2.0. You should definitely update to 3.0.4.0 or 3.0.5.0 (beta). You're probably hitting a bug that was fixed ages ago.

Matt,

definitely sounds like an issue with your specific hardware to me. Some monitors introduce consistent lags by one frame (see Plant & Turner (2009) for an example; http://brm.psychonomic-journals.org/content/41/3/598.abstract). Or it may be a graphics card / driver issue. Anyhoo, here's what you can do to troubleshoot furher:

(1) Check and update your graphics card drivers.

(2) Connect a different monitor to your system.

(3) Run the timing tests on a completely different system for control purposes.

~Dave