[freenet-dev] Some interesting ExtraInsertsSingleBlock data (from pre-1404)
On Wednesday 21 Sep 2011 20:58:44 Matthew Toseland wrote: > From FMS: > > ExtraInsertsSingleBlock > > Sadao at JXXNvLaHdNMysx7GmY5~L4aCoMuQV85oJM9OIqhkTR8 wrote : > > > > 600 random files of size <32KB were inserted as CHK (compression=off, > > metadata=on, 2 blocks in total) running build 1403 (NLM=on, AIMD=off) > > and fetched 7 days later running build 1404. Here are the results: > > > > EISB Stuck files Stick ratio > > 00 81/100 81% > > 02 12/100 12% > > 052/100 2% > > 080/100 0% > > 110/100 0% > > 140/100 0% > > > > Maybe I should choose more small EISBs with lesser step between them, > > i.e. EISB=0,1,2,3,4,5,6, and to repeat the test in build 1404, that is > > definitely better than the previous one. But 12% stuck files with > > EISB=02 (default Freenet setting) is too much in my opinion. > Some really interesting new data showing that 2 extra-inserts works well but is absolutely vital, and some analysis from me. Sadao at JXXNvLaHdNMysx7GmY5~L4aCoMuQV85oJM9OIqhkTR8 wrote : > I repeated the experiment on build 1404 with the same conditions but > with different values of EISB. I inserted files on weekend and fetched > them 10 days later on weekdays to see if that affects anything. I let > the files to be fetched for about 8 hours and was changing their > priority from time to time. Here are the results: > > EISB Stuck files Stuck ratio > 00 38/100 38% > 01 20/100 20% > 024/100 4% > 033/100 3% > 041/100 1% > 054/100 4% > 061/100 1% > > I expected to see linear dependence but there is a jump between EISB=01 > and EISB=02. It's strange for me. Anyway, EISB=02 is optimal for good > freenet builds like 1404. But I still think that EISB=05 makes sense for > poor builds like 1403. Now that's more like it! :) Thanks for the very encouraging statistics! Load management improvements should EVENTUALLY improve this further, reducing the need for extra inserts: - Smoother fair sharing in preemptive rejections. - Sending the slow-down signal back to the AIMDs *before* we start rejecting stuff. - Possibly some queueing, provided we separate load management for SSKs from that for CHKs first to decouple the feedback loops and therefore the queueing times. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20111010/56ec13c9/attachment.pgp>
Re: [freenet-dev] Some interesting ExtraInsertsSingleBlock data (from pre-1404)
On Wednesday 21 Sep 2011 20:58:44 Matthew Toseland wrote: From FMS: ExtraInsertsSingleBlock Sadao@JXXNvLaHdNMysx7GmY5~L4aCoMuQV85oJM9OIqhkTR8 wrote : 600 random files of size 32KB were inserted as CHK (compression=off, metadata=on, 2 blocks in total) running build 1403 (NLM=on, AIMD=off) and fetched 7 days later running build 1404. Here are the results: EISB Stuck files Stick ratio 00 81/100 81% 02 12/100 12% 052/100 2% 080/100 0% 110/100 0% 140/100 0% Maybe I should choose more small EISBs with lesser step between them, i.e. EISB=0,1,2,3,4,5,6, and to repeat the test in build 1404, that is definitely better than the previous one. But 12% stuck files with EISB=02 (default Freenet setting) is too much in my opinion. Some really interesting new data showing that 2 extra-inserts works well but is absolutely vital, and some analysis from me. Sadao@JXXNvLaHdNMysx7GmY5~L4aCoMuQV85oJM9OIqhkTR8 wrote : I repeated the experiment on build 1404 with the same conditions but with different values of EISB. I inserted files on weekend and fetched them 10 days later on weekdays to see if that affects anything. I let the files to be fetched for about 8 hours and was changing their priority from time to time. Here are the results: EISB Stuck files Stuck ratio 00 38/100 38% 01 20/100 20% 024/100 4% 033/100 3% 041/100 1% 054/100 4% 061/100 1% I expected to see linear dependence but there is a jump between EISB=01 and EISB=02. It's strange for me. Anyway, EISB=02 is optimal for good freenet builds like 1404. But I still think that EISB=05 makes sense for poor builds like 1403. Now that's more like it! :) Thanks for the very encouraging statistics! Load management improvements should EVENTUALLY improve this further, reducing the need for extra inserts: - Smoother fair sharing in preemptive rejections. - Sending the slow-down signal back to the AIMDs *before* we start rejecting stuff. - Possibly some queueing, provided we separate load management for SSKs from that for CHKs first to decouple the feedback loops and therefore the queueing times. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] One click solution
On Sunday 09 Oct 2011 15:34:31 Dirk Bruere wrote: Hi I am involved in a Zero State: http://zerostate.net Given that what we talk about, and intend to do, is not legal in several jurisdictions and that we have an international membership I have been thinking about the possibility of a Freenet based ZS intranet. However, the problem that hit several of us almost instantly was that people have to be quite technically knowledgeable to set it up correctly, and we cannot depend on every member having the necessary skills, or time. What I am looking for is a one click solution ie someone goes to our site, click a link, and then if they approve the installation it all goes ahead with a browser icon on the desktop for them to log in to our site on Freenet. So, they need know nothing about node IDs, security levels etc Does anything like this exist? Okay, the basic obstacles here: 1. If people are expecting to have their computers seized, it is essential to encrypt Freenet, encrypt anything downloaded from Freenet, encrypt media files stored on the hard disk, encrypt swap etc. This is somewhat nontrivial to do automatically and quickly, although bundling a browser can solve some of the problems, and it is possible on recent windows's to turn on swap encryption quickly and easily. 2. Freenet in opennet mode is not terribly secure. In fact it provides a false sense of security, and a relatively weak attacker can trace some posters (depending on their usage patterns). But in darknet mode it needs Friends. 3. Bandwidth autodetection doesn't always work. It would of course be possible to go with a low default if UPnP doesn't figure one out. Occasionally somebody would run it on their 10GB-a-month cheapo ISP and get stuck with either a huge bill or their internet being frozen, and this creates bad publicity. 4. A large enough proportion of users object to anything just grabbing 10% of their disk space. WHAT THE IT IS USING 20GB ALREADY???!?!?!?!. Again this creates negative feeling etc, which can be damaging, and particularly offends more technical users. On the other hand, if you have a simple/advanced toggle... 5. Freenet runs in the background all the time. Performance is substantially improved by doing so, but it is quite heavy both on bandwidth and hardware. Some of this can be streamlined into a basic choice followed by a minimum of questions. We have achieved a great deal with the wizard by asking only for high vs low security, but need to do more. However, for Freenet itself, we cannot get rid of ALL the questions. A custom package for a third party project could however do more. Minor note: The Node id|number thing is actually a randomly generated name. The next build will no longer include it on the pages' titles. You only need a name if you have Friends. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
