On Tuesday 06 January 2009 14:59, Daniel Cheng wrote: > On Tue, Jan 6, 2009 at 10:42 PM, Florent Daigniere > <nextgens at freenetproject.org> wrote: > > Matthew Toseland wrote: > >> On Tuesday 06 January 2009 12:15, Florent Daigniere wrote: > >>> Matthew Toseland wrote: > >>>> On Wednesday 31 December 2008 14:23, Matthew Toseland wrote: > >>>>> #1: 41 votes : release the 20 nodes barrier > >>>>> > >>>>> "most of the users nowadays have a lot of upload-bandwith available. > >> Myself > >>>>> has about 3Mbits upload, but the limit to connect to not more than 20 > >> nodes > >>>>> results in about 50kb/s max. Please release the limit or use a dynamic > >>>> system > >>>>> that offers more connections if the node has a high bandwith upload limit > >>>>> (scaling). Thx" > >>>>> > >>>>> I'm not sure what to do about this. The original rationale for the 20 > >> peers > >>>>> limit was that we didn't want to disadvantage darknet nodes too much on a > >>>>> hybrid network, since they will not often have large numbers of peers. > >>>>> Combined with experience on 0.5 suggesting that more peers is not always > >>>>> better, a security concern over over-reliance on ubernodes, and the fact > >>>> that > >>>>> we should eventually be able to improve bandwidth usage through better > >> load > >>>>> management. However, there's a limit to what we are able to achieve > >> through > >>>>> better load management, and it's a difficult problem. > >>>>> > >>>>> Thoughts? > >>>> As people have pointed out, many people only have access to very slow > >>>> connections. Vive seems to think there is no theoretical problem with > >>>> this ... so the remaining questions: > >>>> - What should the minimum number of peers be? > >>>> - What should the maximum number of peers be? > >>>> - How much output bandwidth should we require for every additional peer? > >>>> > >>>> For the first, a safe answer would be 20, since that's what we use now; > >>>> clearly it won't seriously break things. IMHO less than 1kB/sec/peer is > >>>> unreasonable, but I might be persuaded to use more than that. And we > >> probably > >>>> should avoid adding more peers until we've reached the minimum bandwidth > >> for > >>>> the lower limit. Vive suggested a limit of 50, I originally suggested > >> 40 ... > >>>> probe requests continue to show approximately 1000 live nodes at any given > >>>> time, so we don't want the upper limit to be too high; 100 would certainly > >> be > >>>> too high. > >>>> > >>>> One possibility then: > >>>> > >>>> 0-20kB/sec : 20 peers > >>>> 21kB/sec : 21 peers > >>>> ... > >>>> 40kB/sec+ : 40 peers > >>>> > >>>> Arguably this is too fast; some connections have a lot more than 40kB/sec > >>>> spare upload bandwidth. Maybe it shouldn't even be linear? Or maybe we > >> should > >>>> have a lower minimum number of peers? > >>>> > >>>> 0-10kB/sec : 10 peers > >>>> 12kB/sec : 11 peers > >>>> 14kB/sec : 12 peers > >>>> ... > >>>> 70kB/sec : 40 peers > >>>> > >>> Yay, more alchemy! > >> > >> More alchemical than an arbitrary 20 peers limit? I suppose there are more > >> parameters... > > > > See below; it's not about changing the alchemy; it's about changing it now. > > > >>> What's the reason why we are considering to raise the limit again? > >> > >> To improve performance on opennet, in the average case, for slow nodes, and > >> for fast nodes? > >> > >>> It's > >>> not the top-priority on the uservoice thingy anymore. Anyway, I remain > >>> convinced that ~50 votes is irrelevant (especially when we consider that > >>> a single user can give 3 voices to the same task!) and that we shouldn't > >>> set priorities depending on what some "vocal" users are saying. > >>> > >>> They are concerned by their bandwidth not being sucked up? Fine! Turn > >>> them into seednodes, create a distribution toadlet, create a special > >>> mode where they would only serve UoMs (and would be registered by > >>> seednodes as such)... They are plenty of solutions to max out their > >>> upload bandwidth usage if that's what they want their node to do! > >> > >> Don't you think that more opennet peers for fast nodes, and maybe fewer for > >> really slow nodes, would improve performance for everyone? > > > > Fewer peers for slow nodes would help in terms of latency; I'm not sure > > about more for fast nodes. > > > >> Given that our > >> current load management limits a node's performance by the number of its > >> peers multiplied by the average bandwidth per peer on the network? > >> > > > > IMHO it's a lot more trickier to do than to bump one constant! Anyway, > > ugh..... > Did anybody notice we have this dynamic already? > > r19603 Scale so 20 peers at 16K/sec. > r19602 Scaling of peers with bandwidth > > That's in April 2008.
It's turned off at present. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090106/c60c74d6/attachment.pgp>
