Re: slow distfiles mirror

[Daniel J. Luke]

On Aug 8, 2016, at 2:30 PM, Ryan Schmidt  wrote:
> If you have suggestions for improving the mirror selection mechanism we can 
> certainly discuss it.

If there is brokenness that we can define, I'm happy to try to come up with 
solutions.

> Using ping time has always seemed indirect and possibly inaccurate to me,

Yes, but I'm not aware of any reason for that (you haven't been able to 
articulate an actual problem that I've seen, but still imply that there is one 
there).

> Years ago I brought up possibly using geolocation,

IP geolocation isn't very reliable (even if you pay for the 'good' data).

> but even if we had the servers' locations and the user's location, there's no 
> guarantee that geographic proximity equals faster network speed.

yes, so even if you have good geolocation data, it's not as helpful as it seems 
(you really want network latency data to optimize for larger tcp flows).

-- 
Daniel J. Luke



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: slow distfiles mirror

[Daniel J. Luke]

On Aug 8, 2016, at 1:58 PM, Ryan Schmidt  wrote:
> On Aug 8, 2016, at 12:49 PM, Daniel J. Luke wrote:
>> Ryan said: "it's possible for a server to respond quickly to pings but 
>> slowly to actual file transfers"
>> 
>> I'm interested in what prompted that.
> 
> I just imagine that on some networks, it might be possible that the small 
> amount of data used for pings could transfer quickly, while nevertheless that 
> the larger amount of data used to actually transfer files might be slower.

I'm not sure how that would work (or, in fact, what 'faster' and 'slower' means 
in this case).

In the specific case of our mirrors, they all should have adequate bandwidth 
that the 'best' server for any individual is going to be the one that is 
closest (in network latency) to the end user.

The 'ping test' is an attempt to figure out which host is closest.

> I thought this was something that had happened to me on some network at some 
> point in the past.

actual details of any failures of MacPorts mirror selection would be useful so 
the system could be improved.

> It's also possible that all pings failed, in which case MacPorts does not 
> know which server is best. In that case, I'm not sure whether MacPorts tries 
> servers in the order listed in the tcl file or alphabetical order or what.

fetch_common.tcl sets a pingtime of 1 for hosts that fail [comment says 
"ping failed, so put it last in the list (but before the fallback mirrors)"]

> In any case I'm not an expert on network infrastructure. I just know that our 
> mirrors usually work fine, so when a user reports a problem with one of them, 
> it's usually because of something on the user's system like a virus scanner 
> or firewall, or something on the user's network, or some problem with the 
> user's ISP, or a problem somewhere between the user's ISP and the network the 
> mirror is on.

If there are cases where MacPorts mirror selection isn't working properly, we 
should try to address them. If it is working fine, we should avoid 
unnecessarily telling people that it might be broken.

-- 
Daniel J. Luke



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: slow distfiles mirror

[Brandon Allbery]

On Mon, Aug 8, 2016 at 1:49 PM, Daniel J. Luke  wrote:

> Ryan said: "it's possible for a server to respond quickly to pings but
> slowly to actual file transfers"
>
> I'm interested in what prompted that.
>

Routers may be (sometimes configurable, sometimes not) configured to
fast-path (or, alternately, slow-path) ICMP. Some OSes also do this (it's
disconcerting to watch a Solaris box stopped with a kernel panic still
respond to ping...).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: slow distfiles mirror

[Ryan Schmidt]

On Aug 8, 2016, at 12:49 PM, Daniel J. Luke wrote:

> Ryan said: "it's possible for a server to respond quickly to pings but slowly 
> to actual file transfers"
> 
> I'm interested in what prompted that.

I just imagine that on some networks, it might be possible that the small 
amount of data used for pings could transfer quickly, while nevertheless that 
the larger amount of data used to actually transfer files might be slower. I 
thought this was something that had happened to me on some network at some 
point in the past.

It's also possible that all pings failed, in which case MacPorts does not know 
which server is best. In that case, I'm not sure whether MacPorts tries servers 
in the order listed in the tcl file or alphabetical order or what.

In any case I'm not an expert on network infrastructure. I just know that our 
mirrors usually work fine, so when a user reports a problem with one of them, 
it's usually because of something on the user's system like a virus scanner or 
firewall, or something on the user's network, or some problem with the user's 
ISP, or a problem somewhere between the user's ISP and the network the mirror 
is on.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: slow distfiles mirror

