[EMAIL PROTECTED] wrote:
One thing that always bothered me about NGrouting is that we only antisipate
having to retry once.
Originally I wanted to use a Ramon sum to determine the overall time but Ian
pointed out that we don't want to retry infinitely.
It occurred to me that NGrouting estimates t
One thing that always bothered me about NGrouting is that we only antisipate
having to retry once.
Originally I wanted to use a Ramon sum to determine the overall time but Ian
pointed out that we don't want to retry infinitely.
It occurred to me that NGrouting estimates the time for success and t
On Saturday 08 November 2003 06:38 am, Ian Clarke 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 ish there i
Toad wrote:
All in all, it could take a very long time for the estimators to start
producing realistic estimates. If so, we should consider having a less
dramatic bias towards untested nodes.
In which case they won't get routed to and we'll be stuck in false
optima - but see my suggestion in the
On Sat, Nov 08, 2003 at 06:21:23PM +, Ian Clarke wrote:
> Toad wrote:
> >>Not sure what this code is trying to achieve, but it looks like it is
> >>just attempting to have a more intelligent value for pDNF in the event
> >>that the estimator doesn't have any data yet, in which case I think yo
Toad wrote:
Not sure what this code is trying to achieve, but it looks like it is
just attempting to have a more intelligent value for pDNF in the event
that the estimator doesn't have any data yet, in which case I think you
are right. Matthew?
Not sure, maybe we WANT a crazy value on new nodes
On Sat, Nov 08, 2003 at 04:51:55PM +, Ian Clarke wrote:
> Ed Tomlinson wrote:
> >On November 08, 2003 03:14 am, Tom Kaitchuck wrote:
> >>First in node/rt/StandardNodeEstimator.java on line 162 ish there is:
> >>if (pDNF==0)
> >>pDNF = pLegitDNF;
> >>Shouldn't thi
On Sat, Nov 08, 2003 at 12:38:14PM +, Ian Clarke 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 ish the
On Sat, Nov 08, 2003 at 02:14:54AM -0600, 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 (
Ed Tomlinson wrote:
On November 08, 2003 03:14 am, Tom Kaitchuck wrote:
First in node/rt/StandardNodeEstimator.java on line 162 ish there is:
if (pDNF==0)
pDNF = pLegitDNF;
Shouldn't this be:
if (pDNF
The above says. If you know nothing about
On November 08, 2003 03:14 am, 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)
>
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
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:
On Sun, Aug 31, 2003 at 01:21:46AM +0100, Toad spake thusly:
> NGRouting, and a lot of infrastructure work and some major bugfixes, has
> been merged into the unstable branch, in build 6163. So that it can have
Just so you know I'm running 6163 and still getting RNF's regularly. Not
sure what othe
NGRouting, and a lot of infrastructure work and some major bugfixes, has
been merged into the unstable branch, in build 6163. So that it can have
wider testing. Please would everyone running the unstable branch
upgrade, try it, and report bugs or interesting error messages. Merge
was from ngrouting
Using latest CVS:
Last connected never
Last attempted 3691s ago
Connection attempts 60
Connection successes 0
Consecutive failed connections 60
Probability of connection failure 0.984675044593
Successful transfers 32
Does never equal 3691 seconds ago?
Can 32 successful transfers have been per
Before we turn NGR loose in a release, perhaps it
would be a good idea to do one little test, at least
if it's not to hard.
I've heard NGR has been tested on single nodes and
shown good results. Could we measure the results for
queries passing throught the node with different HTLs
independently.
One point. In order to predict accurately, and therefore route
accurately, we want to adjust T_success(node, key) by both htl and size
- and since the search is separate, we get
P_success(node, key) *
(T_search_success(node, key)*htl +
T_transfer(node, key)/keysize)
The other possibility is to
On July 24, 2003 11:48 am, Toad wrote:
> On Wed, Jul 23, 2003 at 09:34:21PM -0400, Ed Tomlinson wrote:
> > On July 23, 2003 05:35 pm, Toad wrote:
> > > Another term then:
> > >
> > > ... + (P(searchFailed(node) * (T_searchFailed(node) + T_req(key)))
> > >
> > >
> > > Where T_searchFailed depends o
On Wed, Jul 23, 2003 at 09:34:21PM -0400, Ed Tomlinson wrote:
> On July 23, 2003 05:35 pm, Toad wrote:
> > Another term then:
> >
> > ... + (P(searchFailed(node) * (T_searchFailed(node) + T_req(key)))
> >
> >
> > Where T_searchFailed depends on the HTL.
>
> This one may help.
>
> > And then ther
On July 22, 2003 08:41 pm, Ian Clarke wrote:
> On Tue, Jul 22, 2003 at 08:30:16PM -0400, Andrew Rodland wrote:
> > Please don't let's forget that random first hop is the only thing that
> > makes retrying of any use after we reach HTL=25 and want to keep trying,
> > because of ftable. And I think t
On July 23, 2003 05:35 pm, Toad wrote:
> Another term then:
>
> ... + (P(searchFailed(node) * (T_searchFailed(node) + T_req(key)))
>
>
> Where T_searchFailed depends on the HTL.
This one may help.
> And then there is transfer failure. Which theoretically depends on the
>
> message length... anyw
On July 23, 2003 02:15 pm, Ian Clarke wrote:
> On Wed, Jul 23, 2003 at 06:56:16PM +0100, Toad wrote:
> > Running averages (presumably we would have one global sensitivity
> > parameter):
>
> Not necessarily, but in-practice, there is no reason not to until we
> have developed a more enlightened way
On Wed, Jul 23, 2003 at 03:13:58PM -0700, Ian Clarke wrote:
> One thought - if we are maintaining open connections to all routable
> nodes - then surely the NGR routing algorithm shouldn't have to worry
> about connectFailed and authFailed problems - as such nodes wouldn't even
> be considered?
One thought - if we are maintaining open connections to all routable
nodes - then surely the NGR routing algorithm shouldn't have to worry
about connectFailed and authFailed problems - as such nodes wouldn't even
be considered?
Ian.
On Wed, Jul 23, 2003 at 10:35:21PM +0100, Toad wrote:
> Some
Some more terms to add on methinks. out of Routing, connectFailed,
authFailed (treated as connectFailed for now), and queryRejected are
accounted for. What about timedOut()? Maybe we should treat it as
queryRejected. What about timing out mid query?
Another term then:
... + (P(searchFailed(node)
On Wed, Jul 23, 2003 at 11:53:55AM -0700, Rudi Cilibrasi wrote:
> It seems clear from a simple thought-experiment that for some machines,
> network outages may be on the order of ten seconds, and for others on
> the order of days. This seems to imply that no single value for
> a multiplier in an e
On Wed, Jul 23, 2003 at 06:56:16PM +0100, Toad wrote:
> Okay, what seems to me to be the current algorithm:
>
> E = (1 - (P_connectfailed(node) + P_queryRejected(node))) *
> (P_success(node, key) * T_success(node, key) +
> (P_DNF(node, key) - P_legit_DNF) * (T_DNF(node, key) + T_req(key
On Wed, Jul 23, 2003 at 06:56:16PM +0100, Toad wrote:
> Okay, what seems to me to be the current algorithm:
>
> E = (1 - (P_connectfailed(node) + P_queryRejected(node))) *
> (P_success(node, key) * T_success(node, key) +
> (P_DNF(node, key) - P_legit_DNF) * (T_DNF(node, key) + T_req(ke
On Wed, Jul 23, 2003 at 06:56:16PM +0100, Toad wrote:
> Running averages (presumably we would have one global sensitivity
> parameter):
Not necessarily, but in-practice, there is no reason not to until we
have developed a more enlightened way to decide on what the forgetfulness
of the running aver
Okay, what seems to me to be the current algorithm:
E = (1 - (P_connectfailed(node) + P_queryRejected(node))) *
(P_success(node, key) * T_success(node, key) +
(P_DNF(node, key) - P_legit_DNF) * (T_DNF(node, key) + T_req(key))) +
(P_connectfailed(node) * (T_connectfailed(node) + T_re
On Wed, Jul 23, 2003 at 12:05:28AM +0100, Toad wrote:
> The main argument put forward at the time was to prevent the network
> from dividing into islands, or to stitch it back together when they did
> form.
Yes, however there has never been a single known instance of this
happening, either in rea
On Tue, Jul 22, 2003 at 08:30:16PM -0400, Andrew Rodland wrote:
> Please don't let's forget that random first hop is the only thing that
> makes retrying of any use after we reach HTL=25 and want to keep trying,
> because of ftable. And I think that people will agree with me, that as
> it stands
ly 22, 2003 8:30
PM
Subject: Re: [freenet-dev] NGrouting and
random first step
-BEGIN PGP SIGNED MESSAGE-Hash:
SHA1 Ian Clarke wrote:||Bottom line, the whole random
routing thing was a solution to a problem|that nobody ever observed, and
in all liklihood - would never|actually
On Mon, Jul 21, 2003 at 11:45:59AM -0700, Ian Clarke wrote:
> On Mon, Jul 21, 2003 at 07:02:46PM +0100, Toad wrote:
> > On Thu, Jul 03, 2003 at 11:40:18AM -0700, Ian Clarke wrote:
> > > If my memory serves me correctly, we currently select the first step in
> > > routing at random as a security me
On Tuesday 22 July 2003 06:05 pm, Toad wrote:
> The main argument put forward at the time was to prevent the network
> from dividing into islands, or to stitch it back together when they did
> form. However, random routing every request on the origin node is not the
> only way to deal with it - one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Clarke wrote:
|
|Bottom line, the whole random routing thing was a solution to a problem
|that nobody ever observed, and in all liklihood - would never
|actually occur in practice.
Please don't let's forget that random first hop is the only thing t
On Mon, Jul 21, 2003 at 07:02:46PM +0100, Toad wrote:
> On Thu, Jul 03, 2003 at 11:40:18AM -0700, Ian Clarke wrote:
> > If my memory serves me correctly, we currently select the first step in
> > routing at random as a security measure.
> >
> > Translating this over to NGrouting, I suggest that f
On Thu, Jul 03, 2003 at 11:40:18AM -0700, Ian Clarke wrote:
> If my memory serves me correctly, we currently select the first step in
> routing at random as a security measure.
>
> Translating this over to NGrouting, I suggest that for the first hop in
> a request, instead of using the RTE to es
Ian Clarke wrote:
Well, Ed has what I understand to be a working implementation of NG
routing in the experimental branch - and I really want to get the ball
rolling with it.
To help this along, I have now make the snapshot generation script
generate a new snapshot of the experimental branch wh
Well, Ed has what I understand to be a working implementation of NG
routing in the experimental branch - and I really want to get the ball
rolling with it.
To help this along, I have now make the snapshot generation script
generate a new snapshot of the experimental branch which can be
downloa
Thank you for this. Your explanation makes things clear.
-todd
On Fri, 4 Jul 2003, Ed Tomlinson wrote:
> NG is really quite simple. What it does is attempt to find the route that will
> respond fastest for a given key. It does this by tracking how long various
> events take.
>
> The curre
> On July 3, 2003 03:11 pm, Ian Clarke wrote:
> > On Thu, Jul 03, 2003 at 01:46:39PM -0500, Tom Kaitchuck wrote:
> > > On Thursday 03 July 2003 01:40 pm, Ian Clarke wrote:
> > > > step in routing at random as a security measure.
> > >
> > > Forgive my ignorance, but how does this provide security?
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Ah, much clearer now. Would the experimental branch be the same as unstable?
> If not, how do I get ahold of it?
No, it's not. You'd get it by doing a "cvs -z3 update -dP -r experimental"
but since you're not a developer, you'd be going through SF'
Ah, much clearer now. Would the experimental branch be the same as unstable? If not, how do I get ahold of it?
On July 3, 2003 10:24 pm, [EMAIL PROTECTED] wrote:
> Alright, can someone give a quick overview of the NGRouting, like Ian gave
> at his talk at Stanford...I think it was?
>
> The idiot sitting here in this chair wishes enlightenment beyond taoism.
NG is really quite simple. What it does is attem
On July 3, 2003 03:11 pm, Ian Clarke wrote:
> On Thu, Jul 03, 2003 at 01:46:39PM -0500, Tom Kaitchuck wrote:
> > On Thursday 03 July 2003 01:40 pm, Ian Clarke wrote:
> > > If my memory serves me correctly, we currently select the first step in
> > > routing at random as a security measure.
> >
> >
On July 3, 2003 02:40 pm, Ian Clarke wrote:
> If my memory serves me correctly, we currently select the first step in
> routing at random as a security measure.
>
> Translating this over to NGrouting, I suggest that for the first hop in
> a request, instead of using the RTE to estimate the per-key
Alright, can someone give a quick overview of the NGRouting, like Ian gave at his talk at Stanford...I think it was?
The idiot sitting here in this chair wishes enlightenment beyond taoism.
On Thu, Jul 03, 2003 at 12:11:59PM -0700, Ian Clarke wrote:
> On Thu, Jul 03, 2003 at 01:46:39PM -0500, Tom Kaitchuck wrote:
> > On Thursday 03 July 2003 01:40 pm, Ian Clarke wrote:
> > > If my memory serves me correctly, we currently select the first step in
> > > routing at random as a security m
On Thu, Jul 03, 2003 at 01:46:39PM -0500, Tom Kaitchuck wrote:
> On Thursday 03 July 2003 01:40 pm, Ian Clarke wrote:
> > If my memory serves me correctly, we currently select the first step in
> > routing at random as a security measure.
>
> Forgive my ignorance, but how does this provide securit
On Thursday 03 July 2003 01:40 pm, Ian Clarke wrote:
> If my memory serves me correctly, we currently select the first step in
> routing at random as a security measure.
Forgive my ignorance, but how does this provide security?
___
devl mailing list
[EMA
If my memory serves me correctly, we currently select the first step in
routing at random as a security measure.
Translating this over to NGrouting, I suggest that for the first hop in
a request, instead of using the RTE to estimate the per-key request time
estimate, we use a random number betw
We ABSOLUTELY MUST NOT implement NGrouting, or edt's new CP algorithm,
until NIO is in. Because we do not want to introduce a bias favouring
nodes with connections already open, when we have the current situation
where nodes cannot keep anything like enough connections open. GJ just
fixed a bug lik
I think the next step with NGrouting is to optomize the various
parameters to ensure that the RoutingTimeEstimator that MJR wrote can
produce good estimates.
The best way to do this is to add some temporary code which outputs
reference/key/routing time data to a file which can be used as a
tes
55 matches
Mail list logo
