On Wed, 10 Oct 2001, Oskar Sandberg wrote: > On Tue, Oct 09, 2001 at 05:23:36PM -0500, thelema wrote: > > On Tue, 09 Oct 2001, Ian Clarke wrote: > < > > > > It is nothing to do with having something published in Freenet, it is > > > the simple mathematics of it. See GJs freesite. > > > > > I've read the freesite. That argument was proposed when this argument > > was first had. I'm still confused as to why the argument is convincing > > this time. The 10% retrieval failure rate is, in my opinion, highly > > exaggerated, and if freenet faile to retrieve a file 10% of the time you > > request it, we should fix *that*, not put more data into freenet which > > will push chunks out faster. > > It hardly matters whether retrieval success is 90% or 99%, if you are > trying retrieve 100 parts without redundancy you are still fucked (2e-5% > or 36% success). In a system where retrieval cannot be guaranteed, > redundancy is necessary when splitting so as to offset the normal > exponential decay when a file is split into many parts. It is ridiculous > that we should sacrifice aspects of the network to achieve 1 in 1000 > failure rather than something acceptable like 1 in 50 or 100, so that > files split into 100 parts "only" should fail 1 time in 10. > I'm just suprised that everyone now seems to agree that we need redundancy when before everyone seemed to be saying "hell no, keep that redundancy away", and I had to compromise with a system that allowed both redundant and non-redundant usage. What about the argument that goes sorta like "when you insert more data into freenet that'll cause the pieces of other files to fall out faster"? Or the arguments about piece popularity being not as high when there's redundant pieces, and that causing pieces to fall out faster.
I'd like to clarify my position, which probably seems to be against redundancy if you just read the above, but I really think that we should try non-redundant splitfiles and if they really can't be requested successfully, we should try adding a *little* bit of redundancy and see how that improves things, and not to go overboard with the redundancy. Thelema -- E-mail: thelema314 at bigfoot.com If you love something, set it free. GPG 1536g/B9C5D1F7 fpr:075A A3F7 F70B 1397 345D A67E 70AA 820B A806 F95D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20011010/3493e12b/attachment.pgp>
