Frame loop slowdown on Ubuntu 16.04

1

I am observing a slowdown of code in my frame loop when calling Screen('Flip',...) with the optional 'when' parameter in ptb3+Matlab on Ubuntu. I have attached a minimal test script, testFlip.m, that illustrates the effect.


The test script does very little other than call and time the rand() function before each call to Screen('Flip',...). Execution of rand() is ~5 times slower when Screen('Flip',...) is called with the 'when' parameter (first page in the attached .pdf) compared to when it is called without the 'when' parameter. I have attached a couple of figures which show histograms of rand() execution times (from the attached test script) for the two conditions. I see the same effect for functions other than rand(), including other ptb operations such as Screen('DrawDots',...).


Is this known and expected behaviour or is this a peculiarity of my system?



I'm running psychtoolbox (from NeuroDebian) in Matlab 2016a on a clean install of Ubuntu 16.04.1 LTS, with the lowlatency kernel.


'uname -a' reports:


Linux ns2 4.8.0-53-lowlatency #56~16.04.1-Ubuntu SMP PREEMPT Tue May 16 02:33:53 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux


PsychtoolboxVersion reports:


3.0.14 - Flavor: Debian package - psychtoolbox-3 (3.0.14.20170103+git6-g605ff5c.dfsg1-1~nd16.04+1)


The machine has an Intel Core i7-7700 CPU @ 3.60GHz x8, 32Gb RAM and a GeForce GTX980Ti/PCIe/SSE2 video card (running at 60Hz). I'm using the closed source NVIDIA Driver version 381.22.


CPU usage of the MATLAB process is 99-100% when testFlip() is calling Screen('Flip',...) without the 'when' parameter but only 40-50% when it is calling Screen('Flip',...) with the 'when' parameter.


Any thoughts, comments or suggestions would be most welcome.


Rgds,


Shaun

Monash University


2
XX---In PSYCHTOOLBOX@yahoogroups.com, <xsoh45mzfyvhgvurlrbp7lkm6hn6yt5wupmugs6w@...> wrote :

Thanks Mario, that is quite useful.

Based on your insight I set the frequency governor to "performance". For posterity, I've attached here two figures showing the new output from testFlip.m calling Screen('Flip',...) with and without the 'when' parameter. As can be seen, the "performance" governor eliminates the discrepancy previously seen using testFlip.m.

-> Good!

A couple of points which may (or may not) be of interest:

1. I don't think this is (or was?) just a hypothetical performance problem - testFlip.m is just the simplest script I could come up with that illustrated what I think is/was the cause of a very real performance problem for our stimulus code. Existing stimulus code running well on Windows 7 was dropping ~10% of frames on Ubuntu (with the two machines running identical hardware).

-> I didn't mean to imply that, i was just asking. The same problems can happen on Windows, depending on machine and driver versions in even worse ways. Cfe. message 22016 where we just had the same situation on Windows-10 + NVidia.

Modifying our code to call Screen('Flip',...) without the 'when' parameter eliminated the dropped frames (based on the VBLTimestamps returned by Screen()).

With the "performance" governor I now get no frame drops for the original stimulus code on Ubuntu.

-> I probably will look into adding some automated setup code in a future PTB release to deal with this more automatically.

2. Our actual stimulus code does many things in the frame loop (much much more than testFlip.m). As you suggest, in practice that should cause the "ondemand" governor to ramp up the cpu frequency, but evidently does not (or at least not enough).

3. testFlip.m produces near identical results when calling Screen('Flip',...) with and without the 'when' parameter on Windows 7. Presumably this is due to differences in the implementation of the Nvidia driver and/or handling of cpu frequency scaling on Windows vs Linux.

-> Yep. The algorithms used, and their tunable parameters, vary widely between operating systems, drivers and type of gpu and cpu. In general the problem seems to get worse the more modern the cpu/gpu and the more processor cores a cpu has, as power-management becomes way more complicated and agressive to squeeze out more performance without melting the machine. That's why problems seem to show up more frequently on higher end machines like yours.

-mario

In any event, thank you for your help.

Rgds,

Shaun