Date: Mon, 24 Jan 2000 10:23:10 -0500 (EST) From: "Mr. K." <bsd@inbox.org> To: Brad Knowles <blk@skynet.be> Cc: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Amancio Hasty <hasty@rah.star-gate.com>, obrien@FreeBSD.ORG, John Polstra <jdp@polstra.com>, current@FreeBSD.ORG Subject: Re: Please help spread the CVSup mirror load more evenly Message-ID: <Pine.BSF.4.21.0001241020040.12883-100000@inbox.org> In-Reply-To: <v0422080cb4b1fdf66ce1@[195.238.1.121]>
next in thread | previous in thread | raw e-mail | index | archive | help
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, <blk@skynet.be> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0001241020040.12883-100000>