[solved] Recorded Timings.

booradley

Hi Sebastiaan,

In my data files for an experiment (which I will send you via DropBox) OpenSesame appears to be recording 'phantom timings', that is to say, it is recording the presentation time of stimuli that have not been called.

I've checked the presentations by holding every sketchpad used to the screen with duration of 'keypress' and made sure everything is as it should be. However, there is still timings for stimuli being recorded under conditions where that stimuli is not presented.

This is very odd and a little worrying.

Do you have any idea what is happening here? The relevant file is called APSB10 in DropBox and row 9 shows an example of what I mean quite clearly; if you search 'time_BothCircles' you will see timings next to it that simply don't belong there.

Also is it safe to say that the correct way to calculate the actual length of time a stimulus is held to the screen is to minus it's presentation time from the very next stimulus to be displayed?

I've included a read_me file with a little bit of clarification on stimuli.

Thanks,

Boo.

EDIT: I've consulted with technicians this end regarding an additional issue. When it comes to timing accuracy (when using a 60Hz CRT monitor) when we instruct OpenSesame to display for 33.2ms (we tell it to display at 30ms since telling it to display at 33 results in 47-50ms) the recorded timing in closer to 37ms. This issue does not appear to exist on LCD monitors (also 60Hz but on a different computer) where the timing is usually exact or only out by 1ms.

I've included a file showing accurate timings when on LCD in the shared folder.

Do you have any suggestions why this may be the case? Gary, our technician here, suggests it may be a problem with differing graphics cards.

Boo.

lvanderlinden

ITA

We will come back to you as soon as possible.

sebastiaan

Hi Boo,

In my data files for an experiment (which I will send you via DropBox) OpenSesame appears to be recording 'phantom timings', that is to say, it is recording the presentation time of stimuli that have not been called.

The time_[item name] variables always contain the timestamp of the last time that an item was called, or in the case of a sketchpad, the last time that the sketchpad was presented. So if a sketchpad is not presented on a trial, it's time_[item name] variable will not be changed, but it will also not be unset. It will simply still have the same value as it had on the previous trial: Does this answer your question?

Also is it safe to say that the correct way to calculate the actual length of time a stimulus is held to the screen is to minus it's presentation time from the very next stimulus to be displayed?

Yes, it is!

EDIT: I've consulted with technicians this end regarding an additional issue. When it comes to timing accuracy (when using a 60Hz CRT monitor) when we instruct OpenSesame to display for 33.2ms (we tell it to display at 30ms since telling it to display at 33 results in 47-50ms) the recorded timing in closer to 37ms. This issue does not appear to exist on LCD monitors (also 60Hz but on a different computer) where the timing is usually exact or only out by 1ms.

I'm not sure I fully understand this. What exactly do you mean by 'recorded timing'? Is that the timing that the technicians have recorded using a photosensitive diode (or something similar?). Or is it the timing reported by OpenSesame? If you mean the latter, could you perhaps describe how you have done the benchmarking exactly? E.g., by posting a script or describing a trial_sequence, and providing other relevant details, such as the back-end and operating system.

Cheers!
Sebastiaan

PS. If you want to share an experiment (or other type of attachment), it's preferable to post it as a publicly accessible links on this forum. That way, other people can answer your question as well! (Unless, of course, there is a strong reason not to post it publicly.)

booradley

Thanks, that explains the 'phantom timings' indeed

Regarding the other timing issue, I'm describing how long a sketchpad is held to the screen (i.e. how many frames in milliseconds) and the recorded timings in the data file as created by OpenSesame.

I calculate the presentation times, as discussed earlier, and they don't seem to be 100% accurate. When we instruct Opensesame to display for 2 frames on a 60Hz CRT there seems to be up to 3ms extra which might indicate a delay? (we instruct it to display for 30ms since when we tell it to do 33ms it is way out. When told to do 30ms it is recorded on the data file as being displayed for 36-37ms for the experiment in DropBox. However, when just displaying a single frame in a loop 20 times with no aim other than recording timings it seems to hit the 33ms mark easily. However, when instructed for 66ms in this paradigm, 4 frames, there is a huge inconsistency also).

