Skip to content
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

Open
glowtape opened this issue May 15, 2018 · 10 comments
Open

Comments

@glowtape
Copy link
Member

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.

@glowtape
Copy link
Member Author

Eh, I spot this only now, 5388fe3 is a small patch applying to b0b70c5 .

@glowtape
Copy link
Member Author

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.

@glowtape
Copy link
Member Author

OK, what I've noticed is that per TaskInfo (reverted vs next):

Actuator 12% -> 13%
Attitude 26% -> 29%
Stabilization 28% -> 30%
ManualControl "0%" -> 1%

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.

@glowtape
Copy link
Member Author

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:

  1. Only board powered, no receiver: 50%
  2. Only board powered, receiver on, armed in LQG rate: 55%
  3. Whole quad powered (for the OSD IRQ to hog CPU), receiver on, armed in LQG rate: 70-71%

With next:

  1. 57%
  2. 62-63%
  3. 78-79%

With the things above reverted:

  1. 52%
  2. 57-58%
  3. 72-73%

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.

@glowtape glowtape changed the title F3 targets have higher CPU usage, likely related to telemetry changes. F3/F4 targets have higher CPU usage, likely related to telemetry changes. May 20, 2018
@glowtape
Copy link
Member Author

glowtape commented May 20, 2018

So next with #2210 brings some slight improvements, the CPU usage got slightly lower.

  1. 55%
  2. 61%
  3. 76-77%

@glowtape
Copy link
Member Author

#2210 doesn't seem to have an effect on SPRF3e idle CPU usage, which stays at 76-77% regardless.

@glowtape
Copy link
Member Author

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:

  1. 51%
  2. 56-57%
  3. 72%

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.

@glowtape
Copy link
Member Author

Nevermind, PIOS_Thread_Period_Elapsed() is new.

@glowtape
Copy link
Member Author

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.
https://github.com/d-ronin/dRonin/blob/next/flight/UAVObjects/inc/uavobjectmanager.h#L120

@glowtape
Copy link
Member Author

With #2210 and #2211, SPRF3e idle CPU usage went to 68-69%. It used to be 67% a few weeks back, but more stuff went into stab.c meanwhile.

As for Seppuku:

  1. 50%
  2. 55%
  3. 69-71%

@mlyle mlyle modified the milestones: Inconceivable, Ludicrous Jul 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants