Okay, after reviewing the source this is what I think I have learned: There is a chain of events: connect -> search -> find data -> transfer. Each chain has to succeed in order for the next event to occur.

In StandardNodeEstimator,

rpConnectFailed is like "# of connect failues" divided by "# of times we tried to connect"

rpSearchFailed is like "# of search failures" divided by "# of times we tried to search"

(They aren't exactly, because they are decaying running averages, but it's close enough)

In which case, you could indeed fail to connect to the node 2/3 of the time, and in the 1/3 of the time when you suceeed, you might fail in your search 2/3 of *that* time. Then, rpConnectFailed=2/3 and rpSearchFailed=2/3 and they add up to more than 1. Sure, the search won't happen unless the connection succeeds, but the probability of search failing is calculated here only in cases where the connection succeeds.

So, I think the code is right as it stands.

Ian Clarke wrote:

On Wed, Oct 01, 2003 at 01:13:36PM -0700, Martin Stone Davis wrote:

I have not RTFS, but I am pretty good with probabilities and statistics.


In that case you could really help us out if you could review the relevant source, since it is easy to have thinkos in this kind of code and very difficult to detect them based on node performance - only a review by someone comfortable with statistics will realistically pick them up.

The relevant file is at:
http://cvs.sourceforge.net/viewcvs.py/freenet/freenet/src/freenet/node/rt/StandardNodeEstimator.java?rev=1.5&content-type=text/vnd.viewcvs-markup

The variable names are pretty verbose so it should be easy enough to see what is going on even if you don't know Java.

Ian.



_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to