|
I am wondering about a few things;
First; the linux system that I have (P166 running
at 150) just doesn't cut it even with 'good' nodes - I gave it the node list
from my XP box - I guess the connectons were taking too long to build and the
other side decided not to wait for it; so to be a reasonable node I have to run
it on the XP; which I don't really like cause Windows hangs a whole lot easier
than linux if pushed just a little too much; and there is already enough
background tasks to get hung up if I'm not careful.
In any case; I was wanting thoughteedback as well
as comparisons with other nodes if possible;
(System happens to be a Athlon 900 running XP with
'more than enough' memory)
First; restarting of the node (which I did when it
was accepting 2709 requests/hr out of 8127); no real reason to do this; just
felt like it -- anyways bad move; I gave it 2hrs to get back on its feet which
it didn't do; got stuck at about 400% capacity and closed to the world doing
nothing usefull; to get it restarted I blocked the incoming connections via my
firewall; restarted it and grabbed a few keys to prime it a little before I
unleashed the full crowd - I did note that the node started talking before it
had grabbed all of the memory it desired; didn't feel like repeating the process
to see if it was still trying to grab memory at the 2h and still not working
mark)
Some stats; that if we can compare (Thelma perhaps)
to see the effect of the routing backoff on reject code that I
proposed.
Uptime is about 4h 20 min; from the found
histogram; my node has 967; 60 client requests happened since the start as well
as 7333 accepted requests out of 14962 reeived requests (all these numbers
except client requests I pulled off the histograms)
Past hourly from the diagnostics section: 1098 out
of 2137; hr2: 1539 out of 3084; hr3: 1292 out of 2601; hr4: 2443 out of 4955;
and as I noted before my 2hr break it was 2709 out of 8127
Few things of note; with the code, my node returns
rejected (no route) to probably a fair fraction of the requests (it uses its
judgement to decide if the nodes it knows about are unlikely to have time
to process the request and doesn't try them all) for client requests; it ends up
with route not found probably half the time; three tries for a site normally
gets it - so not necessarly all that great for the client; but I believe that
this is good for the network as it pushes traffic away from the heavily loaded
nodes (this is assuming that we have enough nodes) - I have a few nodes that I
bairly talk to because their acceptance rate is so low - connect to the; sure
most of the time - but they respond so much with query rejected that they are
down at 1% probability that my node will try to use them. suspect that the
nodes down that low are experiencing the node soo busy that it doesn't have any
time to do anything but respond with query rejected syndrom; therefore backing
off of these nodes might actualy result in them coming back to
life.
Unforunately we have no real way to judge if only
finding data for about 10% of the requests is reasonable or not; many of the
requests could be for items that don't yet exist in the keyspace (eg
frost/fmb/edition links to future editions) From my use of the node prior to
trying to reset it; for keys that I expected should exist somewhere; I
was seeing at least a 25% success rate; which I think is better than
before.
That all said; I am wondering who I need to talk to
for the proposed backoff line to get into the standard distribution - or for
that matter if there is any opposition to it - note that this backoff does not
cause nodes to get dropped from the routing table; they just get a lower and
lower probability of use
For anyone who may have missed it; the proposed
line is contactProbability =
(float)((contactProbability-1.0/5.0)/(4.0/5.0)*(19.0/20.0)); to be added to the
backoffRouting method of CPAlgoData.
My routing able hangs around 55 nodes; 13 reasonbly
accepting;33 marginally accepting and 9 basically flatlined. The flatlined
nodes accept connections just fine and dandy; however they almost never accept
requests; examples of these likely flooded nodes are 62.49.68.75; 133.68.91.222
sure.serveftp.org; www.mytharria.com;
sapphire.alpha.ne.jp - they connect over 80% of the time; but have less than a
2% chance of being used because they don't actually accept requests; it would be
nice to be able to validate what is happening with these nodes; but unless
someone reconizes their node and can give us feedback; I don't think we have a
way to find out - some really high level stats from the nodes would be great to
get from the network; eg daily inbound requests total and handled on a daily
basis; but I expect if anyone tried to put something like that into the code the
would get shot by everyone and anyone who feels they have a right to
be anonymous and any centralized logging of any sort might reduce that
anonymittity
Thoughts/feedback?
Trevor
|
