RE: "Mirrors list order is snafued" - What is the order supposedto be?

[Robert Collins]

On Thu, 2003-01-23 at 16:00, Gary R. Van Sickle wrote:
 I think we should in any case be moving
> towards "hiding" from the average and uninterested user behind an "advanced"
> button or something, and doing an automated server-picking based on ping and
> even-server-load-distribution considerations.

Ok, I'm happy for someone to put up proof of concept code to do this.
Lets not beat our breast about the design implications until there is
something to discuss: whoever writes the code has the primary say.

In terms of UI, I *suggest* the following:
* Make the current list box two column and sortable (there is a MS
control that can do this.)
* In the second column, display N/A and a title of response time by
default.
* Provide a "Test mirror speed" button.

In terms of testing, ICMP ping is a less than useful test for setup.exe.
I suggest that it not be used. This is because 
a) Nearly all corporate based users, and many ISP based users will have
at least one proxy server between them and http mirrors. Proxies will
dramatically alter (both up and down) the response time of an HTTP or
FTP request, vs a ping response. HTTP Provides a TRACE command to
perform HTTP based pings, which is a feasible metric, but not as good as
what I'll describe below.
b) FTP Servers that are very busy (in terms of anonymous user
percentage) may still have a low ping, but deny actual FTP access,
leading to poor performance.
c) ICMP ping does not actually test the application layer you are
working with.

I suggest the following approach, which will test the actual
effectiveness of the given mirror:
* grab a small known file (say .../md5.sum) from the mirror with the
users chosen net access type.

This will be cached when several users are using the same cache, and
could lead to false positives, but no less (IMO) that the false
negatives we will see using ICMP pings. To ameliorate the presence of
false positives, we can put a maximum cache age only on the test file
(in the setup.exe code, not the server). This will allow the other setup
tarballs to be cached, but the benchmark to still be accurate -
regardless of the users network topology. It also has the benefit of
testing the application layer accessability.

Rob
-- 
GPG key available at: .



signature.asc
Description: This is a digitally signed message part

Re: "Mirrors list order is snafued" - What is the order supposedto be?

[Lapo Luchini]

David Starks-Browning wrote:


OK, good point.  As long as nothing *blocks* waiting for pings to
finish, I guess I don't care if setup pings.


That is indeed a *must*, as many router filter echo reply packets, so at 
least some server's reply would never be received, and moreover UDP 
packets may be lost with no problem (no automatic re-transmission at all).

Different problem: we need either raw sockets (bad, bad, bad) or the 
ICMP.dll, which is available also on Win9x if some releaseof IE is 
installed, AFAIR.

--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)

Re: "Mirrors list order is snafued" - What is the order supposedto be?

[David Starks-Browning]

On Wednesday 22 Jan 03, Lapo Luchini writes:
> David Starks-Browning wrote:
> 
> >If I may interject, I hope setup never does this automatically, not
> >even the first time it runs.  Can an arbitrary sort order be
> >acceptable by default, unless the user wants to sort by ping
> >performance?
> >
> What harm can do a single 50-byte UDP packet when there is high 
> probabiilty that a real "connection" needshundreds of big TCP packets 
> just to download setup.bz2?
> Less harm than "people" using always the first mirror as they never 
> re-order it, imho.

OK, good point.  As long as nothing *blocks* waiting for pings to
finish, I guess I don't care if setup pings.

Thanks,
David

Re: "Mirrors list order is snafued" - What is the order supposedto be?

[Lapo Luchini]

David Starks-Browning wrote:


If I may interject, I hope setup never does this automatically, not
even the first time it runs.  Can an arbitrary sort order be
acceptable by default, unless the user wants to sort by ping
performance?


What harm can do a single 50-byte UDP packet when there is high 
probabiilty that a real "connection" needshundreds of big TCP packets 
just to download setup.bz2?
Less harm than "people" using always the first mirror as they never 
re-order it, imho.

--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)

Re: "Mirrors list order is snafued" - What is the order supposedto be?

[Robert Collins]

On Wed, 2003-01-22 at 05:55, Max Bowsher wrote:


> Nevertheless, wouldn't you agree that the treeview I proposed above would be
> an improvement over the current listview?

No. There are several facets to resolve in the design...

1) Where do custom mirrors go?
2) What if all the mirrors in region X are slow, or update slowly?
3) What improvements does it give to the process of choosing a mirror?

Or to put it another way: what use case is best served by the proposed
tree view over a (say) reliability sorted plain old' list.

Rob
-- 
GPG key available at: .



signature.asc
Description: This is a digitally signed message part

Re: "Mirrors list order is snafued" - What is the order supposedto be?

[Robert Collins]

On Mon, 2003-01-20 at 19:59, Lapo Luchini wrote:
> Robert Collins wrote:
> 
> >But: even after that is done, I think we should reexamine the sorting
> >concept, and perhaps sort by the sources.redhat.com order (for us->site
> >speed), or perhaps user mirrors then official, etc.
> >  
> >
> I guess the best would be to sort by "ping time" (smalest to bigger) to 
> help reduce unnecessary trans-oceanic downloads.

Which means pinging all the sites, and storing the results. We use the
official mirror list today, so we can't do this *today*. Also there are
other, more policy issues - time to ping all the sites, policy of the
sites (do they allow ping?).

> But of course it would need to check them each time... or may it be 
> cached in the local setup.ini?

Not setup.ini. mirror.lst / last-mirror

> Also: setup.bz2 couln't be checked for size/date and not be downloaded 
> again each time? Just a MINOR issue of course.

We do this already via the networking logic when using the MSIE network
connection type, or manual HTTP with a proxy server... (use HEAD to get
this).

Rob
-- 
GPG key available at: .



signature.asc
Description: This is a digitally signed message part

Re: "Mirrors list order is snafued" - What is the order supposedto be?

[Lapo Luchini]

Robert Collins wrote:


But: even after that is done, I think we should reexamine the sorting
concept, and perhaps sort by the sources.redhat.com order (for us->site
speed), or perhaps user mirrors then official, etc.
 

I guess the best would be to sort by "ping time" (smalest to bigger) to 
help reduce unnecessary trans-oceanic downloads.
But of course it would need to check them each time... or may it be 
cached in the local setup.ini?

Also: setup.bz2 couln't be checked for size/date and not be downloaded 
again each time? Just a MINOR issue of course.

--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)

Re: "Mirrors list order is snafued" - What is the order supposedto be?

[Max Bowsher]

Robert Collins wrote:
>On Thu, 2003-01-16 at 04:22, Max Bowsher wrote:
>> setup/README asserts that "Mirrors list orer is snafued".
>> 
>> What particular order is it supposed to have?
>
> Well, thats whats broken. It's not sorting the way the current released
> setup does.

Yes, it is. (Tested; 2.249.2.5(release), 2.306(HEAD))

Does this mean that TODO is complete?

Max.

Re: "Mirrors list order is snafued" - What is the order supposedto be?

[Robert Collins]

On Thu, 2003-01-16 at 04:22, Max Bowsher wrote:
> setup/README asserts that "Mirrors list orer is snafued".
> 
> What particular order is it supposed to have?

Well, thats whats broken. It's not sorting the way the current released
setup does.

It simply needs the < operator to do the same thing as the previous
generated-string-for-comparison.

But: even after that is done, I think we should reexamine the sorting
concept, and perhaps sort by the sources.redhat.com order (for us->site
speed), or perhaps user mirrors then official, etc.

Rob
-- 
GPG key available at: .



signature.asc
Description: This is a digitally signed message part