This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: where is setup.exe source?

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

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


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]