From owner-freebsd-current Mon Jan 24 7:24: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from inbox.org (inbox.org [216.22.145.8]) by hub.freebsd.org (Postfix) with ESMTP id 2C6E914C80; Mon, 24 Jan 2000 07:24:02 -0800 (PST) (envelope-from bsd@inbox.org) Received: from localhost (bsd@localhost) by inbox.org (8.9.3/8.9.3) with ESMTP id KAA13885; Mon, 24 Jan 2000 10:23:10 -0500 (EST) Date: Mon, 24 Jan 2000 10:23:10 -0500 (EST) From: "Mr. K." To: Brad Knowles Cc: "Rodney W. Grimes" , Amancio Hasty , obrien@FreeBSD.ORG, John Polstra , current@FreeBSD.ORG Subject: Re: Please help spread the CVSup mirror load more evenly In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Why don't we use the download accelerator (http://www.lidan.com/) methodology and make simultaneous connections to the top 4 sites as discovered by ping? :) On Mon, 24 Jan 2000, Brad Knowles wrote: > At 5:23 PM -0800 2000/1/21, Rodney W. Grimes wrote: > > > You don't even need to modify the protocol. Just write a small > > tcp program that times the 3 way handshake on open to all the > > servers, take the one with the sortest time and spit that out > > for the user to stuff in his cvsupfile. > > Ahh, yes. But, the latency between the "master" server and the > "slave" servers does not necessarily equal the latency between the > cvsup client and the master or slave servers, and you want to be able > to make intelligent choices based on more than *just* the network > latency between the cvsup client and the servers -- if one is very > close, but that one happens to be cvsup1 and is overloaded most of > the time, then you want to be able to choose other servers that might > not be quite so close, but which are much more lightly loaded. > > > Small numbers of "test" data packets tell you very little about > what the overall network performance is going to be like between any > two sites -- you may have lots of highly bursty traffic on one route > and a slightly higher latency but much more consistent level of > traffic on another route. > > You may have small packets flying through a particular network, > but when you go to actually transfer any data, you find that you get > huge percentages of drops on large packets. > > You may have a very lightly loaded 64KB line between you and your > first choice which shows up fantastically well on the "test" (both > low latency and low quantity of drops), but which starts to suck huge > boulders when it comes to actually transferring data. > > > There are a lot of factors to be considered, and it seems to me > that the best thing is to have some more intelligence in the client, > so that it can do at least a first approximation as to network > latency and available bandwidth between it and the various servers, > and then this could be augmented by additional information that could > be provided by cooperating servers that feed each other information > about the status of the overall network from their perspective, > etc.... > > -- > These are my opinions and should not be taken as official Skynet policy > _________________________________________________________________________ > |o| Brad Knowles, Belgacom Skynet NV/SA |o| > |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| > |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| > |o| http://www.skynet.be Belgium |o| > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. > Unix is very user-friendly. It's just picky who its friends are. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message