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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
