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