Date: Sat, 22 Jan 2000 23:34:34 +1300 From: Joe Abley <jabley@patho.gen.nz> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: 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: <20000122233433.A2555@patho.gen.nz> In-Reply-To: <200001220123.RAA59410@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on Fri, Jan 21, 2000 at 05:23:17PM -0800 References: <200001220021.QAA22981@rah.star-gate.com> <200001220123.RAA59410@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 21, 2000 at 05:23:17PM -0800, 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.
>
> 15 lines of perl should be more than enough :-)
Unfortunately, timing a three-way handshake would give you a very
coarse measurement of the packet loss, jitter and bandwidth between the
client and server. It would give you a better measurement of the
latency, but still (statistically speaking) quite a poor one.
Cvsup sessions tend to be long-lived, which means other factors
can have much more dramatic effect on session performance:
+ packet loss
+ path bandwidth
+ optimisation of TCP stacks at either end to the round-trip
latency of the network path (RFC1323 and SACK support, for example)
The only effective way to _really_ measure the cumulative effect of
all these is to model a representative cvsup session to multiple servers,
and compare performance. This is pretty much what John was recommending
in the first place by "why not try a different server every once in
a while" :)
You could automate this like this (and no doubt in other ways):
+ install a small, representatively-sized but junk collection on
every cvsup mirror server
+ every week (say) pull the entire junk collection down from scratch
from a selection of likely servers, and store the relative time taken
to do so.
This should give you a relative performance metric between the servers
you measured, hopefully with local network performance variations
cancelled out by the fact that all tests are run around the same time.
Joe
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?20000122233433.A2555>