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>