Closed sudorook closed 9 years ago
The above plot was from RTXI 2.0 (3.8.13-xenomai-2.6.3). Below is a plot obtained in an identical fashion for RTXI 1.4 also running on 3.8.13-xenomai-2.6.3. I hit reset on the performance module around 10000 us.
This is from RTXI 1.4 w/ RTXI. I hit reset in the middle. The comp. time falls to 0 at the end because I didn't stop recording before I closed the module.
The performance measurement module wasn't computing variance correctly. I fixed it. Here's what the stats are like on RTXI 2.0 running on 3.8.13-xenomai-2.6.3.
I don't think I did anything in the middle. The second plot's y axis is mislabeled. It should be jitter.
All the above plots should have their y-units changed from us to ns.
Also, the performance measurement module was using a moving 'average' to calculate everything, i.e.:
duration = .9 * duration + .1 * (now - lastRead);
I fixed it in my last commit. The reported computation times are lower, as expected, and the severity of spikes are reported as higher. Also, I noticed that huge comp. time spikes (~6000-7000 us) occur then maximizing/resizing the RTXI window.
Plots for good measure... (RTXI 2.0 w/ 3.8.13-xenomai-2.6.3)
There aren't any more detectable issues with the Performance Measurement module. What remains to be done is for me to rewrite the Data Recorder so it doesn't run on its own thread.
Performance enhanced in latest commit. Recording @ 10 kHz.
Running the Data Recorder causes the Performance Measurement module to spike its readings for computation time, jitter, etc.
Open everything in RTXI, reset the Performance module, and then record (at 10 kHz). The values on my machine are unreasonably high. The blip in the middle is when I reset the the Performance Measurement module.
I've been able to reproduce this issue on several other machines, including ones with RTXI 1.4 installed. It occurs solely when the data recorder is running, not with others.
The data recorder runs on its own pthread. I don't know why.