On Thursday 24 September 2009 19:26:41 Evan Daniel wrote: > Looking at the success rate by HTL data collected so far, a couple > thoughts come to mind. > > First, SSK success rates plummet after the first few hops. That is, > most routing of most SSKs is extra work done by Freenet for no obvious > gain. The obvious reason behind this is that there are far fewer SSKs > in existence than there is cache space to hold them, and therefore > they are widely duplicated and easy to find when they exist. The > majority of SSK requests come from messaging apps, which are > continually searching for SSKs that have not yet been inserted and > won't succeed at any HTL. For example, my node has 404256 SSK keys in > its cache, and 11730 in its store, out of a possible 3068886 (cache > 13% full, store 0.4% full). > > My long term average SSK success rates (from 370 hours and 2.3M > incoming requests worth of data): > 18 0.030522 > 17 0.031987 > 16 0.023655 > 15 0.012110 > 14 0.006276 > 13 0.003499 > 12 0.001903 > 11 0.001233 > 10 0.000927 > 9 0.000702 > 8 0.002313 > 7 0.000673 > 6 0.000447 > 5 0.000223 > 4 0.000215 > 3 0.000259 > 2 0.000147 > 1 0.000139 > > Should we consider reducing the max HTL for SSK requests in order to > reduce network load? Is there a way to get a similar effect with > recently failed tables? > > The complement to this data is that CHK success rates have not > completely tapered off by HTL 1 (on 1.6M requests total): > 18 0.5007 > 17 0.4781 > 16 0.4580 > 15 0.3722 > 14 0.2895 > 13 0.2297 > 12 0.1873 > 11 0.1635 > 10 0.1441 > 9 0.1274 > 8 0.1139 > 7 0.1010 > 6 0.0945 > 5 0.0855 > 4 0.0775 > 3 0.0698 > 2 0.0602 > 1 0.0499 > > If we assume that failed CHK requests will be retried (that is, most > CHK requests come from persistent download queues, rather than FProxy > browsing), then it might be the case that slightly increased HTLs > would result in a net decrease in load, because fewer failed requests > will be retried. If 1/20 requests that would normally be killed > because they ran out of HTL would succeed if they were routed one > additional hop, then adding another hop would increase average load by > a factor of 23/22 per request, but reduce the number of retries by a > factor of 19/20, for a net decrease in load.
The figure for 1 htl includes the probabilistic decrement at 1 - 4 hops. > > The data I have from edt's node shows similar trends, though the > specifics vary. His node has a lower high-htl success rate than mine, > but a higher low-htl success rate. I'm not sure precisely what to > attribute this to. > > Evan Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090924/86833a81/attachment.pgp>
