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

[Christian Grothoff]

On Sunday 20 February 2005 16:35, Ludovic Courtès wrote:
> 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?

You are right in that the code does not _guarantee_ that the CPU load 
limitations will be satisfied.  The assumption is, that if you cut out 
(enough of) the expensive computations, you will be blocking (on 
IO/networking events).  Now, clearly that may not happen if there is "too 
much" network traffic (so that even with the cheapest algorithms, you cannot 
process all of the data).  However, so far I had generally the impression 
that this only happened on systems that were imbalanced in terms of CPU vs. 
network capabilities (T1 line on a 386, to given an extreme example).  

The alternative would be to drop packets (or connections) if the CPU load gets 
too high, but so far I felt that this would likely be a bad idea, especially 
since the CPU load may just surge due to unrelated activities (we measure on 
most systems the _total_ CPU load, not just the share taken by gnunetd), 
which would then lead to an unwarranted exodus in terms of 
connections/bandwidth utilization.  In other words, my feeling is that the 
CPU load measurement itself is not reliable enough to really justify "strong" 
measurements (like dropping packets) to keep it in check.  Weaker 
measurements (cheaper algorithms, slower processing of HELOs) OTOH can be 
safe.  That's why the code currently works the way it does.

Christian