Re: Please help spread the CVSup mirror load more evenly
On Mon, 24 Jan 2000, Rodney W. Grimes wrote:
This does not need to really be a wrapper around cvs, folks should run
a tool 1 time to pick the best guess as to what server they should be
using, stick that value in thier cvsup file and be done with it. If
jdp calls for a ``this server is being overloaded please move'' folks
should rerun the selection tool and pick new servers. This latter
event happens 2 or 3 times a year, it is a waste to run this every time
you start up cvsup and can cause the grief if you change cvsup servers
in 1 hour due to the update policy of the mirrors.
I agree that you need to do it with a "run once (in a blue moon?)" script that
helps you select an appropriate host site. But for now, we can leave that to
"manually select a good site"
Here is a patch that I suggested to John the last time this came up.
Rather than patching the supfiles, I "patch" my local `make` configuration.
Just having this in the code might help steer users to a different site.
If we can get most users off of "cvsup.FreeBSD.ORG", we could change that DNS
CNAME to point the underutilized site of the week.
--- src/Makefile.inc1~ Tue Jan 25 04:12:36 2000
+++ src/Makefile.inc1 Tue Jan 25 04:21:00 2000
@@ -407,17 +407,20 @@
@echo "--"
@echo " Running ${SUP}"
@echo "--"
+.if defined(FreeBSD_SUPSITE)
+SITEFLAGS= -h ${FreeBSD_SUPSITE}
+.endif
.if defined(SUPFILE)
- @${SUP} ${SUPFLAGS} ${SUPFILE}
+ @${SUP} ${SUPFLAGS} ${SITEFLAGS} ${SUPFILE}
.endif
.if defined(SUPFILE1)
- @${SUP} ${SUPFLAGS} ${SUPFILE1}
+ @${SUP} ${SUPFLAGS} ${SITEFLAGS} ${SUPFILE1}
.endif
.if defined(SUPFILE2)
- @${SUP} ${SUPFLAGS} ${SUPFILE2}
+ @${SUP} ${SUPFLAGS} ${SITEFLAGS} ${SUPFILE2}
.endif
.if defined(PORTSSUPFILE)
- @${SUP} ${SUPFLAGS} ${PORTSSUPFILE}
+ @${SUP} ${SUPFLAGS} ${SITEFLAGS} ${PORTSSUPFILE}
.endif
.endif
.if defined(CVS_UPDATE)
--- src/etc/defaults/make.conf~ Tue Jan 25 04:14:36 2000
+++ src/etc/defaults/make.conf Tue Jan 25 04:16:42 2000
@@ -197,6 +197,7 @@
#
#SUP=/usr/local/bin/cvsup
#SUPFLAGS= -g -L 2
+#FreeBSD_SUPSITE= cvsup8.FreeBSD.ORG
#SUPFILE=/usr/share/examples/cvsup/standard-supfile
#SUPFILE1= /usr/share/examples/cvsup/secure-supfile
#PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile
Re: Please help spread the CVSup mirror load more evenly
At 4:43 PM -0500 2000/1/21, Garance A Drosihn wrote: And to my best knowledge, BIND does not support anything like that. Not directly, but I think there are ways you can have it call some external procedure to do "load-balancing" for an IP rotary. We talked about doing this to address a problem here at RPI, but then we figured out an alternate solution so we didn't really get to the point of implementing it. I don't know if that external load-balancing procedure is given the IP address of the host doing the lookup, for instance. There are even ways you can give the same physical IP address to multiple machines, and let routing tricks deal with figuring out the shortest possible path from the client to the server, based on where they are. Take a look at the nameservers for mci.com sometime from multiple different machines around the world. -- These are my opinions and should not be taken as official Skynet policy _ |o| Brad Knowles, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
At 5:07 PM -0500 2000/1/21, Louis A. Mamakos wrote: As John mentioned earlier, what your probably most interested in is patch quality (e.g., minimum packet loss) first and latency second as far as network characteristics are concerned. Simply measure them if you choose rather than trying to understand why the latency is what is. Trying to predict path quality based on observed topology is hard to do in an automated fashion. Sure, you can employ some simply heuristics as a human (e.g., don't go through MAE-EAST - it sucks there) and the occasional traceroute will reduce your candidate list of servers to a likely set which won't suck and are in the same hemisphere. That's fine. But we can at least automate this simple 20%, can't we? -- These are my opinions and should not be taken as official Skynet policy _ |o| Brad Knowles, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
At 10:00 PM -0700 2000/1/21, Warner Losh wrote: Hmmm. A thought just occurred to me. There's no need to measure these things. Lookup all the IP addresses. Do a non blocking connection to each of these machines. First one to come back with the REL16_1 response wins, and all the others get closed and you use that one. Doesn't work. There might be a very low latency but low-bandwidth connection between you and one of the servers, when you (and everyone else) would be better off if you instead connected to a server that shows slightly higher latency but has significantly more bandwidth (or less packet loss, or a less loaded server on the other end, etc...). IMO, there are just too many factors to be considered to apply any one simplistic solution. You need more intelligence on both ends -- These are my opinions and should not be taken as official Skynet policy _ |o| Brad Knowles, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
At 11:34 PM +1300 2000/1/22, Joe Abley wrote: 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. This is a really cool idea! Are you going to be writing some code to do this for us? ;-) -- These are my opinions and should not be taken as official Skynet policy _ |o| Brad Knowles, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
I'm hatching in my head a scheme as follows: you may want to take a look at keith moore's work on what he called sonar. there was code, but the internet draft seems to have expired. keith is usually available at Keith Moore [EMAIL PROTECTED]. randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Brad Knowles wrote: At 4:43 PM -0500 2000/1/21, Garance A Drosihn wrote: And to my best knowledge, BIND does not support anything like that. Not directly, but I think there are ways you can have it call some external procedure to do "load-balancing" for an IP rotary. We talked about doing this to address a problem here at RPI, but then we figured out an alternate solution so we didn't really get to the point of implementing it. I don't know if that external load-balancing procedure is given the IP address of the host doing the lookup, for instance. There are even ways you can give the same physical IP address to multiple machines, and let routing tricks deal with figuring out the shortest possible path from the client to the server, based on where they are. Take a look at the nameservers for mci.com sometime from multiple different machines around the world. however, that would require those ips to be all be controlled by the same network entity (AS). if the aren't, then the complexity and the adminstrative costs of such a method make it totally unworkable. damon -- Damon Conway Black Rock City Ranger...Riding the edge of chaos On the constant path of the Ranger Art To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
At 10:23 AM -0500 2000/1/24, Mr. K. wrote: 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? :) As mentioned before, not all sites allow ICMP packets through their networks. In addition, ping only deals with the network latency issue, and not very well at that -- it's only an instantaneous measure. Since cvsup sessions tend to last relatively long periods of time, even if you were to look at just latency, you would want something that would look at minimum, maximum, standard deviation, and median latency over similar relatively long periods of time. Of course, there are also host loading and bandwidth issues, network congestion drops problems, network route flapping issues, and a whole host of other things that you'd also want to look at. As I said before, I don't think any one simple solution to this problem will do the job. -- These are my opinions and should not be taken as official Skynet policy _ |o| Brad Knowles, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
In message v0422080db4b2007302f4@[195.238.1.121] Brad Knowles writes:
: Doesn't work. There might be a very low latency but
: low-bandwidth connection between you and one of the servers, when you
: (and everyone else) would be better off if you instead connected to a
: server that shows slightly higher latency but has significantly more
: bandwidth (or less packet loss, or a less loaded server on the other
: end, etc...).
Agreed. The making lots of connections was a bad idea. However, I've
rarely seen low latency and low bandwidth go together. I've also
problems connecting accross high loss links more often. Sure, it is a
statistical argument.
I still think that the n connections wouldn't be that expensive. The
cost, iirc, of a connection that drops is very low. I can certainly
see enough problems with it to encourage jdp to not implement it,
despite being the person that proposed it...
: IMO, there are just too many factors to be considered to apply
: any one simplistic solution. You need more intelligence on both
: ends
Agreed. But in the abasense of intellegence at one end is causing
problems at the other end.
FWIW, I've found that *MUCH* better response times since I started
using cvsup{6,7,8} on a regular basis than I was getting from
cvsup{1,2,3}. I'm also seeing much faster response times from 6,7,8
than cvsup-master (yes, I know I'm not supposed to use that, but there
are rare times I need to snag the latest change right away...).
I've not tried cvsup 4,5 in a while, but did have trouble connecting
to 5 while polishing my script.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Mon, Jan 24, 2000 at 02:17:54PM +0100, Brad Knowles wrote: At 11:34 PM +1300 2000/1/22, Joe Abley wrote: 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. This is a really cool idea! Are you going to be writing some code to do this for us? ;-) Can do if people think it is worthwhile. Could be done quite easily in a wrapper to cvsup, I would thought. It _will_ need a static test set to be installed at each of the cvsup mirrors to be useful though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Mon, Jan 24, 2000 at 02:17:54PM +0100, Brad Knowles wrote: At 11:34 PM +1300 2000/1/22, Joe Abley wrote: 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. This is a really cool idea! Are you going to be writing some code to do this for us? ;-) Can do if people think it is worthwhile. Could be done quite easily in a wrapper to cvsup, I would thought. It _will_ need a static test set to be installed at each of the cvsup mirrors to be useful though. This does not need to really be a wrapper around cvs, folks should run a tool 1 time to pick the best guess as to what server they should be using, stick that value in thier cvsup file and be done with it. If jdp calls for a ``this server is being overloaded please move'' folks should rerun the selection tool and pick new servers. This latter event happens 2 or 3 times a year, it is a waste to run this every time you start up cvsup and can cause the grief if you change cvsup servers in 1 hour due to the update policy of the mirrors. This thread should die probably die... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Mon, 24 Jan 2000, Warner Losh wrote: Agreed. The making lots of connections was a bad idea. However, I've rarely seen low latency and low bandwidth go together. I've also problems connecting accross high loss links more often. Sure, it is a statistical argument. I still think that the n connections wouldn't be that expensive. The cost, iirc, of a connection that drops is very low. I can certainly see enough problems with it to encourage jdp to not implement it, despite being the person that proposed it... That's the precise reason I suggested a system that used no probing, had feedback, and forced shared load in spite of user misconfiguration. Got shouted down. Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
In message [EMAIL PROTECTED] Chuck Robey writes:
: That's the precise reason I suggested a system that used no probing, had
: feedback, and forced shared load in spite of user misconfiguration. Got
: shouted down.
One reason I think that you've been shouted down (and me too, since I
had similar ideas) is that people in the past have had problems with
different cvsup servers being at different points in time and have
been screwed to som eextent or another by this time skew.
There is a large resistance to automatically switching cvsup servers.
It is my perception that the cvsup servers are much better now than
they were even 6 months ago (well, cvsup{1,2} do seem to be much more
heavily used than 6,7,8).
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Mon, 24 Jan 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] Chuck Robey
writes:
: That's the precise reason I suggested a system that used no probing, had
: feedback, and forced shared load in spite of user misconfiguration. Got
: shouted down.
One reason I think that you've been shouted down (and me too, since I
had similar ideas) is that people in the past have had problems with
different cvsup servers being at different points in time and have
been screwed to som eextent or another by this time skew.
Oh. If that's a problem, it would be a fatal problem (would be for me,
sometimes).
There is a large resistance to automatically switching cvsup servers.
It is my perception that the cvsup servers are much better now than
they were even 6 months ago (well, cvsup{1,2} do seem to be much more
heavily used than 6,7,8).
Warner
Chuck Robey| Interests include C Java programming, FreeBSD,
[EMAIL PROTECTED] | electronics, communications, and signal processing.
New Year's Resolution: I will not sphroxify gullible people into looking up
fictitious words in the dictionary.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Mon, 24 Jan 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Chuck Robey writes: : Oh. If that's a problem, it would be a fatal problem (would be for me, : sometimes). It used to be a big problem. When cvsup was first getting mirrors, some seemed to update every 15 minutes, while others updated what seemed like every two days. A big part of the problem was contention at the main cvsup server. Since cvsup has gone to cvsup-master this problem has all but disappeared. The mirrors all have good connectivity and can get updates on a timely basis. [some deletions] For people updating 2x a day or less often, I doubt that switching between responding cvsup servers would cause great pain, or any effects at all. It is a hard problem to get right all the time Well, I really hate the idea of lots of network pinging, both because it's not reliable for network probing, not reliable for machine load probing, and causes more congestion, so I wanted a way to force loadsharing, one that allowed some feedback so that real backups could be adjusted to. OTOH, there's no way I will try to fight folks with elephantine memories. I even began looking at Modula-3, seeing if I could offer a diff set to jdp. You know what I realized, and (for some reason) no one in my memory has ever written: modula-3, in features, looks a lot like Java. It's not a stylistic descendant of C like Java is, but featurewise, it is. Warner Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
In message [EMAIL PROTECTED] Chuck Robey writes: : Oh. If that's a problem, it would be a fatal problem (would be for me, : sometimes). It used to be a big problem. When cvsup was first getting mirrors, some seemed to update every 15 minutes, while others updated what seemed like every two days. A big part of the problem was contention at the main cvsup server. Since cvsup has gone to cvsup-master this problem has all but disappeared. The mirrors all have good connectivity and can get updates on a timely basis. In my limited testing recently, I've noticed no measurable time skew between the servers. My methodology wasn't the best in the world. It basically ran the following script a bunch of times: for i in 1 2 3 4 5 6 7 8; do cvsup -h cvsup$i.freebsd.org done and checked to see if files reverted between runs (and yes, I did have delete in the cvsup file). I the 10 or so times I ran it I got access failures for some hosts, but I never saw reversions. Another problem is that if you get partway through an update, the connetion drops and you reconnect to a different cvsup server at a different point in time. In the past reversions have happened. And fairly often when there was a big skew. People still remember that, so there is still resistance to it. Going back further to the sup days, swithcing sup servers was a huge deal. There you had all the attributes of the entire repo updated. Not fun, nor protocol friendly. For people updating 2x a day or less often, I doubt that switching between responding cvsup servers would cause great pain, or any effects at all. It is a hard problem to get right all the time Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
In message [EMAIL PROTECTED] "David O'Brien" writes: : "load" on the mirror. Where "load" is either one of the connection : slots, or actual kernel resource load if I have 20% packet loss and thus : cause a lot of retransmissions to occur. Hmmm. A thought just occurred to me. There's no need to measure these things. Lookup all the IP addresses. Do a non blocking connection to each of these machines. First one to come back with the REL16_1 response wins, and all the others get closed and you use that one. I like this idea, except that some sort of consistency is required - ie, once I've started using cvsupX, I'd like to use it in preference to slightly better machines unless it stays bad for some configurable number of connections Warner -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Before I forget: PLEASE DON'T CC ME ON YOUR REPLIES. I'LL READ THEM IN THE MAILING LIST. THANK YOU. Hmmm. A thought just occurred to me. There's no need to measure these things. Lookup all the IP addresses. Do a non blocking connection to each of these machines. First one to come back with the REL16_1 response wins, and all the others get closed and you use that one. I like this idea, except that some sort of consistency is required - ie, once I've started using cvsupX, I'd like to use it in preference to slightly better machines unless it stays bad for some configurable number of connections Um, guys ... hello? The goal here is to spread the load more evenly. Now it's true that if every CVSup run hits every mirror site that the load will be even. But it will also be a whole helluva lot higher than it is even now. So no, I'm not going to implement any solution that involves pinging or connecting to a bunch of sites every time you start up CVSup. Please, no more pie in the sky ideas. My announcement was simply trying to address a trivial problem for today, namely that too many people are failing to use their brains when filling in that host field in their supfiles. That's all. These fancy solutions are just dandy except they don't solve the problem today and most of them are so complicated that they're extremely unlikely to get implemented (at least by me) any time soon. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
In message [EMAIL PROTECTED] Brian Somers writes: : I like this idea, except that some sort of consistency is required - : ie, once I've started using cvsupX, I'd like to use it in preference : to slightly better machines unless it stays bad for some configurable : number of connections I'm hatching in my head a scheme as follows: Each host gets a value of 1 (unless you go in and tweak it). Hosts are tried in order of their values and in some unspecified order in the case of ties. Host with a value = 0 are never tried. Floating point math is done with the results rounded up to the nearest integer. This keeps people from falling below 1. Users can disable a host by tweaking its value in the config file to be 0. Each time you successfully connect, you get a bonus of B. Each failure reduces the nubmer by x%. I'm thinking that B should be on the order of 10-20 and x should be on the order of 10-20. Try at most twice per host. If all the hosts fail, try the best host in forever mode. No updates should happen here to weightings. Not sure about this method in, say, a cron job... That way, as a host succeeds, it will be tried more often first. As a host fails, it will be tried less often. Over time if host N goes down, its weighting will decay relatively quickly and the next best one will take up the slack I purposely chose a linear scale up, and a non-linear scale down. Of course I don't have time to actually code this up. And it also strikes me as overkill. I'm happy with the fixed order list that I tweak as I notice things going bad... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Sun, Jan 23, 2000 at 06:56:39PM -0700, Warner Losh wrote:
Each host gets a value of 1 (unless you go in and tweak it). Hosts
are tried in order of their values and in some unspecified order in
[...]
Each time you successfully connect, you get a bonus of B.
I think you need to keep an element of randomness to prevent "good
enough" from defeating "best".
Bonus B should be weighted by wire speed. I don't know how to make
cvsup spit this out when in batch mode.
This isn't exactly the algorithm you described. Finding differences
is left as an exercise. Acceptability of the constants chosen for the
algorithm varies with expected usage pattern of script.
This is the type of thing that should really be done in cvsup itself,
but I don't feel like learning Modula-3... :)
I disclaim responsibility for any stupid errors. All subtle errors
are completely my fault.
PS: I don't believe this script will work under Linux. Oops. ;-)
Sample cvshosts.dat file:
50 cvsup1.freebsd.org
50 cvsup2.freebsd.org
50 cvsup3.freebsd.org
50 cvsup4.freebsd.org
50 cvsup5.freebsd.org
50 cvsup6.freebsd.org
50 cvsup7.freebsd.org
50 cvsup8.freebsd.org
And the script,
#! /bin/sh
DATFILE=cvshosts.dat
if [ -z "$1" ];
then
fairings=$( (while read -t 0 host
do
if [ "${host%%[ ]*}" -eq 0 ]
then
continue
fi
fairings="${fairings}
$((${host%% *} * $(jot -r 1 5 9) + $(jot -r 1 1 3))) ${host#*[ ]}"
done; echo "${fairings}") ${DATFILE})
hosts=`echo "$fairings" | sort -rn | awk '{print $2}'`
else
hosts=$1
shift
fi
# Potential security problem, probably
trap 'rm -f /tmp/cvshosts.dat.$$' 0
cp $DATFILE /tmp/cvshosts.dat.$$
echo "Will try hosts $(echo $hosts)"
for host in $hosts
do
echo "Using host $host"
if cvsup -1 -P m -s -g ~/bin/sup/fbsd-supfile -L 2 -h $host
then
# 1 works fairly well as a 2, also
perl -pi -e \
's/^(\d+)[ \t]+'"$host"'[ \t]*$/int (($a=$1+1)100?10:$a) . "'" $host"'"/e' \
$DATFILE
exit;
else
perl -pi -e \
's/^(\d+)[ \t]+'"$host"'[ \t]*$/int (($a=$1-$1\/6)1?1:$a) . "'" $host"'"/e' \
$DATFILE
fi
done
mv /tmp/cvshosts.dat.$$ $DATFILE
trap 0
--
Signature withheld by request of author.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
At 10:43 am -0800 21/1/00, John Polstra wrote: [...] we have 8 mirror sites now, named (duh) cvsup[1-8].FreeBSD.org. The newest, cvsup8, is a very high-capacity and well-connected site, yet hardly anybody is using it. Please give it a try! Hi Might it be worth load sharing these via duplicate dns entries for cvsup.freebsd.org, so that callers get one at random? Best wishes Robin. -- Robin Melville, Addiction Information Service Nottingham Alcohol Drug Team Tel: +44 (0)115 952 9478 Fax: +44 (0)115 952 9421 work: [EMAIL PROTECTED] Pages: http://www.nadt.org.uk/ -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 06:20:38PM -0500, Ben Rosengart wrote: Anyway, if multi CNAME is no good then do: cvsup IN A198.104.92.71 ; cvsup1.freebsd.org cvsup IN A205.149.189.91 ; cvsup2.freebsd.org ... and so on This is legal, is it? Not only is it legal, but I believe BIND will return all the A records to any query, and will rotate them. The problem with this is that any time a cvsup server operator decides to renumber their mirror, they need to inform the soa for freebsd.org (and factor in the freebsd.org TTLs to manage the change). In practice this will not work, and will cause 1/n cvsup attempts to fail after a machine has been renumbered until TTLs expire. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 10:43:39AM -0800, John Polstra wrote: This is another in my series of occasional nags to try to get people to use some of the less heavily loaded CVSup mirrors. In the US alone, we have 8 mirror sites now, named (duh) cvsup[1-8].FreeBSD.org. The newest, cvsup8, is a very high-capacity and well-connected site, yet hardly anybody is using it. Please give it a try! What's wrong with DNS-based load-balancing solution? I.e. cvsup[1-8] CNAME cvsup ; for backward compatibility cvsup A x.x.x.x A y.y.y.y ... A z.z.z.z -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
John Polstra wrote: This is another in my series of occasional nags to try to get people to use some of the less heavily loaded CVSup mirrors. In the US alone, we have 8 mirror sites now, named (duh) cvsup[1-8].FreeBSD.org. The newest, cvsup8, is a very high-capacity and well-connected site, yet hardly anybody is using it. Please give it a try! Ok, I tried it and to my surprise the other ones are faster. I'm one of the many who probably didn't give it much thought and just stuck cvsup.freebsd.org in their cvsup config files. Now, I'm running off cvsup6, which gave me no packet loss, but also seems to have a very fast response time. I'm in Canada, and I've noticed that cvsup.ca.freebsd.org, is the absolute worst server I can possibly use. It seems the american ones are much better. Is cvsup.ca just another pointer to cvsup1 in the US? And I also update PAO3 on a regular basis, and that is the slowest one of them all (coming from cvsup.jp, in Japan). Do any of the US mirror's also mirror PAO3? -- -- Pat Wendorf [EMAIL PROTECTED] ICQ: 1503733 - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
As I recall, John Polstra wrote: In fact, the higher-numbered mirrors often have faster hardware simply because they're newer. Also, in particular, there's nothing special about cvsup.FreeBSD.org -- it's simply an alias for cvsup1 and it gets its updates the same way at the same intervals from the same master server as all the other mirrors. Perhaps we should be so bold as to renumber the servers in the DNS such that the preferred servers have the lower numbers? -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Wes Peters wrote: Amancio Hasty wrote: My only point is that the first response to a problem isn't to necessarily pull out emacs and start hacking away on code. Yea, it is easier to do in a regular zone file then to implement the network measurement logic into cvsup. Yes, it is a rather cool idea to rotate on the cvs servers without respect to latency, work load or rate of service response from the server. Thank you. I was beginning to wonder if I am the only one here who thinks blind round-robin DNS is a bad hack. nope...i was keeping my mouth shut. there are several parts to "load balancing", and that isn't necessarily what we are trying to accomplish here. what is being discussed is a method for determining the best performing cvsup server for a given client. to do this you must check for the following things: 1. network performance from the client to a server - what is our latency? - what is our packet loss? - hop counts are largely irrelevant - icmp could be used to implement this as a start, but due to isps rate limiting icmp at their routers it is not totally reliable. ideally, you will have a tcp layer tansaction that can determine latency and packet loss. (NOTE: this has nothing to do with "balancing" network paths as was mentioned earlier. BGP handles that. your path to a given server from a given client will always be the same unless BGP decides otherwise.) 2. ability of a server to hand out data in a timely manner - what is the server's cpu load? - what is the server's memory capacity? - how many other clients is this server serving? - how quickly does it deliver a test load of data? this is important because while you may be able to reach this server quickly, it may not be able to hand out data in a timely manner. i would recommend writing a verification routine into the cvsup server and client that finds this info. it should look someting like this: client -- server What is my network performance? Is it within tolerance? client --- server What is your ability to serve data to me? client --- server Sure, I can send you data at X tolerance level. client -- server Test pattern... basically, a client can go through a list until it reaches a server within it's tolerance. if it doesn't find a server within tolerance, then it will take the one that is closest to tolerance levels. part one is pretty trivial to implement using icmp. part 2 is more interesting. unfortunatly, i'm not much of a coder and i wouldn't know where to start or i'd do it myself. word of advice tho, don't use the ping utility to do the icmp measurements. due to the interactive nature of it, it has a lot of extraneous junk that isn't relevant, and can skew data. damon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Robin Melville wrote: At 10:43 am -0800 21/1/00, John Polstra wrote: [...] we have 8 mirror sites now, named (duh) cvsup[1-8].FreeBSD.org. The newest, cvsup8, is a very high-capacity and well-connected site, yet hardly anybody is using it. Please give it a try! Hi Might it be worth load sharing these via duplicate dns entries for cvsup.freebsd.org, so that callers get one at random? due to dns caching and the totaly arbitrary nature of this method, it almost never does what you expect it to. damon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
There are couple of RFCs on network load balancing with respect to servers or services and I am sure that there are also widely available research papers. Most of those concentrate on balancing the load on the server itself. How about balancing the load on the network paths, I doubt very much that we have a server load problem near as much as we have a network load problem due to people not having ready access to the data that says ``this server is closest network wise to me''. Hi Rod! Perhaps RFC 2391 may be of use. Network Working Group P. Srisuresh Request for Comments: 2391 Lucent Technologies Category: Informational D. Gan Juniper Networks, Inc. August 1998 Load Sharing using IP Network Address Translation (LSNAT) Enjoy -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Friday, 21 January 2000 at 11:11:40 -0800, John Polstra wrote: Can you make cvsup accept multiple servers to try in it's configuration file? I'll add that to the to-do list. When you get the appropriate tuit, you might also consider checking which of the list is most accessible. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Please help spread the CVSup mirror load more evenly
This is another in my series of occasional nags to try to get people to use some of the less heavily loaded CVSup mirrors. In the US alone, we have 8 mirror sites now, named (duh) cvsup[1-8].FreeBSD.org. The newest, cvsup8, is a very high-capacity and well-connected site, yet hardly anybody is using it. Please give it a try! You can find the full list of mirrors worldwide at: http://www.freebsd.org/handbook/mirrors-cvsup.html Remember, the mirrors are equivalent in the sense that they get their updates from the master server at the same intervals (hourly). There is nothing "better" about the lower-numbered mirrors, and they don't get their updates any sooner or more reliably. In fact, the higher-numbered mirrors often have faster hardware simply because they're newer. Also, in particular, there's nothing special about cvsup.FreeBSD.org -- it's simply an alias for cvsup1 and it gets its updates the same way at the same intervals from the same master server as all the other mirrors. To choose a mirror site, try pinging the mirrors in your country. Pick one with a low packet loss rate. The round trip time doesn't matter very much as long as it doesn't undergo wild variations. Second, pick a site that's not too heavily loaded. If your update _ever_ fails because the server is too busy, then you should try a different mirror -- because there are many mirrors that aren't even close to their full loads even at the busiest of times. Thanks for your cooperation. John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
If the user does specifiy a cvsup , can you decide for the user which server is best based upon some simple statistic? -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 10:43:39AM -0800, John Polstra wrote: To choose a mirror site, try pinging the mirrors in your country. Pick one with a low packet loss rate. The round trip time doesn't matter very much as long as it doesn't undergo wild variations. Second, pick a site that's not too heavily loaded. If your update _ever_ fails because the server is too busy, then you should try a different mirror -- because there are many mirrors that aren't even close to their full loads even at the busiest of times. Thanks for your cooperation. John Can you make cvsup accept multiple servers to try in it's configuration file? Joe -- Josef KarthauserFreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
In article [EMAIL PROTECTED], I wrote: To choose a mirror site, try pinging the mirrors in your country. I have been reminded that a few mirrors (cvsup8 in particular) filter pings. Don't take ping failures as a certain indication that the server is down. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
In article [EMAIL PROTECTED], Amancio Hasty [EMAIL PROTECTED] wrote: If the user does specifiy a cvsup , can you decide for the user which server is best based upon some simple statistic? Some day I hope it's possible, but there's nothing like that implemented currently. Also there are some problems that must be solved first. CVSup needs a way to ensure that your "update" won't in fact be a step backward in time. For example, suppose you update twice in rapid succession, first from server A and then from server B. Both servers update hourly, but at different times. You happen to hit them at a point where A has updated more recently than B. In that case you'll be unhappy because your second "update" will instead be a "downdate" (backdate? bad date?). This is solvable, but not as easily as you might think. Lots of complications arise when, for example, you interrupt an update in the middle such that some files have been updated while others haven't. There is discussion on all this in the mailing list archives somewhere. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
So have the cvsup client do the pinging to the server and extract its current work load or other vital statistic. -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Can you make cvsup accept multiple servers to try in it's configuration file? I'll add that to the to-do list. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
In message [EMAIL PROTECTED] John Polstra writes: : Can you make cvsup accept multiple servers to try in it's configuration : file? : : I'll add that to the to-do list. I have a very crude script that does its own (fixed) round robin of multiple servers. It tries three times fast (yes, I know that's likely bad) and then goes to the next one on the list. If all else fails, it will try the first one on the list in "forever" mode (with the nice random retries). I'll have to see about puitting into good shape and posting it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
At 9:42 PM +0100 1/21/00, Jesper Skriver wrote: On Fri, Jan 21, 2000 at 03:34:42PM -0500, Garance A Drosihn wrote: At 10:43 AM -0800 1/21/00, John Polstra wrote: This is another in my series of occasional nags to try to get people to use some of the less heavily loaded CVSup mirrors. Maybe you should make cvsup.freebsd.org as a rotary (of sorts), which returns a different IP address based on the callers IP address. (or is that even possible?) That way, any given host will always try the same cvsup server, but you'll be spreading the load out among the servers. Dial-up users with dynamic ip address assignment ... You don't do it based on the last digit in the ip address. Do it based on the first number, or maybe the first two numbers. Ie, all IP addresses at RPI are 128.113.*.*, so they would all get the same value for this DNS rotary. If you did it in large enough ranges, it should be pretty consistent even for people coming in via dynamic IP addresses. It'd still be a problem for someone who's on the move a lot, of course (such as a laptop which is sometimes used on the RPI campus, and other times is dialing in thru various ISP's around the country). And to my best knowledge, BIND does not support anything like that. Not directly, but I think there are ways you can have it call some external procedure to do "load-balancing" for an IP rotary. We talked about doing this to address a problem here at RPI, but then we figured out an alternate solution so we didn't really get to the point of implementing it. I don't know if that external load-balancing procedure is given the IP address of the host doing the lookup, for instance. I'm just trying to come up with something that automatically balances the load, while still making it pretty likely that a given host will always get the same cvsup server. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
John Polstra wrote: Can you make cvsup accept multiple servers to try in it's configuration file? I'll add that to the to-do list. A nice heuristic that attempts to minimize latency and maximize throughput would be a nice feature to have. For extra credit, reverse entropy as well. Seriously, attempting to connect to a list of servers using record route and minimizing the latency and/or hop count would be a great little feature to add. It would be a great feature to package into a library. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, 21 Jan 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Chuck Robey writes: : I would think using a fixed order would be a really bad thing, causing : overload of the first server in line. Did I misunderstand you? How about : doing a script (say in perl, it has random numbers) that randomly picks : the server from a list? That way, the list could even be weighted, so as : to allow for greater or lesser machine resources (like net access). That's one of the things I have to fix up. This script is good for me, but bad for everyone. Enhancements like this would be a good thing. Got time? I don't know perl. Darn. Yes, I will learn perl. Now. Warner Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, 21 Jan 2000, Warner Losh wrote: In message [EMAIL PROTECTED] John Polstra writes: : Can you make cvsup accept multiple servers to try in it's configuration : file? : : I'll add that to the to-do list. I have a very crude script that does its own (fixed) round robin of multiple servers. It tries three times fast (yes, I know that's likely bad) and then goes to the next one on the list. If all else fails, it will try the first one on the list in "forever" mode (with the nice random retries). I'll have to see about puitting into good shape and posting it. I would think using a fixed order would be a really bad thing, causing overload of the first server in line. Did I misunderstand you? How about doing a script (say in perl, it has random numbers) that randomly picks the server from a list? That way, the list could even be weighted, so as to allow for greater or lesser machine resources (like net access). Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
A nice heuristic that attempts to minimize latency and maximize throughput would be a nice feature to have. For extra credit, reverse entropy as well. Seriously, attempting to connect to a list of servers using record route and minimizing the latency and/or hop count would be a great little feature to add. It would be a great feature to package into a library. I fear that the effort expended to do anything more than the easy 20% will be wasted. Trying to second-guess end-to-end network characteristics by reading the tea-leaves of a traceroute-like probe is going to be very hard. You should measure the characteristics which are exposed to your application, if possible, and make decisions based on that. For instance, on UUNET's backbone network (of which I happen to know quite a lot about since I did some of the original architecture) has an extensive layer-2 ATM and Frame Relay component used to do traffic engineering. Even though there are multiple layer-2 hops through switches, you can't see any of that using a traceroute-like mechanism. And forget about record route options; that's going to cause the packet to go through the slow forwarding path of the router, which is essentially completely unrelated to experience the packet has without the record route option, other than taking the same path. As John mentioned earlier, what your probably most interested in is patch quality (e.g., minimum packet loss) first and latency second as far as network characteristics are concerned. Simply measure them if you choose rather than trying to understand why the latency is what is. Trying to predict path quality based on observed topology is hard to do in an automated fashion. Sure, you can employ some simply heuristics as a human (e.g., don't go through MAE-EAST - it sucks there) and the occasional traceroute will reduce your candidate list of servers to a likely set which won't suck and are in the same hemisphere. I fear trying to be significantly more clever than that and simple measurements is Very Hard and can probably get you a Ph.D. or a bunch of $$$ or both. If you succeed. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Garance A Drosihn wrote: At 10:43 AM -0800 1/21/00, John Polstra wrote: This is another in my series of occasional nags to try to get people to use some of the less heavily loaded CVSup mirrors. In the US alone, we have 8 mirror sites now, named (duh) cvsup[1-8].FreeBSD.org. The newest, cvsup8, is a very high-capacity and well-connected site, yet hardly anybody is using it. Please give it a try! Maybe you should make cvsup.freebsd.org as a rotary (of sorts), which returns a different IP address based on the callers IP address. (or is that even possible?) That way, any given host will always try the same cvsup server, but you'll be spreading the load out among the servers. Thats not so easy. What about this: cvsup IN CNAMEcvsup1.freebsd.org. cvsup IN CNAMEcvsup2.freebsd.org. cvsup IN CNAMEcvsup3.freebsd.org. cvsup IN CNAMEcvsup4.freebsd.org. cvsup IN CNAMEcvsup5.freebsd.org. cvsup IN CNAMEcvsup6.freebsd.org. cvsup IN CNAMEcvsup7.freebsd.org. cvsup IN CNAMEcvsup8.freebsd.org. If you simply put "cvsup.freebsd.org" into your supfile you'll get randomly one of them. This should spread the load fairly well. If you want a special one then simply put "cvsupX.freebsd.org" into you supfile. Aint that easy? I don't see any appearant reson (short of network connectivity) that one *needs* to get always the *same* server. -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 11:06:40PM +0100, Andre Oppermann wrote: Garance A Drosihn wrote: At 10:43 AM -0800 1/21/00, John Polstra wrote: This is another in my series of occasional nags to try to get people to use some of the less heavily loaded CVSup mirrors. In the US alone, we have 8 mirror sites now, named (duh) cvsup[1-8].FreeBSD.org. The newest, cvsup8, is a very high-capacity and well-connected site, yet hardly anybody is using it. Please give it a try! Maybe you should make cvsup.freebsd.org as a rotary (of sorts), which returns a different IP address based on the callers IP address. (or is that even possible?) That way, any given host will always try the same cvsup server, but you'll be spreading the load out among the servers. Thats not so easy. What about this: cvsup IN CNAMEcvsup1.freebsd.org. cvsup IN CNAMEcvsup2.freebsd.org. cvsup IN CNAMEcvsup3.freebsd.org. cvsup IN CNAMEcvsup4.freebsd.org. cvsup IN CNAMEcvsup5.freebsd.org. cvsup IN CNAMEcvsup6.freebsd.org. cvsup IN CNAMEcvsup7.freebsd.org. cvsup IN CNAMEcvsup8.freebsd.org. If you simply put "cvsup.freebsd.org" into your supfile you'll get randomly one of them. This should spread the load fairly well. If you want a special one then simply put "cvsupX.freebsd.org" into you supfile. Aint that easy? I don't see any appearant reson (short of network connectivity) that one *needs* to get always the *same* server. This has been discussed regulary ... You will risk hitting 2 different server in 2 rapid cvsup run's, where the first may be more up to date than the next, as Jordan wrote earlier in this thread ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE# 5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 04:24:41PM -0500, Chuck Robey wrote: On Fri, 21 Jan 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Chuck Robey writes: : I would think using a fixed order would be a really bad thing, causing : overload of the first server in line. Did I misunderstand you? How about : doing a script (say in perl, it has random numbers) that randomly picks : the server from a list? That way, the list could even be weighted, so as : to allow for greater or lesser machine resources (like net access). That's one of the things I have to fix up. This script is good for me, but bad for everyone. Enhancements like this would be a good thing. Got time? I don't know perl. Darn. Yes, I will learn perl. Now. sh has random numbers. Spelled "jot -r". -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Maybe you should make cvsup.freebsd.org as a rotary (of sorts), which returns a different IP address based on the callers IP address. (or is that even possible?) That way, any given host will always try the same cvsup server, but you'll be spreading the load out among the servers. Thats not so easy. What about this: cvsup IN CNAMEcvsup1.freebsd.org. cvsup IN CNAMEcvsup2.freebsd.org. cvsup IN CNAMEcvsup3.freebsd.org. cvsup IN CNAMEcvsup4.freebsd.org. cvsup IN CNAMEcvsup5.freebsd.org. cvsup IN CNAMEcvsup6.freebsd.org. cvsup IN CNAMEcvsup7.freebsd.org. cvsup IN CNAMEcvsup8.freebsd.org. This is wrong two ways. First, the data associated with a CNAME is supposed to be the cannonical name of a host, and not another domain name with only a CNAME resource record. Second, a domain name can at most a single CNAME record associated with it, and other other record types. BIND will (should) barf on a zone file containing the example you listed. If you simply put "cvsup.freebsd.org" into your supfile you'll get randomly one of them. This should spread the load fairly well. If you want a special one then simply put "cvsupX.freebsd.org" into you supfile. You could play some DNS games to get this effect, though it's not clear what the randomness of the list of resource records is supposed to be. Certain the DNS protocol doesn't define any randomness. I don't see any appearant reson (short of network connectivity) that one *needs* to get always the *same* server. See previous mesasge from John regarding doing two successive updates where the servers are not synchronized with the same version files. Is this really a problem that demands solutions this complicated? The solution isn't necessarily a technological one; a simple email message reminding people of other servers might be sufficient :-) louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Brad Knowles wrote: At 11:06 PM +0100 2000/1/21, Andre Oppermann wrote: Thats not so easy. What about this: cvsupIN CNAMEcvsup1.freebsd.org. cvsupIN CNAMEcvsup2.freebsd.org. cvsupIN CNAMEcvsup3.freebsd.org. cvsupIN CNAMEcvsup4.freebsd.org. cvsupIN CNAMEcvsup5.freebsd.org. cvsupIN CNAMEcvsup6.freebsd.org. cvsupIN CNAMEcvsup7.freebsd.org. cvsupIN CNAMEcvsup8.freebsd.org. As I understood the rules of good Domain Administration, everything that is publicly visible in your network needs to have an MX record. But with this scheme you can't give cvsup.freebsd.org an MX record, because pointing an MX at a CNAME violates the RFC. You can, simply do this: cvsup IN MX 10 hub.freebsd.org No violation of any RFC whatsoever. Personally, I would much prefer the CPAN solution of a program that takes the IP address of the query source, and then using knowledge of what IP addresses are generally located where in the world (available via the whois maps in the various regions, which could presumably be imported and stored locally), returns a short list of addresses in the preferred order. For those networks where multiple addresses may have equal "cost", it can then randomize for load balancing purposes. Don't go by whois, it does not reflect the physical connectivity. Go by BGP path length if you want to do something like this. It requires either a hacked nameserver program for this one zone, or the code to handle this has to be incorporated into cvsup itself, so that you distribute the logic and CPU processing time to all the clients. There are commecial nameservers which decide upon bgp path length but it'll cost some big $$$. -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Andre Oppermann wrote: Jesper Skriver wrote: You will risk hitting 2 different server in 2 rapid cvsup run's, where the first may be more up to date than the next, as Jordan wrote earlier in this thread ... Does it matter? Who cvsup's regulary more than once or twice a day? Committers AFAIK do cvs directly. %cvsup Damn! Forgot I don't want src-sys -- Hit ^C. %vi ~/supfileRemove src-sys %cvsup or %cvsup Damn! Forgot I want to remove sup/src-sys/refuse -- Hit ^C. %rm sup/src-sys/refuse %cvsup Yes, I've done both scenarios. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 11:39:24PM +0100, Andre Oppermann wrote: Does it matter? Who cvsup's regulary more than once or twice a day? Committers AFAIK do cvs directly. I "cvs co" from my local copy of the repository, which is kept up-to-date using cvsup. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Louis A. Mamakos wrote: cvsup IN CNAMEcvsup1.freebsd.org. cvsup IN CNAMEcvsup2.freebsd.org. cvsup IN CNAMEcvsup3.freebsd.org. cvsup IN CNAMEcvsup4.freebsd.org. cvsup IN CNAMEcvsup5.freebsd.org. cvsup IN CNAMEcvsup6.freebsd.org. cvsup IN CNAMEcvsup7.freebsd.org. cvsup IN CNAMEcvsup8.freebsd.org. This is wrong two ways. First, the data associated with a CNAME is supposed to be the cannonical name of a host, and not another domain name with only a CNAME resource record. ??? Are all cvsupX.freebsd.org also CNAME's? Second, a domain name can at most a single CNAME record associated with it, and other other record types. BIND will (should) barf on a zone file containing the example you listed. It does not. It will round-robin over the CNAME's. If you simply put "cvsup.freebsd.org" into your supfile you'll get randomly one of them. This should spread the load fairly well. If you want a special one then simply put "cvsupX.freebsd.org" into you supfile. You could play some DNS games to get this effect, though it's not clear what the randomness of the list of resource records is supposed to be. Certain the DNS protocol doesn't define any randomness. But bind does. I don't see any appearant reson (short of network connectivity) that one *needs* to get always the *same* server. See previous mesasge from John regarding doing two successive updates where the servers are not synchronized with the same version files. Who cvsup's regurlary more than once or twice a day? Committers AFAIK do cvs directly. Is this really a problem that demands solutions this complicated? The solution isn't necessarily a technological one; a simple email message reminding people of other servers might be sufficient :-) Yea, then all swamp cvsup8.freebsd.org and John has to send another message that there are still cvsup[2-7].freebsd.org idling around. Just kidding... But you get the point? -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Second, a domain name can at most a single CNAME record associated with it, and other other record types. BIND will (should) barf on a zone file containing the example you listed. It does not. It will round-robin over the CNAME's. See the documentation for the multiple-cnames option in BIND 8.2.2: If yes, multiple CNAME resource records will be allowed for a domain name. The default is no. Allowing multiple CNAME records is against standards and is not recommended. Multiple CNAME support is available because previous versions of BIND allowed multiple CNAME records, and these records have been used for load balancing by a number of sites. So I'd say this is not a good idea. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Jesper Skriver wrote: On Fri, Jan 21, 2000 at 11:06:40PM +0100, Andre Oppermann wrote: I don't see any appearant reson (short of network connectivity) that one *needs* to get always the *same* server. This has been discussed regulary ... Must have been some time ago... You will risk hitting 2 different server in 2 rapid cvsup run's, where the first may be more up to date than the next, as Jordan wrote earlier in this thread ... Does it matter? Who cvsup's regulary more than once or twice a day? Committers AFAIK do cvs directly. -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Matthew Hunt wrote: On Fri, Jan 21, 2000 at 11:39:24PM +0100, Andre Oppermann wrote: Does it matter? Who cvsup's regulary more than once or twice a day? Committers AFAIK do cvs directly. I "cvs co" from my local copy of the repository, which is kept up-to-date using cvsup. OK, then you should hardwire your cvsup server to cvsup[1-8]. You can master cvs so you can master this. Cvsup.freebsd.org is used by Joe Random and he wont be cvsupping more than once a day. -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 11:56:11PM +0100, Andre Oppermann wrote: OK, then you should hardwire your cvsup server to cvsup[1-8]. You can master cvs so you can master this. I do. Thanks for your vote of confidence in my abilities, though. If you meant "committers use cvs directly or hardwire their cvsup server", maybe you should have written that. -- Matthew Hunt [EMAIL PROTECTED] * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Second, a domain name can at most a single CNAME record associated with it, and other other record types. BIND will (should) barf on a zone file containing the example you listed. It does not. It will round-robin over the CNAME's. If it does, than this is a bug in BIND. The DNS is not defined to work this way. Semantically, it doesn't make sense to have more than one CNAME record. The CNAME resource record is supposed to contain the cannonical name for the domain name that it's associated with. There can be only one cannonical name. And it appears that in the latest BIND, they've seen the error of their ways: multiple-cnames If yes, then multiple CNAME resource records will be allowed for a do- main name. The default is no. Allowing multiple CNAME records is against standards and is not recommended. Multiple CNAME support is available because previous versions of BIND allowed multiple CNAME records, and these records have been used for load balancing by a num- ber of sites. In any case, this has turned into a debate on how to (ab)use BIND and the DNS, and is well off topic. Yea, then all swamp cvsup8.freebsd.org and John has to send another message that there are still cvsup[2-7].freebsd.org idling around. Just kidding... But you get the point? My only point is that the first response to a problem isn't to necessarily pull out emacs and start hacking away on code. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
[EMAIL PROTECTED] wrote: Second, a domain name can at most a single CNAME record associated with it, and other other record types. BIND will (should) barf on a zone file containing the example you listed. It does not. It will round-robin over the CNAME's. See the documentation for the multiple-cnames option in BIND 8.2.2: If yes, multiple CNAME resource records will be allowed for a domain name. The default is no. Allowing multiple CNAME records is against standards and is not recommended. Multiple CNAME support is available because previous versions of BIND allowed multiple CNAME records, and these records have been used for load balancing by a number of sites. So I'd say this is not a good idea. Ah, well, ok. I used it extensively with bind 8.1.2 in an internal application in a big bank to get approx. load distribution with Windumb clients (they always take the first record in the list returned). Anyway, if multi CNAME is no good then do: cvsup IN A198.104.92.71 ; cvsup1.freebsd.org cvsup IN A205.149.189.91 ; cvsup2.freebsd.org ... and so on This is legal, is it? -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Matthew Hunt wrote: On Fri, Jan 21, 2000 at 11:56:11PM +0100, Andre Oppermann wrote: OK, then you should hardwire your cvsup server to cvsup[1-8]. You can master cvs so you can master this. I do. Thanks for your vote of confidence in my abilities, though. If you meant "committers use cvs directly or hardwire their cvsup server", maybe you should have written that. Sorry, I didn't want to offend you. I apologise. -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On 21-Jan-00 Andre Oppermann wrote: Jesper Skriver wrote: On Fri, Jan 21, 2000 at 11:06:40PM +0100, Andre Oppermann wrote: I don't see any appearant reson (short of network connectivity) that one *needs* to get always the *same* server. This has been discussed regulary ... Must have been some time ago... Yes, every few months it seems. You will risk hitting 2 different server in 2 rapid cvsup run's, where the first may be more up to date than the next, as Jordan wrote earlier in this thread ... Does it matter? Who cvsup's regulary more than once or twice a day? Committers AFAIK do cvs directly. No, cvs is much slower than cvsup. I, for one, cvsup the repository itself and then do cvs operations locally against that. -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Louis A. Mamakos wrote: Second, a domain name can at most a single CNAME record associated with it, and other other record types. BIND will (should) barf on a zone file containing the example you listed. It does not. It will round-robin over the CNAME's. If it does, than this is a bug in BIND. The DNS is not defined to work this way. Semantically, it doesn't make sense to have more than one CNAME record. The CNAME resource record is supposed to contain the cannonical name for the domain name that it's associated with. There can be only one cannonical name. And it appears that in the latest BIND, they've seen the error of their ways: -snip- OK, I did it with bind 8.1.2, see my other response to Steinar. In any case, this has turned into a debate on how to (ab)use BIND and the DNS, and is well off topic. Back on topic. Do it instead with A records. Joe Random goes for cvsup.freebsd.org and highly likely wont be cvsupping more than once a day. Others who do can hardwire to one specific cvsup server. The best of both worlds with just a few key strokes and now complies with every imaginable RFC. Uh, I better don't pray for it. Yea, then all swamp cvsup8.freebsd.org and John has to send another message that there are still cvsup[2-7].freebsd.org idling around. Just kidding... But you get the point? My only point is that the first response to a problem isn't to necessarily pull out emacs and start hacking away on code. Yea, it is easier to do in a regular zone file then to implement the network measurement logic into cvsup. -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Sat, 22 Jan 2000, Andre Oppermann wrote: Ah, well, ok. I used it extensively with bind 8.1.2 in an internal application in a big bank to get approx. load distribution with Windumb clients (they always take the first record in the list returned). Anyway, if multi CNAME is no good then do: cvsup IN A198.104.92.71 ; cvsup1.freebsd.org cvsup IN A205.149.189.91 ; cvsup2.freebsd.org ... and so on This is legal, is it? Not only is it legal, but I believe BIND will return all the A records to any query, and will rotate them. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Steve Kargl wrote: Andre Oppermann wrote: Jesper Skriver wrote: You will risk hitting 2 different server in 2 rapid cvsup run's, where the first may be more up to date than the next, as Jordan wrote earlier in this thread ... Does it matter? Who cvsup's regulary more than once or twice a day? Committers AFAIK do cvs directly. %cvsup Damn! Forgot I don't want src-sys -- Hit ^C. %vi ~/supfileRemove src-sys %cvsup or %cvsup Damn! Forgot I want to remove sup/src-sys/refuse -- Hit ^C. %rm sup/src-sys/refuse %cvsup Yes, I've done both scenarios. Perhaps an option to CVSup to test a group of servers and render a "rating" for each, or to choose a "best" one. Then an intelligent human being could use this information to occasionally change which cvsup server they use. Such a tool wouldn't be specific to CVSup, of course, and probably already exists in benchmarks. Suggestions? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 11:11:17AM -0800, John Polstra wrote: I have been reminded that a few mirrors (cvsup8 in particular) filter pings. Don't take ping failures as a certain indication that the server is down. On Fri, Jan 21, 2000 at 11:22:33AM -0800, Amancio Hasty wrote: So have the cvsup client do the pinging to the server and extract its current work load or other vital statistic. I have to agree with Amancio. Otherwise how are we to determine if cvsup8 is worth our time? I personally will not be switching to it until I can determine it is a better path for me. Possibly, being ping'able should be be a requirement to being a CVSup mirror. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
: Does it matter? Who cvsup's regulary more than once or twice a day? : Committers AFAIK do cvs directly. : I "cvs co" from my local copy of the repository, which is kept : up-to-date using cvsup. When I'm making lots of commits, I'll do 10-20 cvsups in a day, but usually it is more like 3-5 depending on what I need to track. I cvsup the tree itself and co from there. That's why I wrote the script I did. I'll clean it up tonight and post it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
My only point is that the first response to a problem isn't to necessarily pull out emacs and start hacking away on code. Yea, it is easier to do in a regular zone file then to implement the network measurement logic into cvsup. Yes, it is a rather cool idea to rotate on the cvs servers without respect to latency, work load or rate of service response from the server. -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Hi David, John can implement a ping echo packet protocol for cvsup whose response can have "cool" information on the server. Steven's book on Networking already has the code for doing network latency calculations . It is more like if John has the time to implement such scheme -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 04:47:42PM -0700, Wes Peters wrote: Perhaps an option to CVSup to test a group of servers and render a "rating" for each, or to choose a "best" one. Then an intelligent human being could use this information to occasionally change which cvsup server they use. Such a tool wouldn't be specific to CVSup, of course, and probably already exists in benchmarks. Suggestions? For the actual testing, netperf would probalby be a good choice assuming the server admins will cooperate (or the server was integrated into cvsupd). The normal version is a standalone program, but there is a libritized version as part of the gloperf daemon which is part of the globus project (www.globus.org). As to storing the list of ratings, it would be really nice if such a tool cached them on a per-subnet bases so us telecommuters can move around and cvsup from random ethernet ports with dhcp support. In general, ratings based on network performance are likely to be good for quite some time. The things you probably wouldn't want to cache would be servers loads. Randomly wondering off on a tangent, if clients had nice caches of network information, it might be nice if servers would keep eachother informed of their loads so if they were unnecessicairly busy though could say "go away, here's a list of everyone else's loads so you can pick a good one next time." Of course this is all idle chit-chat until the decididly non-trivial problem of out of sync servers is solved. -- Brooks -- "They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, 21 Jan 2000, David O'Brien wrote: Possibly, being ping'able should be be a requirement to being a CVSup mirror. I don't think it makes sense to try to dictate network policy to people who are doing the FreeBSD Project a favor. Anyway, an application-level round-trip time measurement would probably be more accurate, because some routers treat ICMP and TCP packets differently. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Hi David, John can implement a ping echo packet protocol for cvsup whose response can have "cool" information on the server. Steven's book on Networking already has the code for doing network latency calculations . It is more like if John has the time to implement such scheme 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 :-) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 07:03:51PM -0500, Chuck Robey wrote: I don't know ... I think it might be a good idea for the cvsup client to make a connection to a cvsup master, get redirected from that master to the actual handler of the connection, and then work. That way, a config file on the master could be set up to know the capabilities of the other machines (network availability, machine speed, etc) and dole out connections weighted on that. How is a cvsup master to know anything about the path from me to any given cvsup mirror? Knowing something about the path from me to the master and the path from the master to the mirror tells zero about the path from me to the mirror. Being on an .EDU network, I have a *very* different path to other .EDU machine participating in Inetnet2. My path to cvsup3 is a prime example. This "cvsup master" will have no idea about this. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Hi David, John can implement a ping echo packet protocol for cvsup whose response can have "cool" information on the server. Steven's book on Networking already has the code for doing network latency calculations . It is more like if John has the time to implement such scheme 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 :-) Hi, Thats gross server load balancing . The network travel time does not tell you how how loaded the machine is or the server. It may be gross to the server but it is optimal to the networks :-) There are couple of RFCs on network load balancing with respect to servers or services and I am sure that there are also widely available research papers. Most of those concentrate on balancing the load on the server itself. How about balancing the load on the network paths, I doubt very much that we have a server load problem near as much as we have a network load problem due to people not having ready access to the data that says ``this server is closest network wise to me''. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 07:27:08PM -0500, Will Andrews wrote: Traceroute works fine. Traceroute can be annoying to use as it is much slower. And not all routers respond "properly" to it. If you knew the history of fadeto.blackened.com, you'd know why ICMPs are filtered out I really don't give a rats a** about fadeto.blackened.com. I am part of FreeBSD and that is what I care about. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, 21 Jan 2000, David O'Brien wrote: On Fri, Jan 21, 2000 at 07:03:51PM -0500, Chuck Robey wrote: I don't know ... I think it might be a good idea for the cvsup client to make a connection to a cvsup master, get redirected from that master to the actual handler of the connection, and then work. That way, a config file on the master could be set up to know the capabilities of the other machines (network availability, machine speed, etc) and dole out connections weighted on that. How is a cvsup master to know anything about the path from me to any given cvsup mirror? Knowing something about the path from me to the master and the path from the master to the mirror tells zero about the path from me to the mirror. Being on an .EDU network, I have a *very* different path to other .EDU machine participating in Inetnet2. My path to cvsup3 is a prime example. This "cvsup master" will have no idea about this. I guess it means, is the main component trying to be balanced the server resources or the network resources. I may be wrong, but I think that the server resources are more likely to be the most important bottleneck, and this method detects that, with minimal network effects. If you think that it's really the network that's going to be the bottleneck, then you wouldn't want to use this method. I don't think I'm wrong, but I'm willing to listen to arguments on it. Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, 21 Jan 2000, David O'Brien wrote: On Fri, Jan 21, 2000 at 07:03:51PM -0500, Chuck Robey wrote: I don't know ... I think it might be a good idea for the cvsup client to make a connection to a cvsup master, get redirected from that master to the actual handler of the connection, and then work. That way, a config file on the master could be set up to know the capabilities of the other machines (network availability, machine speed, etc) and dole out connections weighted on that. How is a cvsup master to know anything about the path from me to any given cvsup mirror? Knowing something about the path from me to the master and the path from the master to the mirror tells zero about the path from me to the mirror. Being on an .EDU network, I have a *very* different path to other .EDU machine participating in Inetnet2. My path to cvsup3 is a prime example. This "cvsup master" will have no idea about this. I guess it means, is the main component trying to be balanced the server resources or the network resources. I may be wrong, but I think that the server resources are more likely to be the most important bottleneck, and this method detects that, with minimal network effects. If you think that it's really the network that's going to be the bottleneck, then you wouldn't want to use this method. I don't think I'm wrong, but I'm willing to listen to arguments on it. I think, and am pretty sure as hostmaster for cvsup4, that the bottleneck is a combination of both. We use the max connection limit to control the load on the server, and simply refuse connections beyond the acceptable load limit. As far as I know none of the servers run unlimited connection counts so we already have a load controlling mechanism. I know from a network bandwidth point of view I can tell when someone with T-1 or better comes on and pulls a full copy from us, it shows up quite nicely in the load graphs. I also know from looking at our logs that some people would get faster cvsup's if they changed which mirror they are pulling from. (Anyone directly attached to Verio should no longer be using us, but the new Verio provided server instead.) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
Amancio Hasty wrote: My only point is that the first response to a problem isn't to necessarily pull out emacs and start hacking away on code. Yea, it is easier to do in a regular zone file then to implement the network measurement logic into cvsup. Yes, it is a rather cool idea to rotate on the cvs servers without respect to latency, work load or rate of service response from the server. Thank you. I was beginning to wonder if I am the only one here who thinks blind round-robin DNS is a bad hack. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 08:56:29PM -0500, Chuck Robey wrote: I guess it means, is the main component trying to be balanced the server resources or the network resources. I may be wrong, but I think that the server resources are more likely to be the most important bottleneck, and Not really. If I have a poor network connection to the CVSup mirror used, then I'll spend much long connected to it. Thus causing a higher "load" on the mirror. Where "load" is either one of the connection slots, or actual kernel resource load if I have 20% packet loss and thus cause a lot of retransmissions to occur. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
In message [EMAIL PROTECTED] "David O'Brien" writes: : "load" on the mirror. Where "load" is either one of the connection : slots, or actual kernel resource load if I have 20% packet loss and thus : cause a lot of retransmissions to occur. Hmmm. A thought just occurred to me. There's no need to measure these things. Lookup all the IP addresses. Do a non blocking connection to each of these machines. First one to come back with the REL16_1 response wins, and all the others get closed and you use that one. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
