Toad wrote:
Implemented in unstable 6348.
Cool.
I just tried this with a fresh routing table and DS. Looking at the
small graphs in nodestatus.html, I noticed that most nodes were
initialized with a peak (ie. one key that gets especially bad estimates,
if I am reading the graph correctly).
After several hours of uptime but no interaction with the user (i.e.
node was left overnight) when I decided to check out the web interface
in the morning fred suddenly hang. No cpu whatsoever was used, and when
I tried to get a stack dump I got:
Fatal: Stack size too small. Use 'java -Xss'
On Fri, 2003-11-21 at 04:23, Ian Clarke wrote:
Edward J. Huff wrote:
It seems to me that NGR can't possibly do certain things.
When the standard deviation exceeds the mean, you can't
even predict the sign of your random variable.
The standard deviation exceeding the mean, if it does
On November 21, 2003 06:20 pm, Mike Stump wrote:
Uncle.
It is curious that 92 connections transmitting and a 31 MB backlog
(from ocm) can only get 49.2% of the upstream (from Current upstream
bandwidth usage). Either, this number doesn't contain all the
upstream used, or something is really
On Sat, Nov 22, 2003 at 09:35:45AM -0500, Ed Tomlinson wrote:
On November 22, 2003 09:12 am, Edward J. Huff wrote:
On Fri, 2003-11-21 at 04:23, Ian Clarke wrote:
Edward J. Huff wrote:
It seems to me that NGR can't possibly do certain things.
When the standard deviation exceeds the
On Sat, Nov 22, 2003 at 01:52:41AM -0500, Zlatin Balevsky wrote:
After starting a brand new node with 6348 the outbound requests become
sharply specialized in a matter of minutes. The incoming requests are
How do you determine this?
of course in disaray, but hopefully when more nodes start
On Fri, 21 Nov 2003 22:47:21 +, Toad wrote:
On Fri, Nov 21, 2003 at 03:20:58PM -0500, Ed Tomlinson wrote:
On November 21, 2003 01:45 pm, Toad wrote:
On Fri, Nov 21, 2003 at 12:01:27PM -0500, Ed Tomlinson wrote:
On November 21, 2003 06:41 am, Ian Clarke wrote:
It seems that we
On Sat, Nov 22, 2003 at 06:22:57PM +0200, Jusa Saari wrote:
On Fri, 21 Nov 2003 22:47:21 +, Toad wrote:
On Fri, Nov 21, 2003 at 03:20:58PM -0500, Ed Tomlinson wrote:
On November 21, 2003 01:45 pm, Toad wrote:
On Fri, Nov 21, 2003 at 12:01:27PM -0500, Ed Tomlinson wrote:
On
While debugging the new changes to NGRouting (and finding several bugs
in that code), I came across this:
SEC 11 22, 2003 17:19:24:349 (freenet.node.rt.StandardNodeEstimator,
QThread-74, MINOR): [EMAIL PROTECTED]:
tcp/62.155.178.40:28146, sessions=1, presentations=1, ID=DSA(04a1 4b6d
ca19 d8fd
On Sat, Nov 22, 2003 at 05:30:11PM +, Toad wrote:
While debugging the new changes to NGRouting (and finding several bugs
in that code), I came across this:
SEC 11 22, 2003 17:19:24:349 (freenet.node.rt.StandardNodeEstimator,
QThread-74, MINOR): [EMAIL PROTECTED]:
tcp/62.155.178.40:28146,
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv30192/src/freenet
Modified Files:
Version.java
Log Message:
6349:
Major debugging on NGRouting recent changes.
Add diagnostic startedRequestHTL, use it to make the maintenance requests use typical
HTLs
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv30192/src/freenet/node
Modified Files:
NodeReference.java Node.java NewNodeContactor.java Main.java
Log Message:
6349:
Major debugging on NGRouting recent changes.
Add diagnostic startedRequestHTL,
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FNP
In directory sc8-pr-cvs1:/tmp/cvs-serv30192/src/freenet/node/states/FNP
Modified Files:
NewRequest.java NewDataRequest.java
Log Message:
6349:
Major debugging on NGRouting recent changes.
Add diagnostic startedRequestHTL, use
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FCP
In directory sc8-pr-cvs1:/tmp/cvs-serv30192/src/freenet/node/states/FCP
Modified Files:
NewClientGet.java
Log Message:
6349:
Major debugging on NGRouting recent changes.
Add diagnostic startedRequestHTL, use it to make the
Update of /cvsroot/freenet/freenet/src/freenet/client
In directory sc8-pr-cvs1:/tmp/cvs-serv30192/src/freenet/client
Modified Files:
InternalClient.java
Log Message:
6349:
Major debugging on NGRouting recent changes.
Add diagnostic startedRequestHTL, use it to make the maintenance
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv30192/src/freenet/node/rt
Modified Files:
NGRoutingTable.java FilterRoutingTable.java
StandardNodeStats.java StandardNodeEstimator.java
RoutingTable.java CPAlgoRoutingTable.java
Freenet unstable build 6349 is in CVS. The snapshots are being updated.
Major changes:
* Major bugfixes on recent work on NGRouting
- pDNF was being initialized to 0.0 rather than 1.0 on estimators
created without an initial specialization. Break compatibility with
previous Estimator fields.
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv10591/src/freenet
Modified Files:
Version.java
Log Message:
6350:
Separate global estimators for search time and transfer rate.
Therefore requestFailTime depends on the file size, as it should do.
Fixes
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv10591/src/freenet/node/rt
Modified Files:
NGRouting.java NodeEstimatorFactory.java NGRoutingTable.java
StandardNodeEstimator.java StandardNodeEstimatorFactory.java
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv11019/src/freenet
Modified Files:
Version.java
Log Message:
6351:
Fix NPE in FilterRoutingTable.
Index: Version.java
===
RCS file:
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv11019/src/freenet/node/rt
Modified Files:
FilterRoutingTable.java
Log Message:
6351:
Fix NPE in FilterRoutingTable.
Index: FilterRoutingTable.java
Unstable build 6351 is in CVS. The snapshots are being updated.
Changes:
6350:
Separate global estimators for search time and transfer rate. This means
that requestFailTime, the estimated cost of a retry, a dominating
component in the NGRouting formula, now varies depending on the file
size as
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv17122/src/freenet/node/rt
Modified Files:
StandardNodeStats.java StandardNodeEstimator.java
Log Message:
6352:
Fix the bug that was causing stats.maxTransferFailedTime, and therefore the initial
Unstable 6352 is in CVS. This fixes the bug that caused the initial
transfer failed time to be 0 on some estimators, and increments the
(non-backwards-compatible) estimator passing version number, so that we
don't need to worry about old builds with bad (optimistic) initial
estimators (we can
Update of /cvsroot/freenet/freenet/src/freenet/node/ds
In directory sc8-pr-cvs1:/tmp/cvs-serv28920/src/freenet/node/ds
Modified Files:
FSDataStore.java DataStore.java
Log Message:
6353:
When we send out maintenance requests, when we get FCP or internal requests with skip
datastore
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FNP
In directory sc8-pr-cvs1:/tmp/cvs-serv28920/src/freenet/node/states/FNP
Modified Files:
NewInsertRequest.java NewDataRequest.java
Log Message:
6353:
When we send out maintenance requests, when we get FCP or internal requests
Update of /cvsroot/freenet/freenet/src/freenet/node/states/announcing
In directory sc8-pr-cvs1:/tmp/cvs-serv28920/src/freenet/node/states/announcing
Modified Files:
NewInitialRequest.java
Log Message:
6353:
When we send out maintenance requests, when we get FCP or internal requests with
Update of /cvsroot/freenet/freenet/src/freenet/client
In directory sc8-pr-cvs1:/tmp/cvs-serv28920/src/freenet/client
Modified Files:
InternalClient.java
Log Message:
6353:
When we send out maintenance requests, when we get FCP or internal requests with skip
datastore enabled:
Don't
Update of /cvsroot/freenet/freenet/src/freenet/message
In directory sc8-pr-cvs1:/tmp/cvs-serv28920/src/freenet/message
Modified Files:
DataSend.java
Log Message:
6353:
When we send out maintenance requests, when we get FCP or internal requests with skip
datastore enabled:
Don't actually
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv28920/src/freenet/node/rt
Modified Files:
NGRouting.java
Log Message:
6353:
When we send out maintenance requests, when we get FCP or internal requests with skip
datastore enabled:
Don't
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv28920/src/freenet/node
Modified Files:
NewNodeContactor.java
Log Message:
6353:
When we send out maintenance requests, when we get FCP or internal requests with skip
datastore enabled:
Don't
Update of /cvsroot/freenet/freenet/src/freenet/node/states/request
In directory sc8-pr-cvs1:/tmp/cvs-serv28920/src/freenet/node/states/request
Modified Files:
Pending.java InsertPending.java DataPending.java
AwaitingInsert.java
Log Message:
6353:
When we send out maintenance
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FCP
In directory sc8-pr-cvs1:/tmp/cvs-serv28920/src/freenet/node/states/FCP
Modified Files:
NewClientPut.java NewClientGet.java
Log Message:
6353:
When we send out maintenance requests, when we get FCP or internal requests with
Freenet unstable build 6353 is in CVS, snapshots are updating.
Changes:
When we refetch a recent key for maintenance of the routing table, when
we get an FCP request with RemoveLocalKey, when we do an internal
request with skip datastore enabled, don't actually delete the file from
the store,
Hi All. Time for one of my regular progress reports:
Next Generation Routing is in, and we are working feverishly to weed out
the bugs, and coax it into working nicely. The process is challenging
as often the effects of changes cannot be seen for several days, but we
are making progress. We
His analysis applies to any large-scale p2p network. There are at least
two defenses: either create some sort of certification authority (perhaps
a supervisory p2p network) or allow/encourage fragmentation of the target
network.
Come now, This is not impossible. GNUnet does it.
36 matches
Mail list logo
