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
Date: Sun, 6 Nov 2005 17:34:34 -0500 (EST)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Subject: Re: where is setup.exe source?
In-Reply-To: <436E7DCC.6E27EA9@dessent.net>
Message-ID: <Pine.GSO.4.63.0511061717010.847@slinky.cs.nyu.edu>
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> <436E7DCC DOT 6E27EA9 AT dessent DOT net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 6 Nov 2005, Brian Dessent wrote:

> 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.

Heh.  I should've quoted the "ping"...  What I meant by "ping" above is
some measure of the connection speed, not the actual ICMP packets.
Besides, doing ping in software requires an ICMP-compliant library.

> [snip more "ping" vs "connection speed" discussion]
>
> 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.

Yes, fully agreed.  That's why I'm waiting for a really large round tuit,
rather than doing something quick and dirty, but braindead.  However, the
"always" in your statement above isn't that bad, since it won't happen
unless a user chooses to perform that action.  I also vaguely recall
reading something about a standard bandwidth-test download that won't be
considered "abuse" (it probably would be much smaller than 1MB).  If
anyone recognizes what I'm talking about, I would appreciate a pointer in
private mail.

> 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.

Picking that first mirror can be a hassle, too.  But even if you have a
mirror, it's nice to know what other options are available.  There is also
a question of server load...  Not everyone uses setup in the same way.

> > 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.

Well, yes, if you put it that way.  However, there's a chicken-and-egg
problem here, right?  As in "I want to download Cygwin fast" needs Cygwin
to figure it out[*]?
	Igor
[*] And I'm not even going to suggest using a non-Cygwin set of tools to
write that script...
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--
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/