On Mon, May 4, 2009 at 11:33 AM, Matthew Toseland <t...@amphibian.dyndns.org> wrote: > 1. Release the 20 nodes barrier (206 votes) > > As I have mentioned IMHO this is a straightforward plea for more performance.
I'll reiterate a point I've made before. While this represents a simple plea for performance, I don't think it's an irrational one -- that is, I think the overall network performance is hampered by having all nodes have the same number of connections. Because all connections use similar amounts of bandwidth, the network speed is limited by the slower nodes. This is true regardless of the absolute number of connections; raising the maximum for fast nodes should have a very similar effect to lowering it for slow nodes. What matters is that slow nodes have fewer connections than fast nodes. For example, the max allowed connections (and default setting) could be 1 connection per 2KiB/s output bandwidth, but never more than 20 or less than 15. Those numbers are based on some (very limited) testing I've done -- if I reduce the allowed bw, that is the approximate number of connections required to make full use of it. Reducing the number of connections for slow nodes has some additional benefits. First, my limited testing shows a slight increase in payload % at low bw limits as a result of reducing the connection count (there is some per-connection network overhead). Second, bloom filter sharing represents a per-connection overhead (mostly in the initial transfer -- updates are low bw, as discussed). If (when?) implemented, it will represent a smaller total overhead with fewer connections than with more. Presumably, the greatest impact is on slower nodes. On the other hand, too few connections may make various attacks easier. I have no idea how strong an effect this is. However, a node that has too many connections (ie insufficient bw to use them all fully) may show burstier behavior and thus be more susceptible to traffic analysis. In addition, fewer connections means a larger network diameter on average, which may have an impact on routing. Lower degree also means that the node has fewer neighbor bloom filters to check, which means that a request is compared against fewer stores during its traversal of the network. I'm intentionally suggesting a small change -- it's less likely to cause major problems. By keeping the ratio between slow nodes (15 connections) and fast nodes (20 connections) modest, the potential for reliance on ubernodes is kept minimal. (Similarly, if you want to raise the 20 connections limit instead of lower it, I think it should only be increased slightly.) And finally: I have done some testing on this proposed change. At first glance, it looks like it doesn't hurt and may help. However, I have not done enough testing to be able to say anything with confidence. I'm not suggesting to implement this change immediately; rather, I'm saying that *any* change like this should see some real-world testing before implementation, and that reducing the defaults for slow nodes is as worthy of consideration and testing as raising it for fast nodes. Also: do we have any idea what the distribution of available node bandwidth looks like? Evan Daniel _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
