Stimulus timing

Support
1

Hi Chris,

We are currently struggling with some timing issues and were hoping to get your ideas for how to solve them. For the last few years, we have been running Mworks on mac minis. For experiments where timing is important, these don’t really do a great job because of their limited graphics cards. To deal with this, we set up an external GPU to support both displays (the one we use to interact with Mworks and the one the mouse sees). This gave us nicely reliable timing- however, it was a bit of hack that was not supported by Apple- and the updates to the latest operating system were not compatible with this configuration.

However, we really want to use the new stimulus properties that are available with Mworks 0.8 (which needs the updated Mac OS) and so have been trying some alternative solutions. We bought a new iMac and a new external graphics card that is now supported by Apple. However, the timing isn’t anywhere as good as it was with the old setup. In fact, the external GPU doesn’t really help at all. We think this might be because the external GPU only supports our secondary monitor (not the native iMac monitor) and that the processing power needed to update the retina display is overwhelming the system. Things get a bit better when we close the mirror window, but again, still not as good as things were with the mini. I tried using the functions to predict stimulus timing, but this doesn’t really help (we often see a delay, and the prediction just adds more time). I’ve attached some screenshots to show you the computers/graphics cards that we were using in each condition, and the timing of the stimuli in each condition.

Any thoughts that you have on how to solve this would be really helpful.

Thanks,
Lindsey.

2

Attachments:

3

Hi Lindsey,

That is a strange result. Some additional information would be helpful:

  1. In Terminal, can you run the command

     system_profiler SPDisplaysDataType

    and send me the output? If possible, please run it for all three setups in your stim timing PDF.

  2. How are you determining the intended and actual times?

    I ask because I’ve seen people do this type of comparison in a number of different ways, and some methods are better than others. The best approach is to compare the predicted output time from update_stimulus_display with the stimulus onset/offset time as measured by a photodiode.

Thanks,
Chris

4

Hi Chris,
Thanks for the response.
I’ll get the you terminal output ASAP.
In the meantime, these are all measurements from a photodiode. We are
presenting two 100 ms stimuli with a 250 ms fixed interval. We are less
worried about the delay between the Mworks onset/offset times and stimulus
presentation, than the reliability of relative timing of actual stimulus
presentation events across trials. So these histograms come just from the
onsets and offsets of each stimulus measured by the photodiode. If it’s
helpful, we can send the same thing for the timing reported by Mworks.
Lindsey.

5

Hi Lindsey,

We are less worried about the delay between the Mworks onset/offset times and stimulus presentation, than the reliability of relative timing of actual stimulus presentation events across trials. So these histograms come just from the onsets and offsets of each stimulus measured by the photodiode.

OK, got it. Next question: How are you managing the timing within your experiment (i.e. to get the intended 100ms ad 250ms intervals)? If you just want to send me the XML, that would be fine.

Thanks,
Chris

6

Just timers. Here’s the snippet of the code that just deals with stimulus
queue and dequeue (I removed the compensation for predicted output time
since that didn’t help).
Lindsey.

7

Attachment: TwoStim_snippet.rtf (3.78 KB)

8

Here are the terminal outputs.

9

Attachments:

10

Hi Lindsey & Jennifer,

Thanks for the additional info.

The detailed display information doesn’t offer any clues. I thought perhaps the external display was running at a high refresh rate. (If it’s one of these, then it’s capable of running at 144Hz.) However, it looks like it’s running at just 60Hz.

Looking at your XML, I’m surprised the stimulus timing was ever as consistent as it was on your old setup. For the reasoning behind this, I’ll refer you to this discussion. That said, I want to run my own tests with a photodiode and see what results I get on my various test machines.

In the meantime, I have a few more questions and suggestions:

  1. When running on the iMac, do you ever see warnings like this in the MWorks console?

     WARNING: Skipped 1 display refresh cycles

    These indicate that the graphics hardware isn’t keeping up with MWorks drawing demands.

  2. In addition to High Sierra (macOS 10.13), MWorks 0.8 supports Sierra (10.12) and El Capitan (10.11). It looks like automate-eGPU supports up to macOS 10.12. Have you tried upgrading your Mac mini to 10.11 or 10.12 and using your previous external-GPU setup?

  3. High Sierra made some major changes to the macOS graphics stack, which may have introduced some issues that are affecting you. However, your 2017 iMac will also run Sierra (10.12). It might be worth downgrading it (you’ll probably need to create a bootable installer to do so) and seeing what the stimulus timing is like under Sierra. (This would be using only the internal graphics, as Sierra doesn’t support external GPUs.)

Chris

11

Hi Chris,
Yes- we do see warnings about refresh cycles- much more with the iMac than
we has with the Mac mini. This may be why the predicted output time is not
as helpful for us.
We will try the other OS you suggest (for both the mini and imac) and let
you know how it goes.
Looking forward to seeing your results.
Lindsey.

12

Hi Lindsey,

Yes- we do see warnings about refresh cycles- much more with the iMac than we has with the Mac mini.

Oh, ok. That strongly suggests an issue with the graphics drivers, rather than the hardware. I would definitely try downgrading the iMac to macOS 10.12.

Chris

13

Hi Lindsey,

Were you able to try downgrading the OS on your iMac?

I’ve been running some tests, but so far I haven’t seen the behavior you reported. My best guess is still that it’s a graphics driver issue. If I gain any additional insights, I’ll be sure to let you know.

Cheers,
Chris

14

Hi Chris,
Yes- we downgraded to Sierra and this helped substantially with the timing
issues on the simple experiment I sent you. We have some other, more
complicated, experiments that are still jittery and we’re trying to
pinpoint where the variability is arising. Will send an update if we
figure it out.
Thanks for checking into this (and checking back with us),
Lindsey.