Re: [Help-gnunet] OK to use a FQDN for 'IP' in gnunet.conf?

[Christian Grothoff]

On Saturday 19 February 2005 06:51, Ludovic Courtès wrote:
> Hi Christian,
>
> 6 days, 17 hours, 23 minutes, 7 seconds ago,
>
> Christian Grothoff wrote:
> > I wonder if anyone else is having a problem with high CPU utilization by
> > the _clients_ (not gnunetd)?
>
> Why not gnunetd?  :-)

Because it would be a different issue ;-).

> Last time I tried (several months ago), gnunetd was actually eating so
> much CPU (even while I wasn't downloading anything) that I just
> couldn't let it run in the background and listen to an mp3 at the same
> time on my K6-2 350MHz (admittedly not a cutting-edge machine).  Note
> that this is on Debian unstable, with the GDBM back-end.

What did you configure your MAXCPULOAD to be?  Is it reall CPU consumption or 
is your GDBM database thrashing the harddisk?  How much bandwidth did you 
give to your peer?  

> Since then, I sometimes used aMule, a Python GTK-based implementation of
> the Fasttrack protocol, and I was impressed by its relatively low CPU
> consumption.  Of course, Fasttrack may slightly differ from GAP.  But
> still, aMule didn't eat up all the CPU, even when content was being
> dowloaded from and uploaded to my node at the same time.
>
> Gnunetd seems to be heavily multithreaded which may be one possible
> cause of its CPU intensiveness.

It's not about how many threads there are, it is about the algorithms that are 
used.  GNUnet can burn a large number of cycles trying to find (possibly 
approximate) solutions to an NP-complete problem that improves bandwidth 
utilization.  GAP itself is rather innocent here, it's the bandwidth 
allocator and (depending on your crypto library and other things) sometimes 
the public-key crypto.  Fasttrack does not use that much (if any) crypto and 
does not have the bandwidth scheduler.  And that's where the CPU usage by 
gnunetd goes into.

Christian