Timing Issue in MWorks

Support
1

Hi Chris,

To get the actual time of stimulus presentation, I used information from trigger output provided by VPixx monitor.

In this experiment, the two stimuli are separated by a delay time which was randomised from trial to trial. Comparing what I tell MWorks to do (ideal delay), and what I actually got from Vpixx, it looks like MWorks is always late at displaying stimuli by at least one update frame (the refresh rate was 120 Hz).

I run this experiment with an iMac:
macOS Sierra 10.12.6
3.2 GHz Inter Core i5
8 GB 1867 MHz DDR3
AMD Radeon R9 M380 2048 MB
1 TB SATA Disk storage

Do you think this is plausible? Have you encountered something like this?

Best
Tenri

2

Attachment: almaTimingPerformanceDelay.png (139 KB)

3

Hi Tenri,

In this experiment, the two stimuli are separated by a delay time which was randomised from trial to trial. Comparing what I tell MWorks to do (ideal delay), and what I actually got from Vpixx, it looks like MWorks is always late at displaying stimuli by at least one update frame (the refresh rate was 120 Hz).

You need to be careful about what you’re measuring here. Contrary to what you might expect, the completion of an update_stimulus_display action does not indicate that the display has actually been updated. Instead, it indicates only that the drawing commands have been submitted to the graphics hardware. (For more info, see Understanding Display Updates in the user manual.)

If, within your experiment, you want to know when the display is actually updated, you can use the optional predicted_output_time parameter of update_stimulus_display. You set it to the name of a variable, and when update_stimulus_display executes, it stores in that variable the predicted output time of the frame in which the update will take effect. This time is the operating system’s best guess for when the rendered frame will start to appear on screen. (The same predicted time is used as the timestamp on the #stimDisplayUpdate event corresponding to the update.)

Theoretically, the predicted output times for your stimuli should be close to the times you get from the VPixx monitor. However, there are additional factors that can cause a discrepancy between them. The following come to mind:

  • The predicted output time reported by MWorks is the operating system’s estimate, based on past data, of when the next vertical blank interrupt (VBI) will occur. The display should begin redrawing shortly after the interrupt, but there may be a delay of a few milliseconds.

  • Like CRT’s, LCD displays don’t update all their pixels simultaneously. Instead, the updates are spread out over the refresh period. (The displays I’ve looked at in detail all seem to refresh row by row, left to right, starting at the upper left, and ending at the lower right. However, I don’t know that this is true in general). If the VPixx is reporting when a pixel in the lower right of the display changes, that could be nearly a full refresh period after the VBI.

Also, what exactly is the output you’re getting from the VPixx, and how are you assigning an MWorks time to it? Is it a TTL signal you’re reading into MWorks with a DAQ?

Chris

4

Hi Chris,

The plot I sent to you depicts the difference between the command in MWorks using Start Timer-Timer Expires, with what actually happened, as indicated by VPixx. Looking at the plot, when I tell MWorks to present a 2nd stimulus x-ms after 1st stimulus, the actual latency between two stimuli is x + some inaccuracy. The inaccuracy is ~ 8, 16, 25 etc.

The VPixx information tells me when the display is actually updated. Every time I queue a stimulus, I also queue a small patch at the top left of monitor. Therefore, they are updated together. The RGB value of this patch is read by DAQ.

To know the time when a stimulus is presented, I looked into the MWK file, and take the time stamp (time_us) when the variable storing the TTL signal from VPixx change values (e.g from 0 to 1).

In the attached screenshot, I calculated the actual latency between stimuli as temp(7484).time_us - temp(7481). time_us. 154 and 155 are the event codes of variables where I store the TTL signal from Vpixx.

Sorry if this is not clear yet.

Best
Tenri

5

Attachment: Screen_Shot_2018-07-13_at_15.47.39.png (116 KB)

6

Hi Tenri,

Apologies for the delay in responding.

The plot I sent to you depicts the difference between the command in MWorks using Start Timer-Timer Expires, with what actually happened, as indicated by VPixx.

Ok. My understanding is that the change from the first stimulus to the second proceeds as follows:

  1. Dequeue first stimulus
  2. Update display
  3. Start timer (using a randomized time interval)
  4. Wait for timer to expire
  5. Queue second stimulus
  6. Update display

Also, you’re comparing the timer duration with the interval between TTL low and TTL high from the VPixx. Is that all correct?

The difficultly here (which I tried to explain in my previous response) is that the completion of an update display action does not imply that the display has been updated. Instead, it only indicates that the display will be updated in the near future (ideally, less than one refresh period in the future, but that isn’t guaranteed). Again, I suggest reading Understanding Display Updates.

As a first step toward figuring out what’s happening here, I suggested (and still suggest) that, instead of comparing the time interval inferred from the VPix output with the timer duration, you instead compare the VPix low/high times with the time stamps of the #stimDisplayUpdate events when (1) stimulus #1 disappears from the list of displayed stimuli and (2) stimulus #2 appears in the list of displayed stimuli. By doing this, you’ll be able to compare when the operating system (and, hence, MWorks) thinks the display will be updated with when the VPixx detects it being updated.

As I noted previously, those times should match pretty well: I wouldn’t expect differences of more than a couple milliseconds. If there are big differences (i.e. a full refresh period or more), then the next thing to consider is whether MWorks and/or the graphics hardware isn’t keeping up with the display. If this is happening, you should be seeing warnings in the MWServer console window of the form:

WARNING: Skipped x display refresh cycles

where x is 1, 2, etc. To confirm that MWServer will issue these warnings, check that the system variable #warnOnSkippedRefresh is set to 1 (or, equivalently, that “Warn if stimulus presentation skips a display refresh cycle” is checked in MWServer’s preferences window).

If skipped refresh warnings are enabled, and MWServer isn’t issuing any… well, then we have a genuine mystery on our hands. But we can address that if/when we get to it.

Cheers,
Chris