Toad wrote:
Not necessarily. Maybe it's bias put in specifically to make new nodes
get more hits. On the other hand, maybe we should handle that
differently. Proposal:
We initialize the node estimators to something realistic, and not
heavily biased. This may be from data from the seednodes or from
On Sat, Nov 08, 2003 at 11:49:51AM -0500, Andrew Rodland wrote:
> Tom Kaitchuck wrote:
>
> > OK, so I've finally gotten around to looking at the NGrouting source, and
> > I have a few questions. Which are hopefully simple to answer.
> >
> > First in node/rt/StandardNodeEstimator.java on line 162
On Sat, Nov 08, 2003 at 11:48:26AM -0500, Andrew Rodland wrote:
> Tom Kaitchuck wrote:
>
> > Second a few lines later there is something like:
> > double tDNF = etDNF.guessTime(k) * htl;
> > double pNotConnectFailedOrSearchFailed =
> > (1 - pConnectFailed) * (1- pSearchFailed);
> > estimate += pNo
Tom Kaitchuck wrote:
> OK, so I've finally gotten around to looking at the NGrouting source, and
> I have a few questions. Which are hopefully simple to answer.
>
> First in node/rt/StandardNodeEstimator.java on line 162 ish there is:
> if (pDNF==0)
> pDNF = pLegitDNF;
> Shouldn't this be:
> if (
Tom Kaitchuck wrote:
> Second a few lines later there is something like:
> double tDNF = etDNF.guessTime(k) * htl;
> double pNotConnectFailedOrSearchFailed =
> (1 - pConnectFailed) * (1- pSearchFailed);
> estimate += pNotConnectFailedOrSearchFailed
> * (pDNF - pLegitDNF) * (tDNF + requestFailTime)
> also i noticed within the 5 minutes my node ran:
> - the "open connections" pane doesn't seem to be the most recent layout
> - the cookie management (stupid/normal mode) is not the most recent one
Yeah, that will probably be taken care of when we merge experimental
into unstable (which may be
To help this along, I have now make the snapshot generation script
generate a new snapshot of the experimental branch which can be
downloaded from:
http://freenetproject.org/snapshots/freenet-exp-latest.jar
good idea ;)
seems like somebody forgot to remove a bunch of debug messages to the
c
On Mon, Jun 16, 2003 at 12:02:32PM -0400, Ed Tomlinson spake thusly:
> That brings up an interesting point. How do we measure the efficiently of
> routing. What metrics would make sense to track and why?
However they are measured I think the two main goals of routing should be
kept in mind:
1.
?=
Date: Mon, 16 Jun 2003 12:02:31 -0400
User-Agent: KMail/1.5.9
Cc: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
X-KMail-Link-Message: 139108127
X-KMail-Link-Type: reply
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
charset="iso-885
