[visionegg] Re: "Realtime" process priority in Win2K

Martin, I didn't follow your thread exactyl, but I had the same problem with linux: using high priority, the mouse was not available any more, therefore I built a button-box which I put to the parallel-port, since parallel-port polling still worked

cheers
christoph
Martin Spacek wrote:

Hello again with another long email,

This is probably known by some, but I thought I'd report it anyway,
since I wish I'd known about it sooner. Running VE with
VISIONEGG_MAXPRIORITY = 1 in the .cfg file in Windows 2000, we were
getting quite a bit of variation in the timing histogram, including
frame drops, depending on what was left running in the background, such
as a firewall or even something as benign as a text editor. This
variation correlates near-perfectly to what we can observe on an
oscilloscope, comparing the digital out lines toggling within the code
and the vsync signal coming from the video card. Even with only the
absolutely necessary windows processes running, if allowed to run long
enough there would almost always be some windows interruption that could
last up to a few ms. This is bad, since we never felt confident that
during a long experiment we wouldn't get a frame drop at 200 Hz display.

Then I stumbled across the code in PlatformDependent.py. If the process
priority is changed from:

win32_maxpriority.set_self_process_priority_class(win32_maxpriority.HIGH
_PRIORITY_CLASS)

to:

win32_maxpriority.set_self_process_priority_class(win32_maxpriority.REAL
TIME_PRIORITY_CLASS)

all of a sudden the machine runs like a DOS box, with nearly no
variation in execution time (less than 0.5 ms between vsyncs), in spite
of leaving tons of stuff running (er, suspended) in the background in
Windows. Unfortunately, this also resulted in no keyboard response
during presentation. I guess VE dominates the system so completely that
windows can't even capture input device events. I got the keyboard back
by changing the thread priority from:

win32_maxpriority.set_self_thread_priority(win32_maxpriority.THREAD_PRIO
RITY_HIGHEST)

to:

win32_maxpriority.set_self_thread_priority(win32_maxpriority.THREAD_PRIO
RITY_IDLE)

with only about a 0.5ms increase in variability. We thought we'd have to
go out and buy a 2 GHz machine or something just to reduce the chance of
a frame drop. Now we're completely happy with our Athlon 700 MHz
machine.

I was wondering though, does anyone know of a way to recover keyboard
function while still leaving the thread priority at something higher
than just IDLE? I wouldn't mind getting rid of that extra 0.5 ms of
variation :) I'd also be interested in locking out mouse events (which
also happens at higher thread priority), since mouse motion increases
variability during presentation.

Cheers,

Martin Spacek
PhD student, Graduate Program in Neuroscience
Dept. of Ophthalmology and Visual Sciences
University of British Columbia, Vancouver, BC, Canada
+1-604-875-4555 ext. 66282
mspacek@xxxxxxxxxxxxxxx
http://swindale.ecc.ubc.ca

======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html


======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: