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>

Reply via email to