failed sanity check?

1
dear mario et al.

i'm helping a friend, John Krauskopf, get an experiment going with the Psychtoolbox. He
wants to show movies of drifting gratings. Things are basically working, but we're getting
a lot of unsolicited warning messages about failures in synching:

PTB-WARNING: Couldn't even collect one single valid flip interval sample! Sanity range
checks failed!
PTB-WARNING: Couldn't even collect one single valid flip interval sample! Sanity range
checks failed!
PTB-WARNING: Couldn't even collect one single valid flip interval sample! Sanity range
checks failed!


PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA NV34MAP OpenGL Engine ::
1.5 NVIDIA-1.3.42
PTB-INFO: Renderer has 64 MB of VRAM and a maximum 59 MB of texture memory.
PTB-Info: VBL startline = 768 , VBL Endline = 807
PTB-Info: Measured monitor refresh interval from beamposition = 11.764782 ms
[84.999448 Hz].
PTB-Info: Measured monitor refresh interval from VBLsync = 0.000000 ms [inf Hz]. (0 valid
samples taken, stddev=10000000.000000 ms.)
PTB-Info: Reported monitor refresh interval from operating system = 11.764706 ms
[85.000000 Hz].
PTB-Info: Small deviations between reported values are normal and no reason to worry.

WARNING: Couldn't compute a reliable estimate of monitor refresh interval! Trouble with
VBL syncing?!?

we're running mac os x 10.3.9 on a 12" powerbook G4, MATLAB 7.0.0.19901 (R14), latest
beta (today) of Psychtoolbox. we are driving a CRT as an external monitor (85 Hz).

QUESTIONS:
1. is the synching problem real? it appears that line counting timing is working, but the
VBLSynch is not.
2. i am confused by all the orders to set my monitors to different frame rates and
mirroring. we'd prefer NOT to mirror. must we mirror? must we have different rates?

best

denis

ps
unsolicited warnings are intrusive. i'd much prefer to run a test program when i want to,
not have intrusions in my experiment.
2
Hi Denis,

that's something new: Up to now, problems were sometimes caused by
non-mirror mode and often resolved by switching into mirror-mode. Here
it seems to be the opposite. The test results for non-mirror mode look
very good, so i'd recommend just using it that way. I think i will
remove the non-mirror mode warnings in future releases and replace
them by a one-liner that will direct users to some help file that
explains all the issues around mirror vs. non-mirror. A general
warning is not useful if this is highly hardware specific.

I'd recommend minimizing the Matlab window and possibly switching off
the digital clock in the Menubar (if possible) if you run dual-display
in non-mirrored mode -- Any kind of display update on the desktop can
interfere a bit with timing in the external display. That's the main
reason for the mirror-mode recommendation.

The yellow lines show you the detected rasterbeam position at the time
when flip returns from double-buffer swap. Ideally they should be
located somewhere in the vertical blank area of the display, so you
should not see them at all. In the real world with its occasional
delays and timing jitter, you'll find a few of them at the top of the
display, indicating the small scheduling delays of your computer. On a
broken setup, where either sync to VBL is broken, or syncing to the
wrong display on a dual-display setup, or beamposition queries are
broken, you'll find them spreading over the whole screen area.

So your system setup is fine. Nearly all possible failures related to
vbl sync will be detected automatically during Screen('OpenWindow')
anyway. PerceptualVBLsynctest and VBLSynctest are just different means
to diagnose problems and to double-check what the internal tests do
anyway.

The count of missed deadlines of Screen - Flip is a total count over
the whole session. Very small numbers (1 or 2) are normal, large
numbers may point to problems with your timing. If you provide
Screen('Flip') with the optional 'when' argument that requests a
specific stimulus onset time, then the test works very reliable. If
you use the returned vbl - timestamp of Screen('Flip') then you can
check the timing yourself with a much higher precision than when using
GetSecs. Some of the demos and esp. VBLSyncTests source code describe
this feature in more detail.

