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 because 20 peers couldn't be sustained with the default bandwidth limit at the time... Anyway, what we are talking about here is increasing the max bound... and that has side effects; At least on the FOAF code as it is implemented right now... Try it out locally: bump the constant and you'll lose all of your peers.
