From owner-freebsd-ports@FreeBSD.ORG Wed Sep 2 16:52:29 2009 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6872F106566B for ; Wed, 2 Sep 2009 16:52:29 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 09E8D8FC13 for ; Wed, 2 Sep 2009 16:52:28 +0000 (UTC) Received: by syn.atarininja.org (Postfix, from userid 1001) id 39AD55C3B; Wed, 2 Sep 2009 12:52:28 -0400 (EDT) Date: Wed, 2 Sep 2009 12:52:28 -0400 From: Wesley Shields To: Dmitry Marakasov Message-ID: <20090902165228.GB20719@atarininja.org> References: <6B974976DD234EF08949F6A8@utd65257.utdallas.edu> <20090820164036.GA12998@hades.panopticon> <1250790054.45433.0.camel@hood.oook.cz> <20090821181232.GB59823@hades.panopticon> <1250882387.50625.0.camel@hood.oook.cz> <20090902031433.GA1304@hades.panopticon> <4A9E2505.1070306@FreeBSD.org> <20090902120508.2558236d@it.buh.tecnik93.com> <0B6596C6C29340D738A8A729@utd65257.utdallas.edu> <20090902162633.GB94573@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090902162633.GB94573@hades.panopticon> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Paul Schmehl , freebsd-ports@FreeBSD.org Subject: Re: Migration to new SourceForge URL scheme part 2, SFE and some statistics X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 16:52:29 -0000 (Trimming CC line...) On Wed, Sep 02, 2009 at 08:26:33PM +0400, Dmitry Marakasov wrote: > * Paul Schmehl (pschmehl_lists@tx.rr.com) wrote: > > > > In my case, over a few retries, switch is the fastest, followed by > > > surfnet. heatnet is only somewhere between 500-700K. > > > dfn, garr: and ovh fail. > > > > It might be way too much work for very little benefit, but network latencies > > being what they are, perhaps there should be a routine that runs periodically > > and adjusts the list according to some connectivity parameters? (Yeah, I know, > > easy for me to say. I don't have to write the code.) > > That's really too much work for a little benefit. The only thing > we really want from mirrors is fetchability, and as soon as we have > multiple mirrors that's achieved. Speed is a different issue and, > as my survey shows, mirrors can't be sorted once and forever to > satisfy the whole world, so if you feel like downloads are slow, > just add your favorte mirror into make.conf, like I did a long time > ago. The utility to do it automatically would be useful though, and > actually you can write one. Actually, something even more clever > could be written, similar to RANDOMIZE_MASTER_SITES, but based on > fetch speed feedback, but that'd be an overcomplication if you ask me. There is ports-mgmt/fastest_sites which sorts based upon round-trip time for the TCP handshake to complete. It's not accurate for download speeds but it provides a rough approximation for minimal effort. -- WXS