Timing problems with gUSBampSource and P3Speller

[OKI]

Hello,

we started developping on the BCI2000 version 3.0.0 and finished with our programming.Now we started our experiments, and noticed, that the programm doesn't work properly. I already posted, that the programm doesn't run on our normal experiment computers:

http://www.bci2000.org/phpbb/viewtopic.php?f=8&t=955

We changed the computers, and the programm worked fine on the first view.
But while we did our experiments, we noticed, that the programm runs with different speeds. I tried a downloaded version of the BCI2000 V3 that already was compiled, but the same errors occured.

Sometimes the programm runs faster, and sometimes it slows down. This causes, that wrong targets get selected.
I don't think that the computers are to slow, first there is no Runtime Error (Roundtrip Time excceeds) and second the programm also runs too fast sometimes. Indeed, it changes its speed during a run.

We use the P3Speller, P3SignalProcessing, the Operator, and the gUSBampSource Modules.

Most of the computers run with Sophos Security, has anyone experience with BCI2000 and Sophos?

And why else, can the BCI2000 have this behaviour?
Thank you for answers.

[OKI]

We did some more research.

Here we tested the two working versions.

I don't know why its working sometimes better (first plot of version 3.0.0) and sometimes not.

Might a notebook hard drive with 5400prm slow the system down?

[griffin.milsap]

How was this data collected? Were you using PrecisionTime or some other sort of software timer?

What was the difference between the first BCI2000 3.0 run (where it was "working fine") and the second?

We have a pretty sophisticated setup at the lab over here called BCI2000Certification which was set up by Dr. Adam Wilson. (http://www.bci2000.org/wiki/index.php?t ... edirect=no) This system certifies the latency and jitter of the processor, audio output, video output, and amplifier using external hardware. We used this system to certify timing on BCI2000 3.0 before we pushed it out the door. We havn't used it seriously since then, so it's possible that a change somewhere along the line popped up which changed these timings that we didn't catch.

Internally, we're working out a new release schedule which would ensure that comprehensive timing testing would occur every 6 months (these tests take a significant amount of time and labor to perform). Hopefully, once this is implemented, these timing issues won't crop up in the most recent (stable) version.

-Griff

[OKI]

Dear griffin.milsap,

we recorded those data by an external phyton script.

It is a bit courious, because the first record, was from the self written application and operator module. But i think, that is was an absolute hazard, that it worked fine. Like the timing is not allways that bad.

Moreover, we discovered, that the performance was in addiction of the CPU and harddisk speed.

Before we had those timing problems, we used an DELL notebook with Core i5 @ ca. 2.5gHz, 4gb ram and a 5400rpm hard disk.
Now we use a desktop computer with Corei5, 8gb ram (3.5gb used (x84)) and a 7200rpm hard disk.
With those new settings, the timing is perfect, and changes in a range lower than a milli second.

What i would suppose, is that writing the EEG and logfile data to the disk is causing the timing problems on slower disks.
Like in the other thread that i posted, where properly a RAID system makes the gUSBampSource.exe module crashing, i would advice you, to check the writing of the data to the disc in those modules.

What i also wanted to ask, is if there is a profiler (or a profiler tutorial) aviable for the BCI2000 and MSVC2008 Pro?

Thanks for your reply,
Stefan Völker

[mellinger]

Hi,

there was a bug in the 3.0.1 (May) version of the gUSBamp source module that could result in irregular timing. Especially, it could speed up data acquisition as well as slowing it down, as you describe it. Please make sure you are using the 3.0.2 (June) build for your experiments.

Generally, data rates when recording from an EEG system to disk are much below those required by standard applications such as playback of high-definition video. I don't think there should be any problem with this in BCI2000. Of course, when writing to disk, there is always a possibility that overly eager virus detectors are intercepting, possibly slowing down write operations.

For a useful light-weight profiler, see http://www.lw-tech.com/. It can be used to profile any program that has been compiled in debug mode. It uses statistical profiling rather than instrumentation, so it is small and efficient. To use it, compile BCI2000 in debug mode, start up any configuration you like, start ltprof, and attach it to the BCI2000 module you would like to profile.

Regards,
Juergen