View Issue Details

IDProjectCategoryView StatusLast Update
0003534GNUnetcadet servicepublic2018-06-07 00:25
ReporterbrataoAssigned ToBart Polot 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformWindowsOSWindowsOS Version8.1
Product VersionSVN HEAD 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0003534: Reset cadet is called too often, taking 100% CPU during transfer
DescriptionRunning 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.


TagsNo tags attached.

Activities

bratao

2014-08-31 06:26

developer   ~0008556

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.

bratao

2014-08-31 06:32

developer   ~0008557

Last edited: 2014-08-31 15:28

View 3 revisions

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

Bart Polot

2014-08-31 20:30

manager   ~0008558

One question might help: if transfer is done, why is a new transmission requested?

bratao

2014-08-31 20:38

developer   ~0008559

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.

Bart Polot

2014-08-31 20:43

manager   ~0008560

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 ;)

bratao

2014-09-05 04:22

developer   ~0008562

I fixed this some time ago

Issue History

Date Modified Username Field Change
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