Impossible stimulus onset value

Dear experts:

I have:

  • PTB 3.0.16 - Flavor: beta
  • Windows 10
  • Matlab R2020a

I get a lot of error messages about beamposotion/timing. I’m not sure if they are related. I’m running an experiment where I am basically flashing pictures, and receiving response. I’m also sending an audio trigger via portaudio. I have tests checking the presentation durations of the stimuli, so if they differ slightly (a couple of ms) from what is intended I can measure it once to estimate it and it’s fine. What I don’t want is that it is highly unstable (order of tens of ms) so that I can’t estimate the uncertainty in duration presentation.

Outputs:

PTB-WARNING: PsychOSOpenOnscreenWindow: Failed to switch Windows-8+ desktop compositor to realtime scheduling! Expect additional timing and performance problems!!

PTB-WARNING: Call to PsychAvSetMmMaxThreadCharacteristics() for Vista-MMCSS scheduling failed for threadhandle 00007FF942FDA4E0. Setting thread priority to HIGHEST as a work-around…

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-ERROR: Screen(‘Flip’); beamposition timestamping computed an impossible stimulus onset value of 3437258.871335 secs, which would indicate that

PTB-ERROR: stimulus onset happened before it was actually requested! (Earliest theoretically possible 3437258.876531 secs).PTB-ERROR: Some more diagnostic values (only for experts): rawTimestamp = 3437258.881398, scanline = 1303

PTB-ERROR: Some more diagnostic values (only for experts): line_pre_swaprequest = 654, line_post_swaprequest = 667, time_post_swaprequest = 3437258.876622

PTB-ERROR: Some more diagnostic values (only for experts): preflip_vblcount = 0, preflip_vbltimestamp = -1.000000

PTB-ERROR: Some more diagnostic values (only for experts): postflip_vblcount = 0, postflip_vbltimestamp = -1.000000, vbltimestampquery_retrycount = 0PTB-ERROR: This error can be due to either of the following causes:

PTB-ERROR: Very unlikely: Something is broken in your systems beamposition timestamping. I’ve disabled high precision

PTB-ERROR: timestamping for now. Returned timestamps will be less robust and accurate.PTB-ERROR: The most likely cause would be that Synchronization of stimulus onset (buffer swap) to the

PTB-ERROR: vertical blank interval VBL is not working properly, or swap completion signalling to PTB is broken.

PTB-ERROR: Please run the script PerceptualVBLSyncTest to check this. With non-working sync to VBL, all stimulus timing

PTB-ERROR: is futile. Also run

OSXCompositorIdiocyTest on macOS. Also read ‘help SyncTrouble’ !

I have run the BeampositionTest and this is the output. The only thing that worries me is that the queries seem to the on the order of 50-100 microseconds. Output is attached.

THANK SO MUCH!!!

Output suggests beamposition queries work correctly (at least well enough for about 1 msec accurate timing - NVidia card?), assuming this is a monitor with 2160 pixels vertical resolution, e.g., 3840x2160.

So that means that visual onset timing is broken, e.g., because the desktop compositor is running and interfering. Can happen on multi-display setups, or HiDPI displays (especially if the stimulus monitor is not the primary monitor), or dual-graphics laptops (NVidia Optimus and such) or for various other reasons like graphics driver bugs. I’d first test what happens in single-display mode. Switching to Linux is always a recommendation if reliable timing matters.

Thank you SO much for your super quick reply!!!

Let me first answer your questions:

  1. I don’t use several monitors, only one laptop.
  2. The resolution is indeed 3840x2160.
  3. I do have an NVIDIA Optimus as you suspected, but I have actually changed it so that matlab instead uses another GPU, the integrated one, since that was recommended when getting other errors related to synchronization failure.
  4. Could you perhaps please elaborate on ‘visual onset timing is broken’ means? Does it mean A) That the time stamps (from Flip) do not match when the stimulus onset or B) that the stimulus will not be shown at the frame we request it to or C) something else?

