what is causing (a) slow frame rate and (b) spontaneous NVIDIA stereo off

[billjarrold]

Hello,

A new issue. (We - at UC Davis - have a support contract and I have posted this message there. However, I'd like to get multiple opinions / suggestions on this complex issue, thus I am posting to this list)

SUMMARY: I have a slow frame rate on one machine but not the other machine. I am 80% sure the machines are hardware identical. Additionally the slow machine has recently spontaneously changed its stereo mode enable parameter to OFF. I give detail history context behind these issues, I suspect they are related but would be interested in any opinions thoughts reactions.

FULL VERSION:

Paul, thanks for your phone support yesterday!

All, yesterday our system was stuck in 2D mode. Paul diagnosed the problem as the NVIDIA. I went into it (click right on desktop, chose nvidea) and changed "stereo enabled" from "off" to "on".

3d mode worked after that.

My concern now is WHY this would have changed?

There is a lot of history that may be relevant to this question.
Please read on.

When Paul and I spoke yesterday, our theory was that when we installed
the new nvdia drivers on during our call of june 28 that this caused
the stereo enabled to be defaulted to off.

This would mean that during every test run I did since then during my
testing of the new study I would have failed to notice that 3d mode
wasn't working. Sort of plausible as I was focused/ concerned with
other functionality than 3d vs 2d. But this is much less plausible
when considering that our VR operators who have run ~ 150 participants
in prior studies never noticed the problem until yesterday.

Thus it seems overwhelmingly likely that the evi switch NVIDIA stereo
enabled off was NOT caused by the update of NVIDIA software. Rather
it seems that it just started happening as a kind of random flakiness.

My question is WHY would this ever happen and why would it be
happening now.

No one in our lab including me had any clue about this parameter or
how to change it until yesterday's call with Paul. Thus, no one would
have tweaked it.

It seems if it happened de novo yesterday it is likely to happen
again. That would be very bad. We can not afford to have a flaky
system as we are starting a large 4 year study. Sure, we now know how
to fix this if it happens again but what ELSE is now going to flake
out on us?

Any theories on what could have caused the change?

Here is my theory:

Sorry this is long.

Back in 2009 when Worldviz helpfully installed our system, this
machine started out life in our lab as a machine designated to be
machine that would have fancy graphics drivers to support a mini-Cave
like system made with somethign like 3 large flat screen tvs arrayed
in a Cave like format and using 3d goggles. If this were to happen it
was very likely we'd want different graphics hardware onboard than it
had at the time. Paul and the other person who did the install in Sept
of 2009 took that box back to Worldviz. We were to decided on what
exactly to put into it (in terms of a new graphics driver?) to support
the Cave like context it would hopefully someday serve us. (At least I
*think* that is why it was sent back to Santa Barbara).

Then Peter and I had to decide exactly what kind of config we wanted
for this machine. We dithered. For months. Maybe even a year.

Next, Worldviz quite politely contacted us and said "what do you want
to do with your box that we have here for you?" We decided, "Oh well,
just ship it back. It looks unlikely that we will ever make this
Cave. We will use whatever graphics is on it." or "Put whatever
standard thing you put on these guys."

So, the machine was shipped back to us and the sat for a few more
years unused.

Then I needed the machien on a different project (just plain audio
transcription).

To use it this way, I had to physically move it to a different lab.
It was put on a different network as part of the medical school/health
system. They have a HUGE user base and a HUGE security issue
(bjillions of patient records). In order to be on their network they
did somethign to the box. I'm not sure exactly what they did as part
of their standard operating procedures by a sysadmin guy came by and
messed with it for minutes to hours.

One important reason they did whatever they did is a precautionary
security meaure. I.e. IF the box is stolen, the theives will not be
able to read the hardrive. I think its contents are somehow encrypted.
When someone logs in (the system was connected to the medical school
internet) then and only then can they read the hard drive. Anyone
know what this might be? Does this procedure / technology have a
name? Perhaps I shoudl contact UC davis health system / medical
school technical support?

A few more months went by. Then we no longer needed it in that lab.
I asked the medical school to undo whatever they did to the box. The
guy said "Do you want me to re-format the harddrive?" I said no way
!!! (Not wanting to do a re-install. I'm not systems guy --
terrified of this stuff, especially on windows). So he unddid
whatever it was that he had done and now we could use the box without
having to use the special medical school login capability.

Then about 6 months ago I brought the box back to its original home at
the SAV Lab at the Center for Mind and Brain. I transfered the
license to it a few months ago with the help of some combination of
Phil S, Paul E. and Jeff L. The VR seemed to work fine and was used
for the tail end of Fade Study 2 (our main study 2 Machine seemed to
be contanimated by some VR software by USC - that is a whole other
long complex story).

Then about 1 month ago we started a new study. I noticed a jerkiness
in the view as I would pan back and forth. I hit F4 and noticed a
slow frame rate in the slightly tweaked code for our new study
(i.e. Fade Study 3). Then I went back and fired up Fade Study 2 code.
Again, we had a slow frame rate. Sometimes it got down to 30 FPS.
More often in the 40 to 50 range. I hit F4 twice and see that the
slowness was about 60-70 % caused by "Draw" (i.e. graphics rendering)
and the remaining 30 to 40% caused by "Update" (my python code).

More precisely: Update would vary between 4 and 9 ms on this machine
(Kimputer) and 2-4 on Albert (one of our older reliable machines where
no slow jerkiness was noticed).

Draw is a measure of milliseconds the system spends rendering images
in the system. It ranged between 1 and 14 on Kimputer and 0 and 2 on
Albert.

This is why I said 60-70% caused by graphics and 30-40% caused by
"update".

So, this slowness problem remains unsolved.

I thought all our three boxes were identical in terms of hardware.
Were they identical?

What could be the cause of slowness on one machine and not the other?

That brings me to yesterday. Like I said above, yesterday this
machine (Kimputer) decided to randomly switch into stereo enabled off
mode.

So, here is what I am thinking:

The slowness and the the flaky switching into stereo enabled off mode
are *both* caused by whatever the medical school did to the computer.
The fix, or at least the next diagnostic step to perform is to
reformat the hard-drive of this machine (i.e. Kimputer) and, sigh,
re-install Windows-XP, Lab Tool, Vizard, Tortoise (version control
GUI) and hopefully not much else! This fix has, I guesstimate a 40%
change of fixing the problem.

Is this a good path? Is there a better path, i.e. can anyone suggest
an action that will take us above a 40% chance of fixing the problem?

Maybe the slowness and the change in NVIDIA stereo enabled are
unrelated i.e. caused by two completely separate problems. Any
thoughts on the likelihood of this?