Change Windows 7 timer resolution

[JDF]

Hello, I've been having timing issues with PsychoPy (versions 1.80.03 and 1.80.05).

I'm using a CRT monitor with a refresh rate of 100 Hz, and working on a computer running Windows 7 OS.

I noticed that my script was taking longer than it should, and when running PsychoPy's "timebyFrames" script, it indicates that the frame duration is 15.6 ms, so a temporal resolution of about 64 Hz. After some Googling, I found that 15.6 ms is the default timer resolution of Windows 7. Perhaps I need to set Priority for my script functions (tips would be helpful; I'm new to PsychoPy).

..Still, I've noticed that the phenomenon is variable. For instance, I uninstalled my PsychoPy 1.80.03 and downloaded the updated version. After the install, "timebyFrames" showed a resolution of 10 ms, but then subsequent runs of the script showed 15.6 ms. A similar thing occurred when I adjusted my monitor's resolution: it worked, and then it didn't. Moreover, our lab has 3 identical computer models with duplicate HDs and identical CRTs, and only two of them have this variable problem with time resolution (all were running PsychoPy 1.80.03 until the first was updated). The other one is consistently 10 ms, as is another computer running Windows XP.

Please help. I'd appreciate any insight into this matter.

Thanks so much.

--Jeremy

[Jon]

Hi Jeremy,

I don't know about 15.6ms being the timer resolution on win7.

When I run the following script on my win7 (32bit) box I see very small increments in time being detected. (I also see periodically a larger time interval that increases, which I/m guessing is due to python resizing arrays in memory to cope with the large array of timeDiffs I'm storing)

from psychopy import core

clock = core.Clock()

t0=0

timeDiffs = []

while t0<3:

    t1=clock.getTime()

    timeDiffs.append(t1-t0)

    t0=t1

print timeDiffs[-5:] #print the last 5 diffs

import matplotlib.pyplot as plt

plt.plot(timeDiffs)

plt.show()

[JDF]

Hello, thanks for the suggestion. I ran the script you provided on a computer with the aforementioned timing problems and on one with no problems*, and I get the same results as you did (increasing time differences and intervals) for both computers.I don't think that that's related to the problem I have.

Interestingly, while testing timing in Matlab, I discovered somewhat accidentally that the PsychoPy timing issue goes away after the Psychtoolbox getframeTiming script is run, so long as Matlab continues to run while the PsychoPy scripts are run. Once Matlab is closed, the frame time goes back to 15.6ms rather than 10ms. The Matlab script is likely setting a priority that overrides the slower settings (presumably imposed by Windows) and allows the monitor's actual refresh rate to be used.

I probably need to learn more about setting priority in my PsychoPy scripts, but the fact that the Demo timing script yields the same problem is interesting, as is the variability from instance to instance (e.g., the timing looked accurate once after installing the newest version of PsychoPy, but running subsequent tests without changing anything showed the slower timing), and from computer to computer, despite identical setups.

Please let me know what you think.

Thanks!

--Jeremy


* Note: Attached for your reference are graphs plotted by PsychoPy's "timebyFrames" script for two computers: one with the problem (64 Hz), and one without (100 Hz).



On Thursday, September 18, 2014 4:54:11 PM UTC-4, JDF wrote:Hello, I've been having timing issues with PsychoPy (versions 1.80.03 and 1.80.05).

I'm using a CRT monitor with a refresh rate of 100 Hz, and working on a computer running Windows 7 OS.

I noticed that my script was taking longer than it should, and when running PsychoPy's "timebyFrames" script, it indicates that the frame duration is 15.6 ms, so a temporal resolution of about 64 Hz. After some Googling, I found that 15.6 ms is the default timer resolution of Windows 7. Perhaps I need to set Priority for my script functions (tips would be helpful; I'm new to PsychoPy).

[JDF]

On Friday, September 19, 2014 5:41:22 AM UTC-4, Jon wrote:

[Jonathan Peirce]

Actually I doubt this is to do with changing priorities or timing mechanisms. I suspect it's something to do with graphics card driver settings, like your graphics card doing something extra (filtering, triple-buffering etc.)

Mario Kleiner is the master of graphics cards and knows more than almost anyone about what all the different cards do and how to turn them off! Try in your graphics card settings to set things to high 'performance' rather than high 'quality' but keep the vsync setting turned on. The "quality" settings might make things look "nicer" but they take time and also mean that your graphics card is altering the image that you're trying to render to the screen (e.g. with antialiasing).

good luck and let us know if you find a critical setting that fixes the problem

cheers,
Jon

--
You received this message because you are subscribed to the Google Groups "psychopy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to psychopy-user...@googlegroups.com.
To post to this group, send email to psychop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/psychopy-users/45ce77c2-a070-4fbb-b989-5501eb4719e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JDF]

I thought this would do it, but the problem remains!
I tried various graphics card settings to maximize performance over quality, and nothing seems to work.
I was beginning to think that it might be a compatibility issue with Windows 7 and the ATI Radeon HD 2400 card, since the computers with problems have this OS/card combination, while the ones that work well either have a different card (3600), or run on XP. However, we tried a different computer with 2400 on Windows 7, and the timing is fine on this one.

[Jonathan Peirce]

I guess I'm glad it isn't a general problem, but I'm afraid I'm out of ideas for working out what's wrong.

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/psychopy-users/b61b4e1d-e4ba-4ee3-ad89-368a7ac58d91%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Jon Peirce
http://www.peirce.org.uk

[Sol Simpson]

Have you tried setting the priority of the process in your script to high before the timing critical section of the test is run to see if this changes the reported data? 

Based on your note on the PTB script exec. <-> psychopy timing data variability interaction, it may just boil down to this. Only trying it will let you know.

To set the priority of the psychopy process to high, you can:

   a) directly use the psutil module that is included in the psychopy standalone windows installer

   b) use iohub (which uses the psutil module)

iohub example:

# import the iohub 'Computer' device

from psychopy.iohub import Computer

# Set psychopy process to high priority

Computer.enableHighPriority()

######

# Time critical stuff

# .....

######

# Set psychopy process to normal priority

Computer.disableHighPriority()

#####

Just ensure that the user account being used to run psychopy has the rights needed for this. On WIndows 7, I /think/ a user can change the priority of processes they created without needing special rights. You may need admin rights though, I forget and can not check right now.,

[JDF]

Hi, and thanks for the suggestion. Unfortunately, this did not change anything.

For a while I have thought it was a priority issue. I found by chance while testing a script on Matlab that running the Psychtoolbox script "getFrameTiming" fixes the PsychoPy timing issue, as long as Matlab continues to run. Once I quit out of Matlab though, the timing issues resume in PsychoPy.

I also discovered, just by testing which of our scripts were affected, that the timing of one of our scripts works just fine, and oddly enough, it is the script's calling of the sound library via "sound.Sound()" that is the important factor. If we insert that call command into our other scripts, or the PsychoPy timing test script, everything works fine.

Both of these findings seem to point to priority raising, but so far the more straightforward attempts to raise priority (e.g., core.rush; this recent one with iohub) haven't proved effective.

Are there other ways to do so?

Thanks for your help.

Cheers,

Jeremy

[Sol Simpson]

Pretty weird that calling sound fixes the issue. ;)  

a) When you try and use rush or the iohub enable high priority, do you get any warnings in the console when the script ends indicating that the priority change failed?

b) How are you launching the python script? (Psychopy2 IDE, command prompt, some other IDE, ..?)

c) To try and see what is going on here, I would suggest running Task Manager. In Task Manager, you can use the "View -> Select Columns..." to select the process priority column. Then when you pick the Processes tab of the task manager, you should see the priority of each process. Sort the processes by name and ensure that processes starting with 'p' are visible, so that when you run your python script you will be able to see the python.exe process.

Then run a non full screen script in the different scenarios and see if any of them result in the actual python.exe process running at a priority other than 'Normal'. Report what you find. 

You may also want to look at the process list, sorted by priority, and see if in situations when you run the timing script and the timing is OK, if some processes are being lowered in priority (below-normal, low, ..). If so, would be interesting to know what you find. 

Thanks very much.

[JDF]

Thanks for the suggestions.

Mainly, I've been using PsychoPy2 IDE, but we've also tried this using Windows Power Shell and get the same results
.
We don't see any errors concerning priority. In fact, when I ran Task manager, I saw that the priority does indeed change to high when running the EnableHighPriority command via iohub. Yet the timing is off. Calling sound.Sound() doesn't change priority while running, yet it works. And curiously, using rush actually lowers priority, but the timing is the same as the iohub option.

I hope this helps. I'm more puzzled than ever though!

Cheers,

Jeremy

[Sol Simpson]

I hope this helps. I'm more puzzled than ever though!

Thanks for taking the time to run those tests. I am also more puzzled than before as well though!

Given the experiment priority (even if lowered) seems to have no impact on the issue you are seeing, it makes sense to conclude Jon was right about thinking process priority was not at issue here.

Could be worth while looking into the source code of the PTB util you mentioned that , when run, fixes the issue when the PsychoPy script runs as long as matlab is not closed. It may point to whatever is being done to resolve the issue. I will try to look into the source if I get some time, but that is iffy right now. 

 And curiously, using rush actually lowers priority, but the timing is the same as the iohub option. 

Sounds like this could be a bug. You could raise an issue about it from the psychopy/psychopy github project page.

Thanks again.