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 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 _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
