On Mon, Nov 03, 2003 at 12:10:13AM -0800, Tracy R Reed wrote: > On Sun, Nov 02, 2003 at 11:12:33PM +0000, Ian Clarke spake thusly: > > > If you expect only a .08% psuccess > > > > How do you know that 92% of requests aren't for data that isn't in the > > network. > > You are implying that frost is the cause of this? If that's the case I > think the frost project has to die because it is killing the rest of the > network. But I'm not sure that it is. It would be nice if there were a
That is not a solution. Frost works, somebody would reimplement it, we have no enforcement capability against them, and if frost died now somebody would reintroduce it post 1.0 and mess up a network adapted to no Frost. We need to make Freenet work WITH Frost. > psuccess measurement which did not include KSK's. With an 8% psuccess rate Impossible. KSKs are the same as SSKs. HOWEVER, we could measure psuccess of CHKs... which are very unlikely to be polled, and hold the majority of real content. > I would have to insert a splitfile with around 1000% redundancy to be able > to get it on the first try. Is that what you propose that we do? Or do we > just click retry a whole lot of times and cross our fingers? I haven't > been able to receive TFE for a couple days and my node has 20G of data in > the store and a DS-3 and has been up for months. Others can retrieve it so > it was definitely inserted today. I recall someone on the channel once > reported a 25% psuccess and you were impressed. Doesn't it seem odd to you > that you would buy that as a possible realistic number and now you ask us > to consider that perhaps 92% of requests are for data that isn't in the > network? Well, I'll implement a CHK-only psuccess immediately. Thanks for the idea. > > Freenet is still has a long way to go to get away from alchemy. It's as if > there is no scientific process. The above is a good example. Regarding the > major routing bugs that were found: Wouldn't some basic sanity checking > have caught those? I suggested breaking out some of the methods in the > routing table and providing some inputs and checking that sane outputs > were produced and he seemed to scoff. Not necessarily, how do you test routing? > > Reskill made a good point also: The 692 network DID perform better than > the unstable network when the unstable network had just as few nodes. We > found this out when unstable forked into its own network. Looks like the > theory that any build would work well with so few nodes was incorrect too. That was because of the anti-NGR bug. > > > For the millionth time, just because there is no obvious specialization > > doesn't mean that something is wrong! The specialization might not be > > obvious for any number of reasons other than that Freenet's routing > > isn't doing what it should. > > You have been saying this since before the two major bugs (and probably a > number of smaller ones) were found that ensured that routing would never > work. Had everyone believed it then perhaps the bugs would not have been > found. Why should we believe it now? If the routing is that "nonobvious" > then it is too complicated to actually work. I still don't understand how > freenet will ever scale without specialization. The need for > specialization was made pretty clear in your original papers and the > simulations. > > I have a challenge for you: Name one other computer program that works yet > nobody can explain how. And you intend to put Freenet on this list? I just > don't buy the "nonobvious" routing theory. > > -- > Tracy Reed > http://copilotconsulting.com -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
