Ian Clarke wrote:
Ed Tomlinson wrote:
I thought so too... I do not think so now. Take a look at the metric
showing how many messages you are rejecting locally. In my case when
the node gets busy I accept less than 1%. So we have two number that
are telling use the pSF is really high.
I
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?
/N
- Original Message -
From: Tracy R Reed [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October
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?
It is (or
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?
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
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 calculating
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
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 moron
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
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
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,
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
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 is a
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
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
digest
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
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
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
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
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 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 enable
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 old
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
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
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
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]
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
32 matches
Mail list logo
