Our macOS is 10.11 due to compatibility problems with other software we can’t transition to Linux swiftly. I understand mac has some timing issues, but I want to check if the timing error can be within our tolerance ~2ms. So I did a default VLBSyncTest.
Here are some plots illustrating delta between consecutive flips. We have a 60Hz monitor so as long as ifi is between 15~18 ms it should be fine.
I made 8 different runs, you can see most of the run are within the tolerable range, but sometimes they went really far (delay more than ± 5ms). One interesting thing is that these delay usually happen in the later section of the run, almost like something interrupted the run.
I’m just curious if this is the macOS timing things that people keep mentioning, and if there is a workaround. If we are forced to use this system, we will need to test and report the ifi std, and hopefully it’s mostly within 1~2ms.
Also the SyncTest always reports this line first, so I thought it must be safe because the stddev is only around 0.5ms. Why is this report inconsistent with my testing above? Is it because it only tested 50 samples, so didn’t expect the crazy variation in the later samples of the run?
Measured monitor refresh interval from VBLsync = 16.682252 ms [59.943945 Hz]. (50 valid samples taken, stddev=0.499833 ms.)
That timing is almost certainly broken, from all the output you posted. Far from the 2 msecs tolerance, more like randomized 16 - 50 msecs errors. If you installed the PsychtoolboxKernelDriver, as the software adviced you, it would likely produce way more warning messages wrt. the broken visual timing.
It’s baffling why the script didn’t abort with sync failure btw., as a stddev > 0.2 msecs is almost certainly indicative of timing failure, so I don’t know why it passed with 0.499 msecs in the first place - normally this would cause an abort. What is clear is that the timing on this machine is unusable broken. Update: Probably not baffling, as what you did is likely setting up for use with the desktop compositor, judging from that other discussion thread, by setting a custom window size that wasn’t considered fullscreen. In that case, PTB would have printed warnings towards use of the compositor and broken timing, and also increased its tolerance for timing jitter stddev of up to 1 msec to keep going, assuming you are able to read and comprehend warning messages and adjust your expectations accordingly. You didn’t post the actual PTB output, but I’m pretty sure that’s what happened. Reading helps…
The way to maybe fix this (no guarantee!) if you absolutely have to stick to macOS is to buy support for further advice on how to deal with this on the latest PTB version → help PsychPaidSupportAndService.
See Mario’s advice - much more informed than myself, but we switched away from using an older Mac long ago; really could not get a concrete resolution to the timing issue, but we did not consult Mario.
Switching away is the better solution, but this specific issue would have had a reasonable chance of being fixable in some way, with cooperation of the bug reporter for additional diagnostics - and payment for my time doing so. This specific issue is a case of “you get what you pay for”…
As Mathworks sponsored this, Psychtoolbox 3.0.19.4 contains a potential workaround for this specific type of macOS brokeness, which may or may not help to use such a Matrox Dualhead2Go setup while retaining proper visual timing and timestamping. This is untested due to lack of hardware, and unsupported in case it doesn’t work, but here it goes:
UpdatePsychtoolbox to the latest PTB 3.0.19.4.
Set your DualHead2Go display to the resolution you want, ie. 3840x1080 in your case.
Add the statement Screen('Preference', 'ConserveVRAM', 2); before the Screen or PsychImaging ‘OpenWindow’ call. See help ConserveVRAMSettings, the section about kPsychDontSwitchToOptimalVidMode for explanation of this setting.
Do not specify a window size in ‘OpenWindow’, the default size selected by omitting the parameter or setting it to [] is what allows proper operation.
Twist your fingers and hope for the best.
Obviously you need the PsychtoolboxKernelDriver for macOS properly installed (help PsychtoolboxKernelDriver) for Psychtoolbox to be able to test if this gives you proper display and proper visual stimulation timing/timestamping. Otherwise PTB can’t check carefully and you might still fool yourself into producing data trash instead of proper data collection, just as would happen with any other vision science toolkit than Psychtoolbox.
All this only applies to Intel based Macs, as timing is broken on any Apple Silicon Mac under macOS with any toolkit in existence atm. as far as I know.
Let us know if this actually fixed the problem properly.
