On Thu, Oct 18, 2001 at 12:25:44AM -0400, Gianni Johansson wrote:
<>
> I just checked in changes that give failed nodes an interval to
> "rest" before they are retried again. I think that cooperatively backing
> off in this manner will reduce network congestion. Request will be better
> routed to nodes that can answer them. If the node really is
> completely out of usable refs requests will fail quickly with RNFs instead of
> waiting for all of the known bad refs to be contacted and fail.
As I said, I don't see the point in this. The CP value already gives a
"rest", it just does to ramdonly rather than absolutely, but it averages
out.
If routing skips all the available refs, then the node just should
simply send back a RouteNotFound on the request. Trying to make it force
the routing to a node randomly was a well intentioned idea, but does not
work out in reality. Complicating this will only make it worse.
> 1) It looks like the thread pools job queue is way too big.
> Snippet from Freenet.node.Main.startNode:
>
> if (node.maximumThreads > 0) {
> tm = new ThreadPool(tg, 5, node.maximumThreads >> 1,
> node.maximumThreads);
> tm.start();
> }
>
> First, only half as many threads as are specified in
> freenet.conf are actually created. This is somewhat
> counter-intuitive to the end user.
I agree, that seems wrong. I think that it should rather be
tm = new ThreadPool(tg, node.maximumThreads >> 1, node.maximumThreads, 5);
though "5" seems awefully arbitrary. I'm quite sure the intention was to
have maximumThreads maximum, and half as many in the pool by default, so
this is probably simply a mistake.
<>
> It's easy to reduce the size of the job queue. Figuring out what
> to do to recover somewhat gracefully when it overflows is much more difficult.
> I don't really know the answer.
It should be ok:
1) Incoming connections use run() and simply close if nothing can be
assigned.
2) The Ticker uses blockingRun() so it simply waits until it can run the
threads.
3) Outgoing connections use forceRun() so they simply fall back on
making new java threads.
Those are really all the threads we start (I even considered creating
connections by throwing them on the Ticker so as to not create any
threads anywhere else).
> I will not comment on the practice of using shift operators instead
> of division...
If somebody doesn't know what a bit shift does, they are better off
learning now.
> 2) Tuning the ratio of open connections and allowed threads.
> I think the default maxNodeConnections (30) is too big for the default
> value of maximumThreads (120 which is only 60 real threads). When the
> network gets congested, message chains restart more often which
> seems to eat up more threads.
>
> I have been running my node with 10 connections and 240 threads (120 real
> threads).
>
> Thoughts?
I think you are going going after symptoms here, clearly we should not
need 12 threads per incoming connection. The problem is (I guess) that
your living outgoing connections are staying alive and grabbing all the
threads, hardly allowing any incoming. This effectively creates a
situation where your node can only be routed to using the already open
connections (something that has been discussed as a feature, but which I
think we can agree must be implemented under much more controlled
circumstances).
What clearly needs to be done is tuning the lifetime of connections.
Just setting the connectionTimeout down a little may help (why is that
the one setting nobody is messing with?), but OpenConnectionManager
probably needs to be better at pruning out connections (like removing
redundant connections to the same node) as well.
>
> -- gj
>
> --
> Freesites
> (0.3) freenet:MSK at SSK@enI8YFo3gj8UVh-Au0HpKMftf6QQAgE/homepage//
> (0.4) freenet:SSK at npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage//
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://lists.freenetproject.org/mailman/listinfo/devl
--
Oskar Sandberg
oskar at freenetproject.org
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl
