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

[Christian Grothoff]

On Sunday 20 February 2005 10:29, Ludovic Courtès wrote:
> Hi,
>
> Yesterday, 20 hours, 9 minutes, 41 seconds ago, Christian Grothoff wrote:
> > 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?
>
> I set `MAXCPULOAD' to 50 (the default value) and a maximum bandwidth of
> 50 kB/s in both directions.  It is actual CPU consumption, not I/O
> (looking at Gkrellm makes it very clear).

In that case, you may also want to try to see if things improve if you set 
MAXCPULOAD to an even lower value -- you should not have to, but it might 
help.

> I'm curious about how CPU consumption limitation is implemented.  Could
> you give me pointers to the file(s) where this is done?

src/server/connection.c, line 811 ("getCPULoad").  This is just before the 
code calls either "approximateKnapsack" or "solveKnapsack".  The 
"solveKnapsack" method is what, for most of the peers that I have observed, 
consumes most of the CPU.  Also in line 901 the CPU load is checked to 
possibly reduce the size of the message queue (which again will make life 
easier for the knapsack solver next time round).  

Another time where CPU load is considered is in server/httphelo.c:157, this is 
during the startup of gnunetd when it downloads the HELOs from http.  Here 
the CPU load is considered to slow down the RSA signature verification (since 
we could easily verify 1000 RSA signatures in one big block at the beginning 
otherwise; so what this code does instead is spread that work out over a 
larger interval).

Note that getCPULoad() is relative to the user-specified load maximum.  So if 
you specified "50", getCPULoad will return 200 if the CPU is at 200%, 100 if 
the CPU is at 50% (optimal) and 50 if the CPU is at 25%.

> > 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.
>
> Does that mean that disabling bandwidth limitation should yield less CPU
> consumption?

Yes and no.  It elimiantes the Knapsack, so it would be fast in that respect, 
but you might get lots more crypto (which would make it worse in others).  
However, if you have less bandwidth overall, you get fewer connections and 
thus fewer Knapsack solving -- so a lower limit is almost guaranteed to 
improve things (for the CPU consumption at least).

> My point about preemptive multithreading is that it is sometimes
> considered harmful compared to cooperative multithreading or event
> loops [1, 2].

Well, there are some performance penalties, yes.  But as a user, you could not 
notice the difference for the gnunetd performance (my feeling is that the 
impact of scheduling and locking is under 1% --- especially since most of our 
CPU consumption goes into numeric computations done by individual threads in 
isolation).

Christian