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
Hi,
There is a routing change in 6215 that should lead to nodes not
attempting to route nearly as often to nodes that are query rejecting.
Please upgrade.
Ed
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listi
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
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv29564
Modified Files:
NGRouting.java
Log Message:
Comment
Index: NGRouting.java
===
RCS file: /cvsroot/freenet/freenet/src/freenet
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv28830
Modified Files:
Version.java
Log Message:
Up version for routing change to avoid nodes QRing. edt
Index: Version.java
===
RCS file:
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv28219
Modified Files:
NGRouting.java
Log Message:
Nodeis are routing to nodes that are query rejecting. This can happen if our
globalEstimator values are too low. This modifies things so only su
On Thu, Oct 02, 2003 at 05:23:53PM -0700, Todd Walton spake thusly:
> Well, something to consider is: Are we sure nodes really need to
> specialize, as things are? Maybe there's a lot more disk space out there
> than there is stuff to fill it? In that case, there'd be little need to
> dump ol
On Thu, Oct 02, 2003 at 10:14:49PM +0200, [EMAIL PROTECTED] spake thusly:
> dont *remove* the line as fred fixes missing configuration parameters, such as
> bwlimiting values, with *default* values, which are 10 KB/sec IIRC
> rather use a rather high value for the bwlimits, such as 99 to enabl
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 Thu, 2 Oct 2003, Ken Corson wrote:
> is "histogram of keys in the local datastore" - I'm not certain these
> are the keys (to specialize in) that matter, but I think they are.
I believe the one you want is the second link (first under Histograms),
called "Histogram of the keys in the node's r
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
Roger (and all),
I don't understand all this stuff extremely well myself, but I found
that by using the "switch to advanced mode" main (fred) HTML menu,
then Node Status Interface, then 4th link (3rd under Histograms) ,
is "histogram of keys in the local datastore" - I'm not certain these
are the
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 04:52 pm, Ken Corson wrote:
> Can anyone tell me if NGR has disposed of key-specialization
> within a local node? I noticed that the "barcode" graph went
> away, and when I asked why (on IRC) someone said it was not
> relevant anymore. I am currently RTFS, but it is a lot to
> d
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
In message <[EMAIL PROTECTED]>, Ken Corson
<[EMAIL PROTECTED]> writes
Can anyone tell me if NGR has disposed of key-specialization
within a local node? I noticed that the "barcode" graph went
away, and when I asked why (on IRC) someone said it was not
relevant anymore. I am currently RTFS, but it
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
On October 02, 2003 04:14 pm, [EMAIL PROTECTED] wrote:
> >On Thu, Oct 02, 2003 at 09:04:52AM +0200, Niklas Bergh spake thusly:
> >> 1MB/minute translates to about 12kbyte/s which is close to the default
> >> outbound bwlimit. Are you sure that you have set outboundBandwidthLimit
> >> t=
> >
> >o 0
Can anyone tell me if NGR has disposed of key-specialization
within a local node? I noticed that the "barcode" graph went
away, and when I asked why (on IRC) someone said it was not
relevant anymore. I am currently RTFS, but it is a lot to
digest :) Clearly, if this is the case, the emergent routin
>On Thu, Oct 02, 2003 at 09:04:52AM +0200, Niklas Bergh spake thusly:
>> 1MB/minute translates to about 12kbyte/s which is close to the default
>> outbound bwlimit. Are you sure that you have set outboundBandwidthLimit t=
>o 0
>> in all the nodes config files?
>
>Yes, I did go through all of the co
On Wed, Oct 01, 2003 at 04:50:40AM -0700, Tracy R Reed spake thusly:
> Last good build should ALWAYS be CURRENT_BUILD - 1. This way brand new
> nodes will have someone to talk to but we will only be talking to the most
Well, I finally got javac installed on my machine. It wasn't nearly the
pain I
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
On Thu, Oct 02, 2003 at 09:04:52AM +0200, Niklas Bergh spake thusly:
> 1MB/minute translates to about 12kbyte/s which is close to the default
> outbound bwlimit. Are you sure that you have set outboundBandwidthLimit to 0
> in all the nodes config files?
Yes, I did go through all of the conf files
On Wed, Oct 01, 2003 at 11:41:13AM +0100, [EMAIL PROTECTED] wrote:
> >> IF the smaller installer will automatically chain to the larger
> >> installer when a suitable JVM isn't installed, then I would support
> >> removing the link to the big one, although I still say it's a concession
> >> to the
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 rerequest the data from s
On Thu, 2003-10-02 at 02:50, Martin Stone Davis wrote:
> Ian Clarke wrote:
> If the detailed page actually shows a probability of 1, then we've got a
> real problem. My first guess in that case would be that there is some
> numerical rounding due to extreme closeness to 1.
>
If you were calcula
Ian Clarke wrote:
Jonathan Howard wrote:
The current StandardNodeEstimator.estimate() is trying to calculate
the average time a node will take for any outcome.
Shouldn't it be returning the time if it succeeds + punishment for
when it fails?
It is (or should be). It returns pSuccess*tSuccess
Benny Amorsen wrote:
On fre, 2003-10-03 at 04:17, Ian Clarke wrote:
Jonathan Howard wrote:
The current StandardNodeEstimator.estimate() is trying to calculate the
average time a node will take for any outcome.
Shouldn't it be returning the time if it succeeds + punishment for when
it fails?
I
On fre, 2003-10-03 at 04:17, Ian Clarke wrote:
> Jonathan Howard wrote:
> > The current StandardNodeEstimator.estimate() is trying to calculate the
> > average time a node will take for any outcome.
> >
> > Shouldn't it be returning the time if it succeeds + punishment for when
> > it fails?
>
34 matches
Mail list logo