The manner in which the experiment is presented is as follows:

• Presentation one: 1 circle presented on the left for 33ms

followed by

• Presentation 2: 2 circles, one left (same position as last left circle) and one on the right for 49ms.

I take the timings recorded for each by OpenSesame and subtract the first presentation from the second as they are in serial order.

I'm using PsychoPy as the back-end as I need accurate records regarding the display times. This is all run in Windows XP.

I'm not too keen to discuss in any great detail the experiment here on the open forum just yet but the instructions screen in the experiment provided in DropBox explains the task etc.

Thanks again,

Boo.

sebastiaan

The fact that frames can be skipped is not too surprising. For example, if you set the delay to 30ms, and for some reason (which can be anything, including interrupts from the operating system) there is a hold-up of more than 3 milliseconds, the frame will be skipped. The slower the system is, and the more complex your stimuli are, the more likely this is to happen. The solution is simply to tune down the delay even more.

For example, if you want to present a stimulus for 2 frames on a 100Hz monitor, specifying a delay of 11ms is fine. This will give the operating 9ms to deal with potential hick-ups, which should be more than enough. (Obviously, specifying a delay of 10 milliseconds or less is not fine, as then the stimulus may be presented for only a single frame.)

However, even if a frame is skipped, the reported timing should still be a multiple of the refresh rate. For example, on a 60Hz monitor, an intended interval of 33ms (= 2 * 16.67) can become 50ms (= 3 * 16.67). However, an interval of 37ms should never be reported, at least not with the psycho or xpyriment back-end: A stimulus can not be shown for 37ms on a 60Hz monitor, so the timestamp is necessarily incorrect.

So the question is: Are we talking about averages here? Or single timestamps? If you get single timestamps that are inconsistent with the monitor's refresh rate (certainly when more than 1 or 2 ms), something funky is going on: That should not happen.

booradley

Hi again,

I was talking about single timestamps BUT we went ahead and replaced the Quadro FX graphics card for something (not sure what Gary used) higher spec. We were getting some odd time stamps including 13ms before replacing as well as the 37ms! As you said these are literally impossible timings.

The new card seems to have solved the odd timing issues and we're getting the timings we expect to see for a 60Hz monitor.

Taking your advice and tuning down the delay further appears to have solved the problem of timing. We now get 33ms when we use 17ms as the instruct (above 1 frame of 16.6 so that makes sense). Thanks for that.

A quick question on that though. When you say "This will give the operating Xms to deal with potential hick-ups, which should be more than enough." what do you mean?

Is the OS solving this before presentation and then presents in the correct temporal fashion, i.e. are the time stamps accurately reflecting what is being presented temporally?

If this is the case then problem solved.

Thanks yet again for your help.

Boo.

sebastiaan

The new card seems to have solved the odd timing issues and we're getting the timings we expect to see for a 60Hz monitor.

Good!

A quick question on that though. When you say "This will give the operating Xms to deal with potential hick-ups, which should be more than enough." what do you mean?

If you call canvas.show(), there is some computation that needs to be done before the canvas is actually pushed to the screen. Very little computation, because of the prepare-run strategy, but nevertheless some. So if you call canvas.show() a little bit before the "deadline" (i.e. the moment when the display starts refreshing from the top), there is sufficient time. And since canvas.show() will wait for the v-sync, you don't have to worry about the canvas being shown too soon. Does that make sense?

Is the OS solving this before presentation and then presents in the correct temporal fashion, i.e. are the time stamps accurately reflecting what is being presented temporally?

Yes, they are if you use the psycho or xpyriment backends. In this case, canvas.show() will block the experiment until the canvas is actually shown and return the correct timestamp. For the legacy back-end, canvas.show() will (usually) return right away, so the timestamp that you get is not synced to the vertical refresh (but this is purely a measurement issue — The actual display presentation is synced to the refresh).

These things are actually quite complicated, so they should (and will) be explained in more detail in the documentation. For now, this post on the Expyriment wiki is a good resource.

Cheers!

booradley

We're ready to rock this end.

Thanks for all your help.

Boo.