ciao,
-mario


--- In psychtoolbox@yahoogroups.com, Denis Pelli <denis.pelli@...> wrote:
>
> dear mario
>
> thanks for the helpful reply. we're still baffled by the failing
> sanity check associated with calling SCREEN.
>
> OUR SET UP:
> the failures occur when we run PerceptualVBLSyncTest on a 12" Powerbook.
> mac osx 10.4.6
> matlab 7.0.0.19901 (R14)
> latest beta version of psychtoolbox
> we have TWO displays:
> the built-in LCD screen (main, w menu bar): 60 Hz, 1024x768, millions
> of colors
> an external display driven via the NVIDIA interface and a BITS++
> external adapter: 85 Hz, 1024x768, millions of colors
>
> MIRRORING: contrary to expectation, things more or less work if
> mirroring is off, and fail if mirroring is on. See command-window
> printouts below.
>
> BUG: When mirroring is on, the warnings falsely state that mirroring
> is off. When mirroring is off, the warnings correctly state that it's
> off.
>
> MISSING EXPLANATION: the print out talks about yellow lines, but
> doesn't explain what the "yellow lines" represent. what are they?
>
> INCOMPLETE WARNING:
> WARNING: PTB's Screen('Flip') command missed the requested stimulus
> presentation deadline 2 times!
> This is hard to interpret. It missed 2 out of how many? 100? 1000?
>
> When we run PerceptualVBLSyncTest with mirroring OFF then we see a
> uniform flicker, and yellow lines bunched near the top of the screen.
> Thus we PASS the test, though there are a few warnings. When we run
> with mirroring ON then the test fails prematurely and we never see
> the flickering screen.
>
> the Command Window printouts appear below.
>
> best
>
> denis
>
>
> Here's what appears in the Command Window when we run
> PerceptualVBLSyncTest.
>
>
> two independent displays (85 & 60 Hz), no mirroring:
> PerceptualVBLSyncTest works fine.
> PTB-WARNING: Some of your connected displays are *NOT* switched into
> mirror mode!
> ...
> PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA NV34MAP
> OpenGL Engine :: 1.5 NVIDIA-1.4.18
> PTB-INFO: Renderer has 64 MB of VRAM and a maximum 56 MB of texture
> memory.
> PTB-Info: VBL startline = 768 , VBL Endline = 807
> PTB-Info: Measured monitor refresh interval from beamposition =
> 11.764713 ms [84.999952 Hz].
> PTB-Info: Measured monitor refresh interval from VBLsync = 11.764706
> ms [84.999999 Hz]. (50 valid samples taken, stddev=0.034386 ms.)
> PTB-Info: Reported monitor refresh interval from operating system =
> 11.764706 ms [85.000000 Hz].
> ...
>
> two mirrored displays (60 & 85 Hz)
> PerceptualVBLSyncTest fails
> it FALSELY claims that mirroring is off:
> PTB-WARNING: Some of your connected displays are *NOT* switched into
> mirror mode!
> PTB-WARNING: Couldn't even collect one single valid flip interval
> sample! Sanity range checks failed!
> PTB-WARNING: Couldn't even collect one single valid flip interval
> sample! Sanity range checks failed!
> PTB-WARNING: Couldn't even collect one single valid flip interval
> sample! Sanity range checks failed!
> PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA NV34MAP
> OpenGL Engine :: 1.5 NVIDIA-1.4.18
> PTB-INFO: Renderer has 64 MB of VRAM and a maximum 59 MB of texture
> memory.
> PTB-Info: VBL startline = 768 , VBL Endline = 807
> PTB-Info: Measured monitor refresh interval from beamposition =
> 11.764884 ms [84.998712 Hz].
> PTB-Info: Measured monitor refresh interval from VBLsync = 0.000000
> ms [inf Hz]. (0 valid samples taken, stddev=10000000.000000 ms.)
> PTB-Info: Reported monitor refresh interval from operating system =
> 11.764706 ms [85.000000 Hz].
> ----- ! PTB - ERROR: SYNCHRONIZATION FAILURE ! ----
>
> two displays mirrored (85 Hz & 60 Hz, both 1024x768, millions of colors)
> ***PerceptualVBLSyncTest fails, and falsely claims that we are not
> mirroring.
> PTB-WARNING: Couldn't even collect one single valid flip interval
> sample! Sanity range checks failed!
> PTB-WARNING: Couldn't even collect one single valid flip interval
> sample! Sanity range checks failed!
> PTB-WARNING: Couldn't even collect one single valid flip interval
> sample! Sanity range checks failed!
> PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA NV34MAP
> OpenGL Engine :: 1.5 NVIDIA-1.4.18
> PTB-INFO: Renderer has 64 MB of VRAM and a maximum 59 MB of texture
> memory.
> PTB-Info: VBL startline = 768 , VBL Endline = 807
> PTB-Info: Measured monitor refresh interval from beamposition =
> 11.765030 ms [84.997656 Hz].
> PTB-Info: Measured monitor refresh interval from VBLsync = 0.000000
> ms [inf Hz]. (0 valid samples taken, stddev=10000000.000000 ms.)
> PTB-Info: Reported monitor refresh interval from operating system =
> 11.764706 ms [85.000000 Hz].
> PTB-Info: Small deviations between reported values are normal and no
> reason to worry.
> WARNING: Couldn't compute a reliable estimate of monitor refresh
> interval! Trouble with VBL syncing?!?
> WARNING: Mismatch between measured monitor refresh interval and
> interval reported by operating system.
> This indicates massive problems with VBL sync.
> WARNING: Measured monitor refresh interval indicates a display
> refresh of less than 25 Hz or more than 250 Hz?!?
> This indicates massive problems with VBL sync.
> ----- ! PTB - ERROR: SYNCHRONIZATION FAILURE ! ----
>
> two displays NOT mirrored (85 Hz & 60 Hz, both 1024x768, millions of
> colors)
> ****PerceptualVBLSyncTest works. the yellow lines are clustered near
> the top.
> PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA NV34MAP
> OpenGL Engine :: 1.5 NVIDIA-1.4.18
> PTB-INFO: Renderer has 64 MB of VRAM and a maximum 56 MB of texture
> memory.
> PTB-Info: VBL startline = 768 , VBL Endline = 807
> PTB-Info: Measured monitor refresh interval from beamposition =
> 11.765339 ms [84.995424 Hz].
> PTB-Info: Measured monitor refresh interval from VBLsync = 11.764744
> ms [84.999725 Hz]. (50 valid samples taken, stddev=0.016460 ms.)
> PTB-Info: Reported monitor refresh interval from operating system =
> 11.764706 ms [85.000000 Hz].
> PTB-Info: Small deviations between reported values are normal and no
> reason to worry.
>
> WARNING: PTB's Screen('Flip') command missed the requested stimulus
> presentation deadline 2 times!
>
>
> On May 22, 2006, at 9:36 PM, Mario Kleiner wrote:
>
> > Hi Denis
> >
> > The warnings mean that synchronization to the vertical retrace is
> > completely broken. Normally PTB should abort in such a case, unless
> > the Screen('Preference','SkipSyncTests',1) is set. In that case it
> > would continue without any way to collect stimulus onset timestamps or
> > to sync to retrace or to get the timing right...
> >
> > There's the script 'PerceptualVBLSyncTest' that you could run to
> > verify this visually. Does it work properly (no tearing artifacts)
> > without external display?
> >
> > PTB tries to collect at least 50 valid samples of flips to compute the
> > refresh rate and verify proper syncing. One of the criterions for a
> > valid sample is that the measured duration via flip should be in a +/-
> > 20% window of the interval reported by the operating system.
> >
> > My best guess would be that the Flip command syncs its bufferswaps to
> > the 60 Hz cycle of the internal flat-panel instead of the 85 Hz cycle
> > of the external display, as requested. This is a driver-bug of the
> > gfx-driver, or maybe a "limitation" as Nvidia would call it.
> >
> > I'd try:
> >
> > 1. Does it work in mirror-mode -- both displays run at same refresh
> > rate and are probably driven by same scan converter?
> >
> > 2. Is it possible to change the assignment of primary and secondary
> > display in the OS-X display settings? That might help to force the
> > driver to sync to the correct display.
> >
> > 3. Driver update (Would probably mean OS-X update to Tiger).
> >
> > We had this kind of issues with ATI cards under OS-X 10.3.x. ATI fixed
> > it somewhere in Tiger. This is the first time i'd hear from similar
> > NVidia problems.
> >
> > The mirror mode recommendation is meant to improve timing, because
> > then no gfx-hw ressources are wasted for showing the Aqua desktop or
> > the blinking Matlab cursor and digital clock on the other display. On
> > some hardware this can introduce timing-spikes up to 14 milliseconds.
> >
> > The different framerate recommendation is meant to be applied only
> > once for a specific setup, because this allows some built-in tests to
> > detect subtle problems with VBL syncing that could go unnoticed
> > otherwise.
> >
> > best,
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "Denis Pelli" <denis.pelli@>
> > wrote:
> >>
> >> dear mario et al.
> >>
> >> i'm helping a friend, John Krauskopf, get an experiment going with
> > the Psychtoolbox. He
> >> wants to show movies of drifting gratings. Things are basically
> > working, but we're getting
> >> a lot of unsolicited warning messages about failures in synching:
> >>
> >> PTB-WARNING: Couldn't even collect one single valid flip interval
> > sample! Sanity range
> >> checks failed!
> >> PTB-WARNING: Couldn't even collect one single valid flip interval
> > sample! Sanity range
> >> checks failed!
> >> PTB-WARNING: Couldn't even collect one single valid flip interval
> > sample! Sanity range
> >> checks failed!
> >>
> >>
> >> PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA NV34MAP
> > OpenGL Engine ::
> >> 1.5 NVIDIA-1.3.42
> >> PTB-INFO: Renderer has 64 MB of VRAM and a maximum 59 MB of texture
> > memory.
> >> PTB-Info: VBL startline = 768 , VBL Endline = 807
> >> PTB-Info: Measured monitor refresh interval from beamposition =
> > 11.764782 ms
> >> [84.999448 Hz].
> >> PTB-Info: Measured monitor refresh interval from VBLsync = 0.000000
> > ms [inf Hz]. (0 valid
> >> samples taken, stddev=10000000.000000 ms.)
> >> PTB-Info: Reported monitor refresh interval from operating system =
> > 11.764706 ms
> >> [85.000000 Hz].
> >> PTB-Info: Small deviations between reported values are normal and no
> > reason to worry.
> >>
> >> WARNING: Couldn't compute a reliable estimate of monitor refresh
> > interval! Trouble with
> >> VBL syncing?!?
> >>
> >> we're running mac os x 10.3.9 on a 12" powerbook G4, MATLAB
> > 7.0.0.19901 (R14), latest
> >> beta (today) of Psychtoolbox. we are driving a CRT as an external
> > monitor (85 Hz).
> >>
> >> QUESTIONS:
> >> 1. is the synching problem real? it appears that line counting
> > timing is working, but the
> >> VBLSynch is not.
> >> 2. i am confused by all the orders to set my monitors to different
> > frame rates and
> >> mirroring. we'd prefer NOT to mirror. must we mirror? must we have
> > different rates?
> >>
> >> best
> >>
> >> denis
> >>
> >> ps
> >> unsolicited warnings are intrusive. i'd much prefer to run a test
> > program when i want to,
> >> not have intrusions in my experiment.
> >>
> >
> >
> >
> >
> >
> >
> > ------------------------ Yahoo! Groups Sponsor --------------------
> > ~-->
> > Home is just a click away. Make Yahoo! your home page now.
> > http://us.click.yahoo.com/DHchtC/3FxNAA/yQLSAA/BEfwlB/TM
> > --------------------------------------------------------------------
> > ~->
> >
> > Post your message to: psychtoolbox@yahoogroups.com
> > Please indicate OS9, OSX, or WIN version, and include your full name.
> > Denis Pelli, David Brainard, and Allen Ingling.
> > http://psychtoolbox.org
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>
> Denis Pelli
> Professor of Psychology and Neural Science
> http://psych.nyu.edu/pelli/
>
3
I guess many people use PTB dual-display setups, but not too many on a mobile machine
with relatively low-end gfx-hw at relatively high refresh rates. For Apple users, a MacBook
Pro is the future, with pretty decent gfx-hw and horsepower if one can afford it. The
MacBooks and MacMinis have low-end gfx - not an earth-shattering improvement in
graphics performance and featureset at all wrt. the old PowerBooks, mostly targeted at
office work and web surfing.

