Re: [GNUnet-developers] Patch for network load measurement

[Hendrik Pagenhardt]

On Friday 16 January 2004 18:27, Christian Grothoff wrote:
> Look at "BufferEntry" with the members recently_received (how much
> traffic came from peer X),
> current_connection_value (how much did we appreciate the traffic) and
> "transmitted_limit" and "idealized limit" (how much is the peer allowed
> to send us at the moment) and the related code in connection.c.

I saw this downstream allocation code shortly after I send off my message. 
But it still might be useful to take the downstream load into account 
especially if advanced load measurement is used. It would be quite 
trivial to reduce the maximum allocateable bandwidth by dividing it by 
the load if it goes over 100%.

> 2500? Where didi you get that from I thought it was ADMIN_PRIORITY
> (defined to 0xFFFF = 65536). The idea is that certain administrative
> messages must go through regardless of bandwidth limits (like, say,
> HANGUP).  Now, I also suspect that this priority cap is to blame for
> the spikes, but I thought that we may be generating too many messages
> with ADMIN_PRIORITY at times.  But if you are right with 2500, that'll
> be a different story...

This comes from server/policy.c "outgoingCheck":
-----
  if ( (delta < 50) && /* super-fast path */
       (priority < 50*50) && /* avoid integer overflow problems with high 
priorities */
       (delta * delta * delta * (priority+1) < 50*50*50) ) {
-----
So when the priority is at least 2500 (50*50) the whole condition is false 
and (independent of load) the message is not dropped.

> I'm not sure that they are not.  TCP and the OS will smooth things out
> a bit for us anyway.  And we may not have the CPU cycles to always
> precisely send a message instantly once we're momentously under the
> limit.  Also, given the fact that the messages are of different
> importance and processing is highly concurrent, I don't see how a
> momentous value estimation could possibly work as smoothly as the
> moving averages (and it is important that all changes are smoothed over
> time to avoid instabilities in the network of the form of quickly going
> back and forward between low-load (everyone sends) and high-load
> (nobody sends) states.  This type of oscillation can easily happen and
> is reduced with the moving average but might easily become a problem
> without one.

The problem with the moving averages is that the throttling nearly always 
happens too late. Maybe a "soft" limit would be needed once the 
(momentanous, based on gnunets internal traffic accounting) load gets 
above 100% to reduce the frequency with which messages are sent. I'll try 
some things out and report about my findings.

Hendrik