On Tuesday 30 Aug 2011 21:02:54 Arne Babenhauserheide wrote:
> Am Dienstag, 30. August 2011, 01:08:16 schrieb Arne Babenhauserheide:
> > 5) solution: count each SSK as only
> > average_SSK_success_rate * data_to_transfer_on_success.
>
> Some more data:
>
> chances of having at least this many successful transfers for 40 SSKs with a
> mean success rate of 16%:
>
> for i in {0..16}; do echo $i $(./spielfaehig.py 0.16 40 $i); done
>
> 0 1.0
> 1 0.999064224991
> 2 0.99193451064
> 3 0.965452714478
> 4 0.901560126912
> 5 0.788987472629
> 6 0.634602118184
> 7 0.463062835467
> 8 0.304359825607
> 9 0.179664603573
> 10 0.0952149293922
> 11 0.0453494074947
> 12 0.0194452402752
> 13 0.00752109980912
> 14 0.0026291447461
> 15 0.000832100029072
> 16 0.00023879002726
>
> what this means: if a SSK has a mean success rate of 0.16, then using 0.25 as
> value makes sure that 95% of the possible cases don?t exhaust the bandwidth.
> We then use only 64% of the bandwidth on average, though. With 0.2, we?d get
> 68% of the possible distributions safe and use 80% of bandwidth on average.
Only if there are no clusters - a single requestor fetches a bunch of stuff
that is all already there, rather than polling keys that usually aren't. IMHO
there will be. For instance, when a new chat client is started up, a lot of
what it does will be fetching existing messages rather than polling for new
ones.
-------------- 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/20110831/dfa74946/attachment.pgp>
