help-gnunet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnunet] Normal node behaviour?


From: Christian Grothoff
Subject: Re: [Help-gnunet] Normal node behaviour?
Date: Fri, 29 Oct 2004 12:47:31 -0500
User-agent: KMail/1.7

On Friday 29 October 2004 04:53, Alexander Zimmerer wrote:
> Hi,
>
> is this node behaviour "normal" (see gnunet-stats below). I'm especially
> confused by the amount of msg's espired. There are about as much msg's sent
> as msg's expired, isn't this bad?

Not really.  Your node receives say 50 requests.  It can finds 11 responses, 
but only has bandwidth to send 5. In other words, it has to expire 6 
responses.  Now, Igor will say here that it should have "predicted" that it 
would only be able to send back 5 responses and not done the other 6 database 
lookups (since those were effectively wasted disk accesses), but doing this 
is hard: bandwidth availability and success in actually looking up the data 
vary greatly over time.  And there is an artificial delay between doing the 
disk lookup and actually using the bandwidth, making it even harder to 
predict if a message will have a chance of being transmitted.  

Note that what GNUnet does is it queues all of the messages and if the queue 
gets too long it drops some of the old, unimportant ones.  In your case, that 
maybe 50% of all messages, but again, those are the ones that the bandwidth 
allocation algorithm decided were the least important.  So in many ways, this 
is more of a design feature than a bug or a problem.

> Currently I run BASICLIMITING = NO, I 
> recognized when I change it to YES the ratio msgs sent/msgs expired is
> better (about 2/1). Any ideas or comments?

I do not have an intuitive reason why changing BASICLIMITING to YES would 
improve the expiration ratio (unless it also changes your ratio of upstream 
vs. downstream for some reason).  But again it does not indicate any specific 
problem either.

C




reply via email to

[Prev in Thread] Current Thread [Next in Thread]