From what we understand, the time stamp stimulus presentation time is computed from the previous VBL timestamp, call it VBL_time_i-1 and then adding the estimated interval between VBL timestamps, let’s call it DeltaVBL, to get an estimate of VBL_time_i, which is the stimulus onset. Does it make sense to talk about where in this equation we have the uncertainty?

  1. For us, the most important thing is that we are able to estimate any divergence from what is expected. For example, we can measure any jittered difference between the time stamps and the stimulus presentation by comparing the time stamps to measurements from a photodiode. We can also measure with our photodiode how well the stimulus presentation duration matched the planned one. But we cannot perform these tests continuously, so we have to make sure that whatever timing problems we have we can measure once and then it will stay the same. If these warnings might mean that there is something stochastic going on, then we will just have to switch to Linux (which is a bit of a hassle considering we are a big collaboration and we’ll have to convince everyone else :slight_smile: ).

THANKS A MILLION!!! We really appreciate it!!!

| katbendtz
June 16 |

  • | - |

mariokleiner:

Switching to Linux is always a recommendation if reliable timing matters.

Thank you SO much for your super quick reply!!!

Let me first answer your questions:

  1. I don’t use several monitors, only one laptop.
  2. The resolution is indeed 3840x2160.
  3. I do have an NVIDIA Optimus as you suspected, but I have actually changed it so that matlab instead uses another GPU, the integrated one, since that was recommended when getting other errors related to synchronization failure.

That was the correct move. Unfortunately you probably use an Intel integrated graphics chip, and those often have drivers with timing bugs on Windows, so now it just breaks for a different reason. Maybe an Intel graphics driver upgrade (or downgrade) would help, although i don’t know if this is as straightforward on Optimus laptops, or if special Laptop OEM vendor-provided drivers are needed for Optimus.

On Linux otoh., Intel graphics performs excellent wrt. timing, at least with everything i ever tested.

  1. Could you perhaps please elaborate on ‘visual onset timing is broken’ means? Does it mean A) That the time stamps (from Flip) do not match when the stimulus onset or B) that the stimulus will not be shown at the frame we request it to or C) something else?

Definitely A – Timestamps could be off by up to 50 msecs if you are unlucky, in my experience.

B follows from A if you use the timestamps for stimulus timing, as one usually does, unless one wants to run at full video refresh rate.
Also, with A broken, you can’t detect in software if B happens in any case or not.

From what we understand, the time stamp stimulus presentation time is computed from the previous VBL timestamp, call it VBL_time_i-1 and then adding the estimated interval between VBL timestamps, let’s call it DeltaVBL, to get an estimate of VBL_time_i, which is the stimulus onset. Does it make sense to talk about where in this equation we have the uncertainty?

The reported time by PTB is not an estimate, but a measurement. But what you describe is how one usually calculates the ‘tWhen’ target stimulus onset time if one wants to run animations at anything other than the maximum video refresh rate, or one wants to do timed presentation of stimuli. That’s obviously broken as A is broken.

  1. For us, the most important thing is that we are able to estimate any divergence from what is expected. For example, we can measure any jittered difference between the time stamps and the stimulus presentation by comparing the time stamps to measurements from a photodiode. We can also measure with our photodiode how well the stimulus presentation duration matched the planned one. But we cannot perform these tests continuously, so we have to make sure that whatever timing problems we have we can measure once and then it will stay the same.

That approach likely won’t work, as you don’t have any guarantee that the divergence stays constant across the runtime of your script, or across different runs.

  1. If these warnings might mean that there is something stochastic going on, then we will just have to switch to Linux (which is a bit of a hassle considering we are a big collaboration and we’ll have to convince everyone else :slight_smile:).

Unless all your collaborators have the same broken hardware+software setup, only you need to fix your Laptop with Linux, no? In general Linux is advisable though if hassle free timing is of importance.

-mario