On Mon, Jan 5, 2009 at 1:12 PM, Matthew Toseland <toad at amphibian.dyndns.org> 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 > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I would think 10 peers is too low, perhaps split the difference at 15? 0-10kB/sec : 15 peers 12kB/sec : 16 peers 14kB/sec : 17 peers ... 20kB/sec : 20 peers ... 60kB/sec : 40 peers Or the same, but 3kB/sec for each new peer: 0-10kB/sec : 15 peers 13kB/sec : 16 peers 16kB/sec : 17 peers ... 25kB/sec : 20 peers ... 85kB/sec : 40 peers = 85% of a 768Kb upload connection -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: http://getfiregpg.org iD8DBQFJYr1G4esu1mlKOs8RAnTQAJ9IRDkguSbTeYlrtDRslgOcdDdjYQCeOkqc qHTxNWZmaPRxP/GzBWYizfI= =sxlj -----END PGP SIGNATURE-----
