Closed tfoote closed 7 years ago
Leaving it running in the good state it even accelerates to 2% of the time blocking (note the markup is wrong it's a raw fraction not a percent.) But we're now turning over at ~500hz which is where gazebo is throttling.
Freq: (499.533017) Average[max] wait 0.001957[0.002113], acting: 0.000045[0.000137] blocking: 0.022438 %
Freq: (499.086621) Average[max] wait 0.001959[0.002107], acting: 0.000045[0.000138] blocking: 0.022306 %
Freq: (499.485427) Average[max] wait 0.001957[0.002091], acting: 0.000044[0.000143] blocking: 0.022220 %
Freq: (499.154332) Average[max] wait 0.001960[0.002104], acting: 0.000044[0.000136] blocking: 0.021923 %
Freq: (499.790161) Average[max] wait 0.001955[0.002090], acting: 0.000046[0.000207] blocking: 0.022842 %
Freq: (500.412685) Average[max] wait 0.001954[0.002058], acting: 0.000044[0.000130] blocking: 0.022104 %
Freq: (498.079670) Average[max] wait 0.001957[0.002170], acting: 0.000050[0.000138] blocking: 0.025108 %
Freq: (499.430709) Average[max] wait 0.001956[0.002105], acting: 0.000046[0.000128] blocking: 0.022845 %
Freq: (501.932552) Average[max] wait 0.001950[0.002101], acting: 0.000042[0.000106] blocking: 0.021314 %
Freq: (498.355451) Average[max] wait 0.001962[0.002106], acting: 0.000045[0.000149] blocking: 0.022254 %
Freq: (498.095049) Average[max] wait 0.001961[0.002109], acting: 0.000047[0.000141] blocking: 0.023166 %
Freq: (499.412869) Average[max] wait 0.001955[0.002161], acting: 0.000047[0.000144] blocking: 0.023525 %
Freq: (499.373626) Average[max] wait 0.001955[0.002080], acting: 0.000048[0.000134] blocking: 0.024070 %
Freq: (499.483048) Average[max] wait 0.001959[0.002095], acting: 0.000043[0.000147] blocking: 0.021529 %
A potentially related issue is that after 15 mintues of running slowly (cpu time) gazebo got noteably faster and went from 26% CPU to 100% CPU. (trial with 50 drones) And at that point everything got much more responsive.
Here's some timing: starting the first set of drones slowed it down for ~100 seconds the 2nd set of drones ~ 250 seconds: https://gist.github.com/tfoote/5fd7190d22f80f9af663a43fd7a175ac
With more debugging I've found that ardupilot is updating about 40 out of 41 times in well under 1 ms. However in that remaining cycle it blocks for 100ms which blocks gazebo for 100ms too.
Here's a full gist: https://gist.github.com/tfoote/8fc39ed2cb07b582ca75a98f3de26141 and the branch with instrumentation: https://github.com/tfoote/ardupilot/tree/instrumenting_sim_gazebo
We found the slowdown of 100ms every 40 frames: https://github.com/tfoote/ardupilot/commit/0b38166bc7c48c920e572726346bfa882d4ba8ce
After running that we're still seeing generally slow behavior but the large gaps are gone. I'm going to try larger tests.
There were two fixes. One was to remove the long sleep in ardupilot. tfoote/ardupilot@0b38166 And the second is to enable sim time to keep things synchronized #104
Loading and unloading plugins still slows down the simulation but that's expected.
Sometimes the simulation seems to run much slower. I've been able to isolate it that if you launch a drone a 2nd time, the ardupilot does not speed up after "Ready to Fly" When in the first run it goes from 50% blocking to ~10% blocking. And in the 2nd run there's no noticable speedup, which slows the simulation down greatly across many vehicles.