Date: Fri, 21 Jan 2000 17:07:34 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Wes Peters <wes@softweyr.com> Cc: John Polstra <jdp@polstra.com>, joe@pavilion.net, current@FreeBSD.ORG Subject: Re: Please help spread the CVSup mirror load more evenly Message-ID: <200001212207.RAA02163@whizzo.transsys.com> In-Reply-To: Your message of "Fri, 21 Jan 2000 14:29:40 MST." <3888CFC4.E130D88D@softweyr.com> References: <XFMail.000121104339.jdp@polstra.com> <20000121190729.C58872@florence.pavilion.net> <200001211911.LAA11701@vashon.polstra.com> <3888CFC4.E130D88D@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001212207.RAA02163>