Questions about Timing on Windows

Hardware
1

Hi all! I was wondering if anyone could give me more context about some of the PTB info I’m seeing in an Eyelink PTB experiment. Timing is important, so I want to make sure I’m doing the best I can within the constraints of the system I have. Specs: Windows 10, NVidia GeForce GTX 1080, Zowie monitor at 240Hz. I’m on the current PTB beta:

'3.0.18 - Flavor: beta - Corresponds to SVN Revision 13009
 For more info visit:
 https://github.com/Psychtoolbox-3/Psychtoolbox-3'

I’ve already read ‘help BeampositionQueries’ and ‘help ConserveVRAMSettings’ and ‘help SyncTrouble’ trying to address the timing issues. I updated the graphics driver and adjusted the settings to match the recommendations to the best of my ability. I have also run this code on multiple-screen setups and a single screen setup (see examples below) but the timing comments are still appearing.

Screenshot (5)
Screenshot (5)821×602 36 KB 

PTB-INFO: The detected endline of the vertical blank interval is equal or lower than the startline. This indicates
PTB-INFO: that i couldn't detect the duration of the vertical blank interval and won't be able to correct timestamps
PTB-INFO: for it. This will introduce a very small and constant offset (typically << 1 msec). Read 'help BeampositionQueries'
PTB-INFO: for how to correct this, should you really require that last few microseconds of precision.
PTB-INFO: Btw. this can also mean that your systems beamposition queries are slightly broken. It may help timing precision to
PTB-INFO: enable the beamposition workaround, as explained in 'help ConserveVRAMSettings', section 'kPsychUseBeampositionQueryWorkaround'.


PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA GeForce GTX 1080/PCIe/SSE2 :: 4.6.0 NVIDIA 527.37
PTB-INFO: VBL startline = 1080 , VBL Endline = 1079

(1) What does it mean that VBL endline <= VBL startline?

It looks like the backup method, the beamposition method, is measuring something reasonable:

PTB-INFO: Measured monitor refresh interval from beamposition = 4.262833 ms [234.585798 Hz].
PTB-INFO: Will use beamposition query for accurate Flip time stamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 4.171246 ms [239.736520 Hz]. (50 valid samples taken, stddev=0.071293 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 4.166667 ms [240.000000 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.

(2) Do the deviations between the above refresh intervals seem normal?

I

INFO: PTB's Screen('Flip', 10) command seems to have missed the requested stimulus presentation deadline
INFO: a total of 5 times out of a total of 10 flips during this session.

INFO: This number is fairly accurate (and indicative of real timing problems in your own code or your system)
INFO: if you provided requested stimulus onset times with the 'when' argument of Screen('Flip', window [, when]);
INFO: If you called Screen('Flip', window); without the 'when' argument, this count is more of a ''mild'' indicator
INFO: of timing behaviour than a hard reliable measurement. Large numbers may indicate problems and should at least
INFO: deserve your closer attention. Cfe. 'help SyncTrouble', the FAQ section at www.psychtoolbox.org and the
INFO: examples in the PDF presentation in PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips.

(3) Is it correct to interpret missing the requested stimulus presentation deadline as meaning that the buffer swap was not successfully synchronized with the display’s refresh rate? If so, is it correct to assume that the phrase “this number is fairly accurate” is referring to the “small but constant offset mentioned above” which I’m assuming is something like 1/240Hz = 4.2 ms?

Here’s the full output of a single run:

Eyelink: Opening Eyelink in DUMMY mode


PTB-INFO: This is Psychtoolbox-3 for Microsoft Windows, under Matlab 64-Bit (Version 3.0.18 - Build date: Jun 27 2022).
PTB-INFO: OS support status: Windows 10 (Version 10.0) supported and tested to some limited degree.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: For information about paid support, support memberships and other commercial services, please type
PTB-INFO: 'PsychPaidSupportAndServices'.

PTB-INFO: The detected endline of the vertical blank interval is equal or lower than the startline. This indicates
PTB-INFO: that i couldn't detect the duration of the vertical blank interval and won't be able to correct timestamps
PTB-INFO: for it. This will introduce a very small and constant offset (typically << 1 msec). Read 'help BeampositionQueries'
PTB-INFO: for how to correct this, should you really require that last few microseconds of precision.
PTB-INFO: Btw. this can also mean that your systems beamposition queries are slightly broken. It may help timing precision to
PTB-INFO: enable the beamposition workaround, as explained in 'help ConserveVRAMSettings', section 'kPsychUseBeampositionQueryWorkaround'.


PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA GeForce GTX 1080/PCIe/SSE2 :: 4.6.0 NVIDIA 527.37
PTB-INFO: VBL startline = 1080 , VBL Endline = 1079
PTB-INFO: Measured monitor refresh interval from beamposition = 4.262422 ms [234.608374 Hz].
PTB-INFO: Will use beamposition query for accurate Flip time stamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 4.203306 ms [237.907971 Hz]. (50 valid samples taken, stddev=0.118357 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 4.166667 ms [240.000000 Hz].
PTB-INFO: Small deviations between reported values are normal and no reason to worry.
PTB-INFO: ==============================================================================================================================
PTB-INFO: WINDOWS DWM DESKTOP COMPOSITOR IS ACTIVE. On this Windows-10 or later system, Psychtoolbox can no longer reliably detect if
PTB-INFO: this will cause trouble for timing and integrity of visual stimuli or not. You might be just fine, or you could be in trouble.
PTB-INFO: Use external measurement equipment and independent procedures to verify reliability of timing if you care about proper timing.
PTB-INFO: ==============================================================================================================================
Trial 1 starts...
	Image loaded: catch-stimuli/catch019.BMP 
Trial 2 starts...
	Image loaded: experimental-stimuli/102.BMP 
Trial 3 starts...
	Image loaded: catch-stimuli/catch034.BMP 
Trial 4 starts...
	Image loaded: experimental-stimuli/078.BMP 
Trial 5 starts...
	Image loaded: experimental-stimuli/153.BMP 
Trial 6 starts...
	Image loaded: experimental-stimuli/312.BMP 


INFO: PTB's Screen('Flip', 10) command seems to have missed the requested stimulus presentation deadline
INFO: a total of 6 times out of a total of 14 flips during this session.

INFO: This number is fairly accurate (and indicative of real timing problems in your own code or your system)
INFO: if you provided requested stimulus onset times with the 'when' argument of Screen('Flip', window [, when]);
INFO: If you called Screen('Flip', window); without the 'when' argument, this count is more of a ''mild'' indicator
INFO: of timing behaviour than a hard reliable measurement. Large numbers may indicate problems and should at least
INFO: deserve your closer attention. Cfe. 'help SyncTrouble', the FAQ section at www.psychtoolbox.org and the
INFO: examples in the PDF presentation in PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips.
2

For the more detailed answers, a support ticket for Mario will get you the best answers about what VBL means on a modern system etc.

In general, 4ms isn’t much time to do much of anything in a PTB display loop so physically missing deadlines even on a well-specified Linux system with an AMD card is not unheard of. If you need to do some stimulus updating, check the eye position and any associated logic, check the keyboard, each takes time that will eat into your small allotment per frame. Do you still see dropped frames in a very simple loop? VBLSyncTest? You may need to really care about optimising code in the display loop if it is dependant on the work being done in the display loop…

Are you sure you are passing the correct when timestamp to Screen('Flip'), if you are using a vbl from a previous trial it may not be right for the first frame, you must flip just before your stimulus starts then use that vbl + wiggle room. One trick is to make a log of your stimulus ON/OFF frames and your vbl times then you can check where the missed frames are in relation to your stimulus presentation, like so:

853×1341 70.8 KB

On Linux missed frames can be trusted I think but on Windows Mario’s extensive arsenal of meaurements are potentially prone to some OS or driver bug (guaranteed frame times are not a common requirement for most commericial needs)…

To really confirm these times would also require a physical measurement made using a photodiode. You can make a simple loop and alternate two colours every X frames and see if your lost flip is visible in the photodiode signal?

1 Like
3

The only thing I have to add to @Ian-Max-Andolina without a paid support ticket is that with “a well-specified Linux system with an AMD card” you have more tools at hand than on other systems to make proper timing on a 240 Hz display work. Not only AsyncFlips, also special flips like in PerceptualVBLSyncTestFlipInfo.m, and fine-grained timing support by use of AMD FreeSync, e.g., VRRTest.m. And yes, if timing is really important, i’d switch to such a Linux system.

-mario