But the numbers don't look too bad: 0.33% dropped frames at 50 secs at 120 Hz at
800x600 is pretty good for your setup. The hardware can just handle the load, it just
doesn't have any headroom left to tolerate occasional spikes in gfx/cpu load that happen
from time to time. Let's do some fine tuning to see if we can squeeze out a millisecond or
two. You'll have to try these in no specific order, each of them will reduce cpu or gpu load
and timing noise but i don't know which ones will work better or worse or which
combination will suffice. You can use all of them simultaneously:

Matlab: Try to run it in matlab -nojvm mode --> Cuts down all the periodic processing
done by the user interface and the heavy-weight Java virtual machine, reduces memory
load and cpu load.

User interface: Make sure nothing moves on your desktop -> Static clock display, no
blinking second indicator, no display of seconds. -> Reduces gpu load.

Try if adding a Screen('Preference', 'ConserveVRAM', x); with x=1 or 2 or 3 or 4 to the top
of your script makes things better or worse. --> Reduced VRAM pressure, but higher load
for system RAM and bus. Wouldn't expect much, but worth a try...

Open a 2nd onscreen window on the internal flat-panel while your code is running. This
has the purpose of blocking the OS-X user interface from updating the internal display.
PTB takes over full control over ressource management for any display with an open
onscreen window... --> Reduced VRAM pressure and gpu load, more deterministic
timing.

