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

[Ludovic Courtès]

Today, 3 hours, 46 minutes, 27 seconds ago, Christian Grothoff wrote:
> 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 tried setting it to 20 but that didn't seem to make a big difference.

> 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%.

I see.  However, what really defines the amount of CPU time "consumed"
by the process is the ratio of the time it spent in the running state
over the total elapsed time.  The sleeping state may be entered when
doing blocking I/O calls (e.g. select, recvmsg), or calls to sleep,
pthread_mutex_lock, etc.  IOW, it may be necessary and sufficient to
adjust the time spent in blocking I/O calls to reach the requested CPU
load.

Deciding on how to make computations (whether exactly or approximately
as you mentioned) makes the process use its CPU time more efficiently,
but it does not necessarily reduce its share of CPU time.

Maybe I'm just stating the obvious, or maybe this is what gnunetd
already does?

Thanks,
Ludovic.