CPU time increase after long runtime
In the last weeks I did some lonely MTB trips and notice a decrease of battery runtime from 17 hours to 12 hours screen on time compared to my Android ROM benchmarks, by using mostly only my high contrast dashboard with low LCD brightness.
I thought my battery was already worn out because I did modify my firmware to skip android auto shutdown and keep draining battery until the protection circuit cuts the power to get ~5% more runtime. But I could reproduce my 17 hours time in a controlled environment and even better, I could measure cpu time differences between my test case and a more real usecase by feeding the gps simulation with my real data.
First of all, there is a difference between receiving 36.000 GPS points from roughly same location and 36.000 GPS from different locations.
- Different positions do force map render time
- Different positions do rotate map
- Different positions do increase recording track length
I could fix the first 2 points
- disable map rotation during dashboard usage
- disable center position during dashboard usage
But after benchmarking this improved setup I found out that guidance does take extra cpu cycles and a fresh started locus maps does use much less cpu cycles than an instance with already some hours of runtime. I'm not sure what's the reason, because I can't execute many long-running use cases.
Don't blame track recording right now, I didn't prof it so far, but at least I found out that something is keep increasing battery drain over time. Could be a reason because calculating 36.000 points is more expensive than calculating 3.600 points.
I did four 90 minutes tests with closing locus process after each run and one 360min test with 4 segments. The 360 minutes run did keep increasing cpu times after each 90 minute segment
More context for the Data:
- I did use a 90min long nmea file with nearly static position for the stay tests
- I did use a 15 hour long GPX track for guidance
- I did use a 90min long cycle ride nmea file for the move tests (does match to the first 10% of the gpx track)
- I have sensor debug logging allways enabled to keep high precision pressure measurements with 5Hz, so my cpu times are maybe a bit higher then usual
- All tests are done on a v3 vector map, except the online tile map test
- measurements was done with /proc/[pid]/stat
I could send you all my Testdata (2 nmea files and the gpx track) via email if you like.
At the end of week I try to find out what happens without track recording and what happens without sensor debug logging.