[Daniel J. Luke]

On Aug 8, 2016, at 1:20 PM, Ryan Schmidt  wrote:
> On Aug 8, 2016, at 10:25 AM, Daniel J. Luke wrote:
>> On Aug 7, 2016, at 5:22 PM, Ryan Schmidt wrote:
>>> It decides this based on lowest ping time. This is not necessarily 100% 
>>> reliable: it's possible for a server to respond quickly to pings but slowly 
>>> to actual file transfers.
>> 
>> If this is true for any of our mirror sites, they shouldn't be mirror sites.
>> 
>> Mirrors should have adequate bandwith to push data, so the determining 
>> factor in transfer speed is going to be the rtt (see also tcp bandwith-delay 
>> product).
> 
> As I said in my next sentence:
> 
>>> The UWaterloo server is often the one chosen for me, and it's been fast for 
>>> me, but it depends on your unique network situation.

I'm interested in what unique network situation causes the rtt test to be an 
unreliable indicator of which mirror to choose.

-- 
Daniel J. Luke



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: slow distfiles mirror

[Ryan Schmidt]

On Aug 8, 2016, at 10:25 AM, Daniel J. Luke wrote:

> On Aug 7, 2016, at 5:22 PM, Ryan Schmidt wrote:
>> It decides this based on lowest ping time. This is not necessarily 100% 
>> reliable: it's possible for a server to respond quickly to pings but slowly 
>> to actual file transfers.
> 
> If this is true for any of our mirror sites, they shouldn't be mirror sites.
> 
> Mirrors should have adequate bandwith to push data, so the determining factor 
> in transfer speed is going to be the rtt (see also tcp bandwith-delay 
> product).

As I said in my next sentence:

>> The UWaterloo server is often the one chosen for me, and it's been fast for 
>> me, but it depends on your unique network situation.


The xorg-randrproto distfile that was mentioned earlier is 139K which is 
smaller than most web sites and should transfer instantaneously on most any 
connection.

I tested downloading a somewhat larger file using my current Internet 
connection (100mbps Time Warner Cable in San Antonio, TX), which transferred at 
521kbps. For comparison, I tried our CDN, which in my case was reaching the 
Dallas CDN datacenter, and that was faster at 951kbps. I also checked pings, 
and the CDN had lower ping times, so in my case, of those two server, MacPorts 
would have tried to use the CDN first. But these results are specific to my 
Internet connection and the results would be different for other users.


$ curl -O 
http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/mongodb/mongodb-src-r3.2.8.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 27.1M  100 27.1M0 0   521k  0  0:00:53  0:00:53 --:--:--  537k


$ curl -O https://distfiles.macports.org/mongodb/mongodb-src-r3.2.8.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 27.1M  100 27.1M0 0   951k  0  0:00:29  0:00:29 --:--:-- 1010k


$ ping -c 4 ykf.ca.distfiles.macports.org
PING mirror.csclub.uwaterloo.ca (129.97.134.71): 56 data bytes
64 bytes from 129.97.134.71: icmp_seq=0 ttl=44 time=64.722 ms
64 bytes from 129.97.134.71: icmp_seq=1 ttl=44 time=69.800 ms
64 bytes from 129.97.134.71: icmp_seq=2 ttl=44 time=65.103 ms
64 bytes from 129.97.134.71: icmp_seq=3 ttl=44 time=64.210 ms

--- mirror.csclub.uwaterloo.ca ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 64.210/65.959/69.800/2.240 ms


$ ping -c 4 distfiles.macports.org
PING distfiles.macports.netdna-cdn.com (198.232.124.36): 56 data bytes
64 bytes from 198.232.124.36: icmp_seq=0 ttl=114 time=17.169 ms
64 bytes from 198.232.124.36: icmp_seq=1 ttl=114 time=20.108 ms
64 bytes from 198.232.124.36: icmp_seq=2 ttl=114 time=29.649 ms
64 bytes from 198.232.124.36: icmp_seq=3 ttl=114 time=23.775 ms

--- distfiles.macports.netdna-cdn.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.169/22.675/29.649/4.657 ms


$ curl http://198.232.124.36
You are hitting the MaxCDN Dallas Datacenter




___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users