Millisecond Forums

P.S. If you are still seeing the delays, it would be interesting to know whether any of the following steps cumulatively have an impact:

1) Removing all data and audit recording (you've already done this)
2) Remove the ontrialend logic and the text stimuli showing the debug info from the
3) Remove the shape stimuli from the presentation

Thanks for the reply, Sean. Really weird. I can reproduce these delays reliably, though.

Yes, that's what I'm talking about. The mean difference to be precise. In the test script, "Difference" reflects the duration of the last trial (measured as difference between the previous and current trial's start time), "Mean" reflects the mean duration across all trials.

Thanks,

~Dave

Ah, that might explain the discrepancy. The mean difference includes "start_trial", which does not have a fixed length (it's length depends on how quickly you respond). The performance in question is the duration of the fixed length trials, so the mean difference isn't relevant.

I've been opening the data file and looking at the reported difference for each fixed length trial, and all the durations have fallen within the range of 1000-1001. Are you seeing any single trial durations outside this range?

-Sean

No. My script corrects for that.

More weird - did you update the test script? I just downloaded it again, and the calculations were different than the script I previous had. The version I have now does indeed correct for the start_trial.

I'm still not seeing any delays larger than 1ms, however. I'll try on some more machines...

-Sean

I might have initially uploaded the wrong version -- however said version can't have been online for more than a couple of minutes... Sorry for the confusion.

~Dave

Dear Dave/Sean,

Many thanks once again for the extensive testing and many helpful comments you guys have provided on this topic - really, really helpful. I'm very happy to report that including a post-trial pause, setting erase=false for all my stimuli, and updating to the latest build of Inquisit have pretty much solved the problem I was having - Dave's debugging timing code reports trial durations which are pretty much bang-on, with an occasional deviation by a millisecond or two. Testing with external hardware (getting Inquisit to output a TTL pulse on the parallel port with each trial and recording it with a analogue-digital converter with 1ms resolution) confirms that the timing is accurate as well. This is a massive improvement over the situation I was in before and I'm re-commencing my experiments with renewed confidence in what I'm doing. 

Interestingly, the above is only true on the computer I use for testing - when I run the programs on the computer in my office (similar specifications) I still see timing lags. Nevertheless, at least with Dave's debugging code I can be certain about what's going on whatever hardware I use in the future.

I have a suggestion actually - it would have been immensely helpful to me if the timing code had been easily available somewhere. I've been using Inquisit for a while but am in no way a 'proper' programmer and had no idea Inquisit could be used in this way, and even less idea how to implement those functions. Would it perhaps be possible to include an example script similar to Dave's in the Inquisit Task Library on the main website?

Many, many thanks again,

Matt.

Request for clarification, if I may: This is to say that on your office PC

(a) the debugging script does not report timing lags although there are such lags (as measured via external equipment / TTL)?

or

(b) the debugging script does accurately report timing lags despite the various optimizations (postrialpause, erase=false, etc)?

Thanks,

~Dave

Dave,

Sorry for being unclear - what I meant was b), i.e. the debugging script is showing lags of about 30ms on each trial, despite all the optimisations.

Cheers,

M.

Ok, I've dug more deeply into this, and identified the cause of the extra lags. Basically, the lags are equal to two retrace intervals of the monitors (as Dave had earlier surmised).

The first interval is because when Inquisit prepares to write the stimuli to the screen, it stalls until the beginning of a retrace interval. This can take up to 1 interval in duration and is currently added to the total duration of the trial, assuming no postrialpause is set.

The 2nd interval lag was simply a bug as Inquisit mistakenly waited until the next interval began before advancing.

Both of these lags were consumed into the posttrialpause, so they wouldn't affect timing if that command is set. I will hopefully have a fix ready for both shortly.

-Sean