View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003534||GNUnet||cadet service||public||2014-08-31 06:06||2018-06-07 00:25|
|Reporter||bratao||Assigned To||Bart Polot|
|Product Version||SVN HEAD|
|Target Version||0.11.0pre66||Fixed in Version||0.11.0pre66|
|Summary||0003534: Reset cadet is called too often, taking 100% CPU during transfer|
|Description||Running GNUNet under Intel V-Tune I can see that reset_cadet is responsible for the majority of CPU usage. Often making the application use 100% of CPU.|
From the function description, it was supposed to be called only when something wrong happened.
|Tags||No tags attached.|
Futher checking the profile. Looks like that gnunet-service-fs and gnunet-service-cadet get in a loop. Both consuming 100% CPU and doing nothing, as the download transfer is already done ( an 600MB file transmitted with FS_delay setting disabled)
Looks like that transmit_sqm is called and the condition NULL == buf get hit every time. Calling the reset_cadet_async.
Yeah, look at this flow. It's a loop.
cadet_reset_task => reset_cadet = > GNUNET_CADET_channel_destroy =>
if (GNUNET_YES == th_is_payload (th))
th->notify (th->notify_cls, 0, NULL);
It calls transmit_sqm with buf == NULL, so it will always call => reset_cadet_aync << LOOP
||One question might help: if transfer is done, why is a new transmission requested?|
I tried to fix it in r34248-34249.
It cancel the notify before destroying the cadet channel. I do not know if this is the right fix, but is working here nevertheless.
I saw the fix, and changed the API calls a little bit. My point is that cancelling whatever is pending before calling channel destroy is a good workaroud. A fix would be not to call transmit_ready when the transfer is done, in the first place, just call channel_destroy.
Also, indiscriminately calling reset_cadet on any NULL == buf seems a bit... radical ;)
||I fixed this some time ago|
|2014-08-31 06:06||bratao||New Issue|
|2014-08-31 06:06||bratao||Status||new => assigned|
|2014-08-31 06:06||bratao||Assigned To||=> Bart Polot|
|2014-08-31 06:26||bratao||Note Added: 0008556|
|2014-08-31 06:32||bratao||Note Added: 0008557|
|2014-08-31 06:34||bratao||Note Edited: 0008557||View Revisions|
|2014-08-31 15:28||bratao||Note Edited: 0008557||View Revisions|
|2014-08-31 20:30||Bart Polot||Note Added: 0008558|
|2014-08-31 20:38||bratao||Note Added: 0008559|
|2014-08-31 20:43||Bart Polot||Note Added: 0008560|
|2014-09-05 04:22||bratao||Note Added: 0008562|
|2014-09-05 04:22||bratao||Status||assigned => resolved|
|2014-09-05 04:22||bratao||Resolution||open => fixed|
|2014-09-30 10:31||Christian Grothoff||Fixed in Version||=> 0.11.0pre66|
|2014-09-30 10:31||Christian Grothoff||Target Version||=> 0.11.0pre66|
|2018-06-07 00:25||Christian Grothoff||Status||resolved => closed|