On August 7, 2003 11:02 pm, Ian Clarke wrote: > 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.
Exactly. > > 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. I once implemented this is an overloaded production transaction processing system. The user response time dropped about 50% and it actually did more work over a period of time. Less task switching, lead to a more effecient system which could do more work. My boss at the time did not believe it would work this way. He let me proceed since he trusted me to backout quick if it did not work. It worked. Limiting the work we have to do when the bandwidth limit is exceeded it is GOOD idea. Really. > > 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. Ed _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
