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% > > 05 2/100 2% > > 08 0/100 0% > > 11 0/100 0% > > 14 0/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% > 02 4/100 4% > 03 3/100 3% > 04 1/100 1% > 05 4/100 4% > 06 1/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>