View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003534 | GNUnet | cadet service | public | 2014-08-31 04:06 | 2018-06-06 22:25 |
| Reporter | bratao | Assigned To | Bart Polot | Due Date | |
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | Windows | OS | Windows | OS Version | 8.1 |
| Product Version | Git master | ||||
| 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 => Inside 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 | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-08-31 04:06 | bratao | New Issue | |
| 2014-08-31 04:06 | bratao | Status | new => assigned |
| 2014-08-31 04:06 | bratao | Assigned To | => Bart Polot |
| 2014-08-31 04:26 | bratao | Note Added: 0008556 | |
| 2014-08-31 04:32 | bratao | Note Added: 0008557 | |
| 2014-08-31 04:34 | bratao | Note Edited: 0008557 | |
| 2014-08-31 13:28 | bratao | Note Edited: 0008557 | |
| 2014-08-31 18:30 | Bart Polot | Note Added: 0008558 | |
| 2014-08-31 18:38 | bratao | Note Added: 0008559 | |
| 2014-08-31 18:43 | Bart Polot | Note Added: 0008560 | |
| 2014-09-05 02:22 | bratao | Note Added: 0008562 | |
| 2014-09-05 02:22 | bratao | Status | assigned => resolved |
| 2014-09-05 02:22 | bratao | Resolution | open => fixed |
| 2014-09-30 08:31 | Christian Grothoff | Fixed in Version | => 0.11.0pre66 |
| 2014-09-30 08:31 | Christian Grothoff | Target Version | => 0.11.0pre66 |
| 2018-06-06 22:25 | Christian Grothoff | Status | resolved => closed |