--- snip: Request made twice politely remains unacknowledged --- The code was designed so that you could replace one RoutingTable implementation with another. Could you please back out your changes to CPAlgoRoutingTable and move your new implementation to a completely different class? That we can easily test one implementation against the other in an apples-to-apples comparison. --- snip --- Are you going to fix this?
Am I really the only one seeing this problem? --gj On Tuesday 24 December 2002 11:25, you wrote: > > On Tue, Dec 24, 2002 at 04:06:16PM +0000, Matthew Toseland wrote: > > On Tue, Dec 24, 2002 at 11:39:58AM -0500, Gianni Johansson wrote: > > > On Monday 23 December 2002 19:28, you wrote: > > > > > On Sun, Dec 22, 2002 at 12:27:12PM -0500, Gianni Johansson wrote: > > > > > Matthew: > > > > > I am seeing significantly slower performance since the > > > > > CPAlgoRoutingTable was changed. > > > > > > > > Empirical evidence or even a systematic anecdote would be of > > > > interest. > > > > > > 0) My load average is higher by a factor of 1.5 to 2.0 > > > 1) Page loads in fproxy are excruciatingly slow > > > 2) Load average increases noticably when downloading freesites with > > > fproxy. This was not the case with the previous implementation. > > > > This suggests that your node is doing more work. What is your local load > > average like? Are you running a permanent node? > > I mean the network load average - see the Network Load infolet. 5500 to 6500 queries an hour, which is pretty much the same as it was before. > > > > > > The code was designed so that you could replace one RoutingTable > > > > > implementation with another. Could you please back out your > > > > > changes to CPAlgoRoutingTable and move your new implementation to a > > > > > completely different class? That we can easily test one > > > > > implementation against the other in an apples-to-apples comparison. > > > > > > > > Easily test the routing table? How, exactly? > > > > > > Easy comparison of the effects of the different routing table > > > implementations on the node's performance. > > > > No, it's NOT easy. > > > > > Scipients (oskars/ians?) design allows you to plug in any RoutingTable > > > implementation when the node is constructed. When you move your code > > > into it's own class, we can switch back and forth between rt > > > implementations at startup time with a cli parameter value. > > > > > > If the performance problems go away with the old code, then we know > > > there is still work to be done on your implementation. If they don't > > > then we know your rt changes are not responsible for the problem. > > > > > > See freenet.node.Main.main: > > > > > > > > > RoutingTable rt = new CPAlgoRoutingTable(routingStore, > > > Node.rtMaxNodes, > > > Node.rtMaxRefs, > > > Core.randSource); > > > > > > // Comments left over from when I replaced scipients routing table impl > > > -- gj // RoutingTable rt = new > > > ProbabilityRoutingTable(routingStore, // > > > Node.rtMaxNodes, // > > > Node.rtMaxRefs, // > > > > > > > > Thanks. > > > > > > > > > > --gj > > > > -- > > Matthew Toseland > > toad at amphibian.dyndns.org > > amphibian at users.sourceforge.net > > Freenet/Coldstore open source hacker. > > Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 > > http://freenetproject.org/ ---------------------------------------- Content-Type: application/pgp-signature; charset="us-ascii"; name="Attachment: 1" Content-Transfer-Encoding: 7bit Content-Description: ---------------------------------------- _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
