Sorry, I haven't had an opportunity to test drive.
But to better understand what happens I did some basic tests.
I simulated short periods of vibration/shock by moving the laptop.
Status of hdd protection was observed with the protection process gui.
It shows the orientation of the laptop and the measures taken
(hdd running, paused, protection suspended; see "RR freeze on vibration - display.JPG").
My findings so far, with fast polling used (12 parameters @ ~17.5 samples/s):
CPU load with my test set of parameters and no graph output: variable ~5-20%.
CPU load with maximum graph output: ~60%.
There are three problems:
a) frozen program for short periods of time
In trace mode RR freezes completely as long as the HDD is offline (due to shock protection).
No data sampling, display, systemlog or data file writes occur.
This is true for logging data to HDD or USB.So it seems (paused) writes to the sytem logfile (still on HDD) do block the whole process!
In the log files big time gaps can be seen.
If RR then resumes it processes buffered messages from the interface as fast as possible.
In that situation some samples get the same time (like problem b).
Looks like some messages are processed within a msec or the granularity of time is not good enough.
(see "RR freeze and resume - data.JPG")
b) more than one data sample per timestamp
Occurs independend of system logging (info level used).
In the data log I see that data samples with the same timestamp occur in periods of jitter.
I suspect that RR wasn't able to process the data in time (blocked, CPU load etc.).
May be related with graph output CPU load.
If RR resumes it processes buffered messages from the interface as fast as possible.
Same as with problem a) but depending on sampling intervall and delay for just 2 or 3 data samples.
It's is getting worse if the sampling intervall gets shorter (fast polling, fewer parameters, better interface)
or the computer being slower (running on battery power wo high speed setting).
c) big leap back in time (and frozen graph output for long periods of time)
Still don't have an idea for that.
There are no anomalies before or after the leap.
Maybe a bug in the timing code?
Solution for a)
Point the rr_system and data logging dir to USB (how to do for rr_system.log?).
Use a SSD.
Don't trace while logging.
Don't drive while tracing
Solution for b)
No other processes that load the laptop (graphics, cpu, disk etc.).
Use slow polling.
Don't graph too much (window size and count of parameters matters) - to be confirmed.
Use high speed energy scheme even while on battery power.
Buy a faster laptop.
Will give the data logging to USB (@INFO level) a try when my car runs again after the injectors have been swaped.
I'm curious if continued vibration adds to problems b and c.
Cheers
- matze -
