idf_monitor.py huge CPU load (IDFGH-1634) #3884
Comments
|
I have the same issue on Linux Ubuntu. Appeared after update to IDF 4 System: Linux ubuvb 5.0.0-25-generic #26-Ubuntu SMP Thu Aug 1 12:04:58 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux IDF: |
|
@no1seman @negativekelvin @pglen Sorry about this. It's due to the delay time too short here: https://github.com/espressif/esp-idf/blob/master/tools/idf_monitor.py#L493 Is there anyone can help me to test which value is proper on your OS? (Too large will cause the screen print delay/keyboarad respond delay, too small will use too much CPU resource) The unit is in second. |
|
@ginkgm, PS I'm using ubuntu 18.04.3 LTS with latest core: 5.0.0-25-generic (5.0.0-25.82) as a virtualbox guest on windows 10 with 4 virtual CPUs and 8 Gb virtual RAM. Hardware: i7-8550U with 16 Gb RAM. |
|
It should be |
|
with item = self.event_queue.get(True, 0.01) logs printing looks good with #define SOCKETS_DEBUG LWIP_DBG_ON and intensive network operations: 4-5% CPU core load. |
|
FIXED!
The processor was not breathing in the condition of no data. I inserted a
delay into the flow, so now the processor has a chance to relax.
See the line I added, marked in red in the code snippet below. I elected
30 milliseconds, as it is an optimum between as much delay as we can add,
and perception
threshold of the human observer.
Snippet from idf_monitor.py:
def main_loop(self):
self.console_reader.start()
self.serial_reader.start()
try:
while self.console_reader.alive and self.serial_reader.alive:
try:
item = self.cmd_queue.get_nowait()
except queue.Empty:
try:
item = self.event_queue.get(False, 0.001)
except queue.Empty:
# Let the processor breathe # Peter Glen 15/aug/2019
time.sleep(0.03) # Wait 30 millisec on no data
continue
(event_tag, data) = item
if event_tag == TAG_CMD:
self.handle_commands(data)
elif event_tag == TAG_KEY:
An even simpler change is to to remove the second .get, and add just the
time.sleep line.
*Please mention my name in the same spirit that prompted me to help.*
Peter Glen
…On Thu, Aug 15, 2019 at 4:17 AM Yaroslav Shumakov ***@***.***> wrote:
with item = self.event_queue.get(True, 0.01) logs printing looks good with
#define SOCKETS_DEBUG LWIP_DBG_ON and intensive network operations: 4-5%
CPU core load.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3884?email_source=notifications&email_token=AEMBG5GJHL5DROKUI4CRTCDQEUGKTA5CNFSM4IJVYYCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4LFJEQ#issuecomment-521557138>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEMBG5EVE43B5VZY2L7TVMLQEUGKTANCNFSM4IJVYYCA>
.
--
-- Peter Glen
Author / Inventor of official US Patent 'Adaptive Alpha Blending'.
Referenced by thirteen Multi Billion Dollar companies. (US20070103483).
This email is hereby declared confidential under the *Electronic
Communications Privacy Act *and the
*EU Lisbon Treaty.*
|
|
@pglen We usually don't put names into comments but you can open a Pull request for this and then your contribution will be logged in the form of a commit (including your name and email address). |
|
No worries. Glad I could help.
…On Thu, Aug 15, 2019 at 11:22 AM Roland Dobai ***@***.***> wrote:
@pglen <https://github.com/pglen> We usually don't put names into
comments but you can open a Pull request for this and then your
contribution will be logged in the form of a commit (including your name
and email address).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3884?email_source=notifications&email_token=AEMBG5GA33SZA3N74BM2C6DQEVYCJA5CNFSM4IJVYYCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4MDQGI#issuecomment-521680921>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEMBG5HU4Y3BULCSSK5T4JTQEVYCJANCNFSM4IJVYYCA>
.
--
-- Peter Glen
Author / Inventor of official US Patent 'Adaptive Alpha Blending'.
Referenced by thirteen Multi Billion Dollar companies. (US20070103483).
This email is hereby declared confidential under the *Electronic
Communications Privacy Act *and the
*EU Lisbon Treaty.*
|
|
@pglen there are two different queues so you don't want to remove the "second get". It is trying to block but uses the incorrect False parameter so the correct fix is changing it to True as shown above. Blocking is better than forcing a delay with sleep. |
|
The blocking is better, yes, but the serial implementation does not support
what you propose. (provides no event/semaphore) to block on / wait for.
The reason why the processor is clipping, is that the no data path repeats
the call too soon.
Waiting for 30 ms on no data is an option; killing the processor is not.
Peter
…On Thu, Aug 15, 2019 at 11:39 AM negativekelvin ***@***.***> wrote:
@pglen <https://github.com/pglen> there are two different queues so you
don't want to remove the "second get". It is trying to block but uses the
incorrect False parameter so the correct fix is changing it to True as
shown above. Blocking is better than forcing a delay with sleep.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3884?email_source=notifications&email_token=AEMBG5HOQZG4UDQYTXCUA7TQEV2B5A5CNFSM4IJVYYCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4MFB7Y#issuecomment-521687295>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEMBG5GYRLYTPFXSGRWO3YLQEV2B5ANCNFSM4IJVYYCA>
.
--
-- Peter Glen
Author / Inventor of official US Patent 'Adaptive Alpha Blending'.
Referenced by thirteen Multi Billion Dollar companies. (US20070103483).
This email is hereby declared confidential under the *Electronic
Communications Privacy Act *and the
*EU Lisbon Treaty.*
|
|
Tried the blocking option, you are right.
When will this make it into the github subsys?
Thank you.
…On Thu, Aug 15, 2019 at 11:46 AM Peter Glen ***@***.***> wrote:
The blocking is better, yes, but the serial implementation does not
support what you propose. (provides no event/semaphore) to block on / wait
for.
The reason why the processor is clipping, is that the no data path repeats
the call too soon.
Waiting for 30 ms on no data is an option; killing the processor is not.
Peter
On Thu, Aug 15, 2019 at 11:39 AM negativekelvin ***@***.***>
wrote:
> @pglen <https://github.com/pglen> there are two different queues so you
> don't want to remove the "second get". It is trying to block but uses the
> incorrect False parameter so the correct fix is changing it to True as
> shown above. Blocking is better than forcing a delay with sleep.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#3884?email_source=notifications&email_token=AEMBG5HOQZG4UDQYTXCUA7TQEV2B5A5CNFSM4IJVYYCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4MFB7Y#issuecomment-521687295>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AEMBG5GYRLYTPFXSGRWO3YLQEV2B5ANCNFSM4IJVYYCA>
> .
>
--
-- Peter Glen
Author / Inventor of official US Patent 'Adaptive Alpha Blending'.
Referenced by thirteen Multi Billion Dollar companies. (US20070103483).
This email is hereby declared confidential under the *Electronic
Communications Privacy Act *and the
*EU Lisbon Treaty.*
--
-- Peter Glen
Author / Inventor of official US Patent 'Adaptive Alpha Blending'.
Referenced by thirteen Multi Billion Dollar companies. (US20070103483).
This email is hereby declared confidential under the *Electronic
Communications Privacy Act *and the
*EU Lisbon Treaty.*
|
|
@pglen it's under internal review now, I think you can see it soon~ Thanks for all your contribution |
…nted Inspired by @no1seman, @negativekelvin and @pglen on Github. (In post oder) Resolves espressif/esp-idf#3884
Environment
Problem Description
After last esp-idf repo updates idf_monitor.py began to 100% load of one CPU core under linux (uname -a: Linux ubuntudev 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux, ubuntu 18.04)
Expected Behavior
idf_monitor.py should not use so much CPU resources
Actual Behavior
Near 100% CPU load
Steps to repropduce
Code to reproduce this issue
Debug Logs
The text was updated successfully, but these errors were encountered: