Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <436E7DCC.6E27EA9@dessent.net>
Date: Sun, 06 Nov 2005 14:03:56 -0800
From: Brian Dessent <brian AT dessent DOT net>
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: where is setup.exe source?
References: <dklo7u$naf$1 AT sea DOT gmane DOT org> <436E6A0C DOT 5E565962 AT dessent DOT net> <Pine DOT GSO DOT 4 DOT 63 DOT 0511061603100 DOT 847 AT slinky DOT cs DOT nyu DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com

Igor Pechtchanski wrote:

> I disagree.  FWIW, keeping the local ping response time information for
> mirrors and re-pinging on demand has been on my TODO list for a while.
> The only thing I would strenuously object to is re-pinging the mirrors
> automatically on every setup -- it's much better to let the user update
> the mirror information (by adding a "Ping" button).  I don't recall if the
> mirror list is sortable, actually -- if it isn't, it ought to be.  BTW,
> now that setup is resizable, it would make sense to at least add the
> location information from mirrors.lst to the mirror list dialog.

Well there's fundamentally two different concepts going on here.

A) Is the mirror online and fresh?  This is taken care of by the
infrastructure at cygwin.com.

B) Based on *my* connection, is the mirror fast?  This obviously is
something that can only be measured by the end user.  However, ping is a
really poor way to judge bandwidth.  One of the main reasons is that
carrier grade routers do standard IP packet forwarding in hardware line
cards (at full line rate) but they often punt things like ICMP and SNMP
to be handled by the CPU which is much slower.  More at
<http://www.iwl.com/Resources/Papers/icmp-echo_print.html>.  So a low
ping doesn't correlate to high bandwidth, and vice versa.

Another issue is ping doesn't measure anything about the kinds of
bandwidth caps that might be in place on the mirror.  You might be right
across the street from a mirror but if it has a 50kb/s per connection
throttle it's going to be a lot slower than one in, say, Sweden with
three times the ping but no caps.

I would argue the only way to measure this is by manually experimenting
with various mirrors and finding one from which you can download fast. 
This too could be automated by setup, but it is a lot harder than just
measuring pings.  And you would want to do it in a way that doesn't
cause abuse, i.e. you wouldn't want to always download a 1MB file from
every mirror just to see which one is the fastest.

Also, personally, I tend to find one mirror that I like and stick with
it.  All the mirrors on the official list have the same set of packages
so once you find a suitable mirror it makes no sense to then try others,
unless you experience connection problems.  So I don't really see a need
for adding a lot of automation to measuring bandwidth.

> Yuk.  Then you'd need to pass this information to setup (not easy, as
> setup actually grabs one from cygwin.com).  It's better to do this in
> setup proper.

Well again, I see it defined more as "I want to measure this once and
find a suitable mirror, which I then select in setup" as opposed to "I
will need ongoing measurements and rankings because I will be constantly
selecting the best mirror."  From that perspective, you can write a
simple perl script that downloads a package from each mirror in the list
and tells you which one is the fastest - there's no need to communicate
this back to setup.exe since you can just pick that mirror and be done
with it.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/