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. > that's not the point: the point is you're about to merge a new > client-layer AND considering to change yetAnotherParameter which might > have network wide effects in the meantime. All of that in a short > timeframe and right before a release (unless I missed something the > release is still planned for "soon")! > > It's bad practice. > > Suppose things get screwed up (or drastically improve): how will you say > which of your changes have caused it? It's not like the theoreticians > knew for sure what the effects are going to be: they said "it shouldn't > break things" ... not that it won't or can't. > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
