| Reference | Downloads | Github

Refresh stability issue: please help! Doc is scarce about this

Hi community,

The benchmark wizard detects a refresh stability issue:

"refresh stability (SD) 3.59 ms Warning: the refresh rate has high frame-to-frame variability (SD > 0.5 ms)"
I use a BENQ XL2411Z LCD monitor running at 144 Hz (1920x1080). Processor is AMD A6-6400K with Radeon Graphics. Platform is windows 7.

I can’t figure out what this exactly means, and consequences of this issue on timing. Please help, documentation is pretty scarce on this…

Check that you have the latest graphics card driver installed. Get it directly from AMD, for your specific AMD Radeon graphics card. Don’t rely on Windows-provided drivers.

Thanks Michael, I will. Meanwhile, I’d like to understand consequences of this issue on data collection. Any insight?

That’s too general a question to be answerable. It really depends on the implementation of your particular task. Best just to try and address the issue before gathering data. Once you have the appropriate driver installed, try again, changing driver settings if needed to get the refresh rate to be stable as required.

Or are you saying that you already have data collected under these conditions?

I haven’t started data collection yet, I’d like to solve the issue first.
I updated my Radeon drivers, without success. The refresh stability still shows a suboptimal value (SD = 2.69). I noticed that the default radeon setting for ‘wait for vertical refresh was ‘off, unless application specifies’. I changed to "always on’ or even ‘Enhanced sync’, but this didn’t change anything.
My experiment involves static stim. I just flip() once and starts a timer right after until the response. Do you think I should start data collection?
Thanks again for the precious help

It should probably be set to “always on”, (I would have hoped that this would solve your issue). Avoid “Enhanced sync” for the timebeing unless you know what you are doing.

Perhaps post a screenshot of the available settings for some feedback from someone more familiar with it.

If the card doesn’t wait for the next vertical refresh, then you can’t be too sure about when your stimulus actually appeared, so it adds a bit of noise to your RT measurement. If it is waiting, then the variability may be due to other reasons (like competing processes meaning your code can’t always keep up with the refresh rate of the screen). We might be able to assess that if given more info than just the mean and SD. Try running PsychoPy’s built-in timeByFrames demos and post a screenshot of the resulting graphs here.

Ok, attached are plots from timeByFrames and timebyFramesEx. I also attach a screenshot of results from the benchmark wizard. Looks that the graphics card waits for the next vertical refresh. So there seems to be competing processes. Weird, as he computer is not connected to the internet, and has very few softwares installed. Note that I am using a BENQ monitor running at 144Hz. Hower, I get the same issues when decreasing the refresh rate down to 60Hz.

The good news is that the timing demos show well-nigh perfect performance at 144 Hz, with little appreciable variability. I don’t know how to explain the contradiction between those results and those of the benchmark wizard, indicating an SD of 2.44 ms. Perhaps @jon can shine some light on it?

But these results bode well for the possibility of good timing within your own experiment.

The times being reported there look exceedingly well constrained (as in, it looks like your precision most of the time is roughly 10s of microseconds which is amazing).

But note that very first value appears shorter than the others (2.5ms not 7ms). I expect that’s causing the problem in the SD calculation from the benchmark wizard (I didn’t personally write benchmark so I can’t say for sure). I suspect that’s a slight error in deciding what to call t=0, or possibly it’s an issue that your system is taking a little while to “calm down” at the beginning.

The key part, though is that, while rendering the stimulus the SD looks way way less than 1ms, so I’m sure there isn’t anything to worry about with your hardware/environment