On Thu, Aug 07, 2003 at 10:26:43PM -0400, Scott Young wrote: > > On Thu, Aug 07, 2003 at 09:21:43PM -0400, Scott Young wrote: > > > The problem with that is that it's hard to tell when the upstream > > > connection is maxed out. > > > > Well, yes if you mean the actual upstream connection, but I mean the > > permitted upstream bandwidth allocated to Freenet. > > Well, what if a node sets it to unlimited?
Then your proposal is screwed too - so it isn't really relevant to a comparitive discussion. > What if the node is > configured with an appropriate value, but starts up KaZaA and KaZaA hogs > a lot of the badwidth? Ditto. > > Yes, but NGR needs to learn who is the fastest server, if the servers > > are constantly getting and finishing with customers then this will > > fluctuate too quickly for NGR to track. > > I guess you could be right... if the entire network is doing NGR then > there might still be a general tendency for too many connections to be > opened. In that case, many of the nodes with NGR might still end up in > the same situation we're in now, but maybe just a little better. So > NGR != Global Optimum. NGR is largely irrelevant to this debate since NGR will make any load-balancing mechanism perform better, whether it is yours or mine. > So what precisely is it that we're aiming for? Rank these in order of > best to worst: > > 1. 200 connections with 0.1 k/sec each > 2. 10 connections with 2 k/sec each > 3. 4 connections with 5 k/sec each > 4. 1 connection with 20 k/sec (4) is better - since in a given period of time it will serve just as many connections as (1), but it will take 1/200th of the time to do it. > If we assume the exact number of connections listed above can remain > open at any given time (i.e. as soon as one request finishes, another > one starts at the same speed), then the fourth one is probably the > best. It would handle the same number of QPH, but transfers data much > faster. Although, 4 won't work well because the assumption is false. No, (4) is better even if your assumption is false. > And also, what is the cost to overall network latency when nodes are > QueryRejecting most requests so that the minimum number of connections > can be achieved? It isn't the minimum number of connections, it is the maximum number of connections such that existing connections aren't slowed down by new connections. > What should happen is some type of balancing mechanism that > automatically balances toward the best spot between many slow > connections and fewer fast connections. Ah, so your response to my pretty specific proposal is some hand-wavey concept of automatic balancing - get back to me when you know how to do it, because only then will I be able to explain why you are wrong. Ian. -- Ian Clarke [EMAIL PROTECTED] Coordinator, The Freenet Project http://freenetproject.org/ Weblog http://slashdot.org/~sanity/journal
pgp00000.pgp
Description: PGP signature
