Are you doing more testing?
On Saturday 13 June 2009 19:05:36 Evan Daniel wrote: > On Sat, Jun 13, 2009 at 1:08 PM, Matthew > Toseland<toad at amphibian.dyndns.org> wrote: > > Now that 0.7.5 has shipped, we can start making disruptive changes again in > > a few days. The number one item on freenet.uservoice.com has been for some > > time to allow more opennet peers for fast nodes. We have discussed this in > > the past, and the conclusions which I agree with and some others do: > > - This is feasible. > > - It will not seriously break routing. > > - Reducing the number of connections on slow nodes may actually be a gain > > in security, by increasing opportunities for coalescing. It will improve > > payload percentages, improve average transfer rates, let slow nodes accept > > more requests from each connection, and should improve overall performance. > > - The network should be less impacted by the speed of the slower nodes. > > - But we have tested using fewer connections on slow nodes in the past and > > had anecdotal evidence that it is slower. We need to evaluate it more > > rigorously somehow. > > - Increasing the number of peers allowed for fast opennet nodes, within > > reason, should not have a severe security impact. It should improve routing > > (by a smaller network diameter). It will of course allow fast nodes to > > contribute more to the network. We do need to be careful to avoid > > overreliance on ubernodes (hence an upper limit of maybe 50 peers). > > - Routing security: FOAF routing allows you to capture most of the traffic > > from a node already, the only thing stopping this is the 30%-to-one-peer > > limit. > > - Coalescing security: Increasing the number of peers without increasing > > the bandwidth usage does increase vulnerability to traffic analysis by > > doing less coalescing. On the other hand, this is not a problem if the > > bandwidth usage scales with the number of nodes. > > > > How can we move forward? We need some reliable test results on whether a > > 10KB/sec node is better off with 10 peers or with 20 peers. I think it's a > > fair assumption for faster nodes. Suggestions? > > I haven't tested at numbers that low. At 15KiB/s, the stats page > suggests your slightly better off with 12-15 peers than 20. I saw no > subjective difference in browsing speed either way. > > I'm happy to do some testing here, if you tell me what data you want > me to collect. More testers would obviously be good. > > > > > We also need to set some arbitrary parameters. There is an argument for > > linearity, to avoid penalising nodes with different bandwidth levels, but > > nodes with more peers and the same amount of bandwidth per peer are likely > > to be favoured by opennet anyway... Non-linearity, in the sense of having a > > lower threshold and an upper threshold and linearly add peers between them > > but not necessarily consistently with the lower threshold, would mean fewer > > nodes with lots of peers, and might achieve better results? E.g. > > > > 10 peers at 10KB/sec ... 20 peers at 20KB/sec (1 per KB/sec) > > 20 peers at 20KB/sec ... 50 peers at 80KB/sec (1 per 3KB/sec) > > I wouldn't go as low as 10 peers, simply because I haven't tested it. > Other than that, those seem perfectly sensible to me. > > We should also watch for excessive cpu usage. If there's lots of bw > available, we'd want to have just enough connections to not quite > limit on available cpu power. Of course, I don't really know how many > connections / how much bw it is before that becomes a concern. > > 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/20090619/7949b734/attachment.pgp>
