Recall that in NGR we always estimate how long will it take to get the
data if the message is (initially) routed to this node. It is
important that we know what the estimate *means*. I don't think that is
the case with the equasion you give above.
I see you don't work with sub-symbolic AI.
On Sat, Oct 04, 2003 at 01:51:36PM +0100, Jonathan Howard wrote:
Recall that in NGR we always estimate how long will it take to get the
data if the message is (initially) routed to this node. It is
important that we know what the estimate *means*. I don't think that is
the case with the
Jonathan Howard wrote:
Recall that in NGR we always estimate how long will it take to get
the data if the message is (initially) routed to this node. It is
important that we know what the estimate *means*. I don't think that
is the case with the equation you give above.
I see you don't work
Jonathan Howard wrote:
The importance is for determining the preferred ordering.
That sentence makes no sense to me.
All I'm saying is the challenge is to sort the nodes from best to worst.
You don't have to be using the result values of numeric computations.
(I'm not suggestion to do it another
Ian Clarke wrote:
Interesting, but the issue is that the tFailure used in the current NGR
algorithm is not the time required to receive the failure, tFailure is
the time required to receive the failure PLUS THE ESTIMATED TIME TO
REREQUEST THE DATA FROM SOMEWHERE ELSE AND GET IT. Lets call
Martin Stone Davis wrote:
estimate=pSuccess+tSuccess
oops. typo: I meant to multiply, not add.
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
Martin Stone Davis wrote:
Okay, here's my problem with that: It's correct only if we are sure that
we would actually get a successful result from some other node. But
what if no other nodes return data, and we only get DNFs?
Well, this is where the concept of a legitimate DNF comes in. Let me
Martin Stone Davis [EMAIL PROTECTED] writes:
Ian Clarke wrote:
I still don't have my head around this fully yet, but I think the core
flaw in your proposal is that it assumes that, for a given key, the
pSuccess values of repeated requests to the same node are independent,
but they are not.
On Fri, Oct 03, 2003 at 11:37:35PM +, thong wrote:
Martin Stone Davis [EMAIL PROTECTED] writes:
Ian Clarke wrote:
I still don't have my head around this fully yet, but I think the core
flaw in your proposal is that it assumes that, for a given key, the
pSuccess values of repeated
Ian Clarke wrote:
Martin Stone Davis wrote:
Okay, here's my problem with that: It's correct only if we are sure
that we would actually get a successful result from some other node.
But what if no other nodes return data, and we only get DNFs?
Well, this is where the concept of a legitimate
Ian Clarke wrote:
Jonathan Howard wrote:
That shows what I say first and is dependent on (for working) as desired
tSuccess tFailure.
(pSuccess + pFailure) = 1
tSuccess ~= tFailure -
Actually no, tFailure should typically be much larger than tSuccess as
it includes the estimated time to
Ian,
Please read this one. Think he makes sense. If so we can remove the global estimator
from the eq, with Martin's formula we should not need it. This could also explain why
we are seeing such high numbers of requests on nodes - routing thinks they will react
fastest and they do by
On October 02, 2003 05:36 pm, Ed Tomlinson wrote:
Ian,
Please read this one. Think he makes sense. If so we can remove the
global estimator from the eq, with Martin's formula we should not need it.
This could also explain why we are seeing such high numbers of requests on
nodes - routing
Martin Stone Davis wrote:
Let's take Jonathan's example:
Node 1 - pSuccess 0.1 tSuccess 1000 pFailure 0.9 tFailure 2000
estimate = 1900
Node 2 - pSuccess 0.9 tSuccess 5000 pFailure 0.1 tFailure 1
estimate = 5500
For node 1, nSuccess/t = 1/(1000+0.9*2000/0.1) = 1/19000
For node 2,
Ed Tomlinson wrote:
Please read this one. Think he makes sense. If so we can remove the global estimator
from the eq, with Martin's formula we should not need it. This could also explain why
we are seeing such high numbers of requests on nodes - routing thinks they will react
fastest and they
Ian Clarke wrote:
I still don't have my head around this fully yet, but I think the core
flaw in your proposal is that it assumes that, for a given key, the
pSuccess values of repeated requests to the same node are independent,
but they are not. After the first failure, pSuccess for that node
On October 02, 2003 07:47 pm, Martin Stone Davis wrote:
Ian Clarke wrote:
I still don't have my head around this fully yet, but I think the core
flaw in your proposal is that it assumes that, for a given key, the
pSuccess values of repeated requests to the same node are independent,
but
Ed Tomlinson wrote:
On October 02, 2003 07:47 pm, Martin Stone Davis wrote:
Ian Clarke wrote:
I still don't have my head around this fully yet, but I think the core
flaw in your proposal is that it assumes that, for a given key, the
pSuccess values of repeated requests to the same node are
pSuccess is a function of (node,key). It will vary for a give node depending
on the key passed. This is what worries Ian about your suggestions.
Actually no -
Also
we do not just use tFailure. The term is (tFailure+tToDoThisOnAnotherNode(key))
*That* is what worries me about Martin's
Martin Stone Davis wrote:
Ian, is this what your worry is? I don't get it. I thought that we are
estimating time to retrieve a fixed key. In which case, it doesn't
matter that pSuccess is a function of (node,key): I hold key fixed and
take pSuccess to be only a function of node.
You are
Ian Clarke wrote:
Well, initially I think it would be more constructive right now if you
could redo your criticism of the current scheme now that you have this
knowledge.
So far as I can tell, the current scheme achieves what we want already -
can you demonstrate otherwise?
I'll try. Can you
On October 02, 2003 10:13 pm, Martin Stone Davis wrote:
Ian Clarke wrote:
Well, initially I think it would be more constructive right now if you
could redo your criticism of the current scheme now that you have this
knowledge.
So far as I can tell, the current scheme achieves what we
Martin Stone Davis wrote:
Ian Clarke wrote:
Well, initially I think it would be more constructive right now if you
could redo your criticism of the current scheme now that you have this
knowledge.
So far as I can tell, the current scheme achieves what we want already
- can you demonstrate
23 matches
Mail list logo
