On Thursday 01 January 2009 17:20, Ian Clarke wrote: > On Thu, Jan 1, 2009 at 6:16 PM, Florent Daignière > <[email protected]> wrote: > >> 2008/12/31 Matthew Toseland <[email protected]>: > >> I'd say lets raise the threshold, perhaps to 40. The arguments > >> against it seem a bit handwavey to justify denying functionality that > >> our user's clearly want. Upload bandwidth is the life-blood of P2P > >> networks, we should use every scrap of it we can get. > >> > > > > At the moment we don't use it, we *waste* it. What about improving the > > payload ratio first? > > What about doing both? I'm assuming we're talking about changing > constants here - a 30 second job.
Whereas improving the payload is considerably harder. However, it would likely make sense to have a sliding scale? 40 peers on a node with only 12K/sec would be madness... IMHO no node should have less than 10 peers, the question is at what point do we start adding more? Some nodes max out 50K/sec with only 20 peers ... Maybe: 0-10K/sec : 10 peers 10K/sec to 70K/sec: add one peer for every 2KB/sec? So 16K/sec (half of 256kbps) gives 13 peers, 28K/sec (half of 448kbps) gives 19 peers, 55K/sec (half of 892kbps) gives 32 peers, 70K+ gives 40 peers. (These are the most common upstream bandwidths in the UK, divided by two as we do). Thoughts? We probably should get some input on this from a theoretical perspective. > > Ian.
pgpe3VqpemRHX.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