Modify Screen('Flip', w) to become Screen('Flip', w, 0, 2); This will prevent PTB from
automatically clearing the framebuffer to background color after each flip. You'll have to
handle this manually, but as long as your new stim overdraws the old stim anyway, we can
save a millisecond or so for the redundant clearing of the framebuffer. --> Reduces gpu
load.

What else? If you draw textures without any scaling, subpixel scrolling or subpixel shifts
(srcRect and dstRect of same size and positioned at integral pixel positions) and without
rotation (standard upright drawing), you can disable bilinear texture filtering by explicitely
setting the optional flag 'filtermode' of Screen('DrawTexture',......,filtermode) to zero. -->
Reduce gpu load and VRAM bandwidth.

Finally (try this at last, avoid if possible), read "help Priority" (the section about OS-X
10.4.7 and later) and follow the suggestions there. This shouldn't matter much, but maybe
with old G4 hardware it makes a small difference.

Another thing: Running the OS-9 Classic environment is an absolute killer for timing
behaviour on OS-X.

The VBLSyncTest script is another way to assess and learn about display timing.

The PTB beta should work on your setup. If it gives you sync failures that's an indication of
something fishy in itself. Maybe you should post the error-output of PTB beta?

What kind of stimuli do you want to create? While DriftDemo is a nice demo for texture
based movies, there are much more elegant and efficient ways in PTB3 to create drifting
periodic gratings or other periodic stimuli, e.g., DriftDemo2 and DriftDemo3 or
AlphaRotateDemo or DriftWaitDemo...

