-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
F3/F4 targets have higher CPU usage, likely related to telemetry changes. #2200
Comments
Yeah I don't get it. Right now on latest next, it idles at 77% with no config at all. When I revert the recent change 2637207, which gives back 3%, and the other two changes above, I drop to 70%. I've been looking and prodding at it, and I don't get it. |
OK, what I've noticed is that per TaskInfo (reverted vs next): Actuator 12% -> 13% The interesting thing is that the job these tasks do is very definite and on a timer. The amount of UAVO accesses should not vary per tick, neither do the changes look like they'd do more work. If at all, they'd do less, because throttled queues aren't potentially updated as much. |
Ugh, it has an effect on F4, too. I went to do some logging with some lean custom logging profile, the sort that didn't use to flash the CPU warning (at 166hz), but now it does (at 100hz). So I've installed the LQG test build from the forums, the CPU usage on my Seppuku was this, logging disabled though:
With next:
With the things above reverted:
I figure some remaining overhead in the third case comes from the vertical thrust stuff and probably moving BMI160 from interrupts to polling, that weren't present in the forum build. |
So next with #2210 brings some slight improvements, the CPU usage got slightly lower.
|
#2210 doesn't seem to have an effect on SPRF3e idle CPU usage, which stays at 76-77% regardless. |
Latest changes in #2210 bring F3 idle down to 71-72%, whereas with the reverts, it's 70-71%. So that definitely did something. As for the Seppuku:
It's practically fixed, but it appears we're optimizing other things to make up for it, since PIOS_Thread_Systime() was always in use. Later today I'm starting with next and am going to knock out things in the commits above on next bit by bit to find what triggers it. |
Nevermind, PIOS_Thread_Period_Elapsed() is new. |
OK, I think I've tracked it down. I've knocked out everything by commenting out, CPU usage stayed high. The mere commenting of this line dropped the CPU from 77% to 72%, even though that pointer wasn't in use anymore, because of having commented out other things using it beforehand. |
Several users have been mentioning higher CPU usage on the F3 targets lately. Most recent reporter Maquiabelo, where it seems to be causing a critical CPU alarm, and also claims to be unable to arm (presumably due to critical CPU). Two quads using a micro F3, running the Omnibus F3 target.
The UAVOs are attached to this issue, but I haven't looked into it yet. spc95.zip
I'm seeing something similar. When I install an older build on my SPRF3e, it idles at 67%, and with next, it's at 80%. With erased settings both times (LQG, FlipOver and Motorgain don't seem to be responsible for the brunt of it).
I'm currently busy identifying a bunch of CPU time sinks, which may or may not happen only with the GCS attached. It seems like two commits are responsible for the bump on my SPRF3e, each worth around 5%:
b0b70c5 telemetry: throttled obj can only be in queue once
5388fe3 uavobjectmanager: improve timer math
The issue with latter one was identified over on IRC, altho it brings the additional CPU from 4-5% down to 1.5-2%, not nearly zero, so there's still a minimal effect on that one.
Former seems unclear.
Maquiabelo has an OSD on his Omnibus. I figure its presence seems to send things over the edge together.
The text was updated successfully, but these errors were encountered: