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:
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
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
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 w
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.
T
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
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
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
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 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
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 that
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 oth
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
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
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 corre
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 suggestion
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 indepe
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,
>
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 d
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
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, n
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 - ro
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 rejectin
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 rer
24 matches
Mail list logo