In any case, give us feedback what worked (well) and what didn't.

good luck,
-mario

--- In psychtoolbox@yahoogroups.com, "Solomon, Joshua" <J.A.Solomon@...> wrote:
>
> Dear Mario (et al)
> Thanks for your help, and sorry for the long delay in responding, but...
>
> On 21/1/07 18:12, "Mario Kleiner" <mario.kleiner@...> wrote:
>
> > If you get consistent sync-failures then somethings screwed with timing on
> > your setup. What OS and gfx-hardware do you use?
>
> Mac OS X 10.4.8; NVIDIA GeForce4 MX.
>
> > Does it help to disable one
> > of the displays? Someone said one can disable the internal flatpanel by
> > closing the lid?
>
> I don't know of any way to disable the flatpanel without putting the
> computer to sleep. This would be a suboptimal solution in any case. Someone
> out there must be able to use PsychToolbox with two displays!
>
> > Rethinking your timing problem, 13 dropped frames are the sum of 12 + 1. 1 is
> > expected given the demos design, 12 is the number of textures that are created
> > in DriftDemo, so the 13 dropped frames are probably the 13 first frames and
> > you see the upload delay for initial upload of the 12 textures to VRAM. If you
> > increase the runtime of the demo you'll probably not experience any more
> > dropped frames, regardless of runtime.
>
> A good thought, but no. The number of dropped frames isn't consistent. It
> does increase with display time, but not proportionately. I ran it twice
> with a 50-second display. The first time there were 27 dropped frames; the
> second time there were 23.
>
> > If this is the case then you could try addign the Screen('PreloadTextures',
> > win); command before start of the animation loop to ask PTB to preload the
> > textures before start of the display loop and see if this helps.
>
> I tried this anyway. 26 dropped frames.
>
> > With recent gfx-cards one usually doesn't need such measures for any
> > reasonably sized images, they are just way too fast, but with older hardware
> > it may cost you just one or two millsecs too much for 120 Hz without
> > preloading.
> >
> > Like the bavarians say: "Schaun wer mal, dann seh mer schon." -mario
>
> OK, I give up. Translation?
>
> > --- In psychtoolbox@yahoogroups.com, "Solomon, Joshua" <J.A.Solomon@>
> > wrote:
> >
> >> On 18/1/07 19:28, "Mario Kleiner" <mario.kleiner@> wrote:
> >>
> >>> Try to use the latest beta instead of stable, its always more up to date,
> >>> more fine-tuned, maybe that helps a bit.
> >>>
> >> Thanks, but the beta version doesn't work for me. DriftDemo crashes due to
> >> catastrophic sync errors, whether I use MirrorMode or not.
> >>
> >>> One dropped frame is normal for that demo, but 13 seems to be too much. Do
> >>> you see the same effect in other demos or only in that one? Could it be that
> >>> some other software is running on your machine in the background?
> >>>
> >> No other software running. I tried MovieDemoOSX a couple times. The first
> >> time, only one frame was dropped; the second time, none. I then tried
> >> DriftDemoOSX again. Thirteen frames dropped. This is at 120 Hz. I also tried
> >> DriftDemoOSX again at 85 Hz. No dropped frames.
> >>
> >>> --- In psychtoolbox@yahoogroups.com, "smgxjas" <J.A.Solomon@> wrote:
> >>>
> >>>> I still get between 11 and 17 dropped frames
> >>>> each time I run DriftDemoOSX at 800 x 600 x 120, using non-mirrored mode
> >>>> (MirrorMode won't work at all) from my 1-GHz PowerBook G4. Today I also
> >>>> tried 640 x 480 x 67. Only one dropped frame! I could live with 1 dropped
> >>>> frame, but I cannot live with 67 Hz. So, suggestions still appreciated. I'd
> >>>> even be willing to buy alternative hardware, if it would help. js
>
> --
> Joshua A. Solomon
> http://www.staff.city.ac.uk/~solomon
>