Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 28, 2009, at 1:46 PM, Ryan Schmidt wrote: On Jun 28, 2009, at 13:11, David Bannister wrote: So yes, there is no connectivity to Telia, Comcast and a handful of German ISPs. This is due to some disagreements with AS1880 and those ISPs. AS1880, the transit provider for this node does not run a public network. It is a private network for personal use with over 100Gbps of transit connectivity. Why are you trying to get ports from a Swedish mirror if you are on Comcast (Norcal)? If you are looking to avoid global connectivity issues may I suggest you include GeoIP and BGP information during the selection of server to make sure things 'work.' Other people do this have have no issue. The technology exists and I will be more than happy to tell you how this stuff works. MacPorts used to not have any central mirrors, and would select a download location based on the order listed in the Portfile. Then we added the mirror at Apple, and changed MacPorts to ping each mirror and select mirrors in order of lowest to highest ping time. This has seemed to work well so far. Then the trd.no and arn.se mirrors were added, which should just serve to sweeten the deal. If arn.se happens to be the lowest ping, it will be used first. If, as Toby states, the server does not respond to ping from his network, then it should not impact the download mechanism whatsoever. If it does, then that is a bug in MacPorts base that we would want to address. I believe the problem is MacPorts will wait for a while (10 seconds?) before giving up on a mirror which just drops packets instead of refusing the connection outright. It does not break MP, but it is pretty annoying. David should have explained the limitations on the mirror at the beginning, but at least we know now so a workaround can be put into the mirror selection. -Bill smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 29, 2009, at 10:31, William Siegrist wrote: I believe the problem is MacPorts will wait for a while (10 seconds?) before giving up on a mirror which just drops packets instead of refusing the connection outright. It does not break MP, but it is pretty annoying. David should have explained the limitations on the mirror at the beginning, but at least we know now so a workaround can be put into the mirror selection. For me it takes about 5 seconds to fetch zlib, of which about 1 second is actually downloading the file. For glib2, which is larger and has more mirrors, it takes 11 seconds, of which about 7 seconds are downloading the file. So either way, about 4 seconds for MacPorts to set up and ping all the servers (including my local mirrors which are offline and not responding to pings for this test). If we can make MacPorts quicker at setting up and pinging the servers that would of course be great, but 4 seconds doesn't seem all that bad. Is this also what you're seeing, or is it taking much longer for you? What workaround are you thinking of for the mirror selection? $ time port -d fetch zlib DEBUG: Found port in file:///Users/rschmidt/macports/dports/archivers/ zlib DEBUG: Changing to port directory: /Users/rschmidt/macports/dports/ archivers/zlib DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: adding the default universal variant DEBUG: Requested variant darwin is not provided by port zlib. DEBUG: Requested variant i386 is not provided by port zlib. DEBUG: Requested variant macosx is not provided by port zlib. DEBUG: Executing org.macports.main (zlib) --- Fetching zlib DEBUG: Executing org.macports.fetch (zlib) --- zlib-1.2.3.tar.bz2 doesn't seem to exist in /mp/var/macports/ distfiles/zlib DEBUG: Pinging www.zlib.net... DEBUG: Pinging www.gzip.org... DEBUG: Pinging host1.local... DEBUG: Pinging host2.local... DEBUG: Pinging host3.local... DEBUG: Pinging distfiles.macports.org... DEBUG: Pinging arn.se.distfiles.macports.org... DEBUG: www.zlib.net ping time is 36.238 DEBUG: www.gzip.org ping time is 150.544 DEBUG: host1.local ping time is 1 DEBUG: host2.local ping time is 1 DEBUG: host3.local ping time is 1 DEBUG: distfiles.macports.org ping time is 64.301 DEBUG: arn.se.distfiles.macports.org ping time is 167.334 --- Attempting to fetch zlib-1.2.3.tar.bz2 from http://www.zlib.net/ % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 100 415k 100 415k0 0 284k 0 0:00:01 0:00:01 --:--:-- 438k real0m4.855s user0m0.271s sys 0m0.174s $ time port -d fetch glib2 DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/glib2 DEBUG: Changing to port directory: /Users/rschmidt/macports/dports/ devel/glib2 DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: Using group file /Users/rschmidt/macports/dports/_resources/ port1.0/group/muniversal-1.0.tcl DEBUG: universal variant already exists, so not adding the default one DEBUG: Requested variant i386 is not provided by port glib2. DEBUG: Requested variant macosx is not provided by port glib2. DEBUG: Executing variant darwin provides darwin DEBUG: Executing org.macports.main (glib2) --- Fetching glib2 DEBUG: Executing org.macports.fetch (glib2) --- glib-2.20.4.tar.bz2 doesn't seem to exist in /mp/var/macports/ distfiles/glib2 DEBUG: Pinging ftp.cse.buffalo.edu... DEBUG: Pinging www.gtlib.cc.gatech.edu... DEBUG: Pinging www.mirrorservice.org... DEBUG: Pinging fr2.rpmfind.net... DEBUG: Pinging mirror.aarnet.edu.au... DEBUG: Pinging ftp.unina.it... DEBUG: Pinging ftp.acc.umu.se... DEBUG: Pinging ftp.belnet.be... DEBUG: Pinging ftp.nara.wide.ad.jp... DEBUG: Pinging ftp.dit.upm.es... DEBUG: Pinging ftp.no.gnome.org... DEBUG: Pinging ftp.chg.ru... DEBUG: Pinging ftp.kddlabs.co.jp... DEBUG: Pinging mirror.internode.on.net... DEBUG: Pinging ftp.gnome.org... DEBUG: Pinging ftp.gtk.org... DEBUG: Pinging host1.local... DEBUG: Pinging host2.local... DEBUG: Pinging host3.local... DEBUG: Pinging distfiles.macports.org... DEBUG: Pinging arn.se.distfiles.macports.org... DEBUG: ftp.cse.buffalo.edu ping time is 67.610 DEBUG: www.gtlib.cc.gatech.edu ping time is 1 DEBUG: www.mirrorservice.org ping time is 139.922 DEBUG: fr2.rpmfind.net ping time is 1 DEBUG: mirror.aarnet.edu.au ping time is 226.017 DEBUG: ftp.unina.it ping time is 170.698 DEBUG:
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On 2009-06-30 01:46, Ryan Schmidt wrote: On Jun 29, 2009, at 10:31, William Siegrist wrote: I believe the problem is MacPorts will wait for a while (10 seconds?) before giving up on a mirror which just drops packets instead of refusing the connection outright. It does not break MP, but it is pretty annoying. David should have explained the limitations on the mirror at the beginning, but at least we know now so a workaround can be put into the mirror selection. For me it takes about 5 seconds to fetch zlib, of which about 1 second is actually downloading the file. For glib2, which is larger and has more mirrors, it takes 11 seconds, of which about 7 seconds are downloading the file. So either way, about 4 seconds for MacPorts to set up and ping all the servers (including my local mirrors which are offline and not responding to pings for this test). If we can make MacPorts quicker at setting up and pinging the servers that would of course be great, but 4 seconds doesn't seem all that bad. Is this also what you're seeing, or is it taking much longer for you? The problem is not the ping-based selection of servers. A server can sucessfully respond to ICMP echo requests, but may drop any packets sent over TCP to port 80/21 - by firewall rules on the host itself or on the route. This means it will not even respond with Connection refused and thus leaves the connection in a half-established state which will only be resolved by a timeout. In MacPorts 1.7 curl will use a timeout which is about 5 minutes for this purpose. This has been changed to shorter timeouts on trunk recently [1] by Joshua. Of course it is still just a good guess as you cannot tell how long a server will really need to respond. The new timeout of 30s should be less annoying than the old 5 minutes, while it should be enough time for most servers. I don't think anyone wants to fetch from a server which needs longer than 30s to deliver a single TCP packet :-) Rainer [1] http://trac.macports.org/changeset/52758 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 29, 2009, at 19:14, Rainer Müller wrote: The problem is not the ping-based selection of servers. A server can sucessfully respond to ICMP echo requests, but may drop any packets sent over TCP to port 80/21 - by firewall rules on the host itself or on the route. This means it will not even respond with Connection refused and thus leaves the connection in a half-established state which will only be resolved by a timeout. In MacPorts 1.7 curl will use a timeout which is about 5 minutes for this purpose. This has been changed to shorter timeouts on trunk recently [1] by Joshua. Of course it is still just a good guess as you cannot tell how long a server will really need to respond. The new timeout of 30s should be less annoying than the old 5 minutes, while it should be enough time for most servers. I don't think anyone wants to fetch from a server which needs longer than 30s to deliver a single TCP packet :-) True. But what started me on this line of questioning was Toby's statement that the server does not respond to pings. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On 2009-6-30 11:10, Ryan Schmidt wrote: On Jun 29, 2009, at 19:14, Rainer Müller wrote: The problem is not the ping-based selection of servers. A server can sucessfully respond to ICMP echo requests, but may drop any packets sent over TCP to port 80/21 - by firewall rules on the host itself or on the route. This means it will not even respond with Connection refused and thus leaves the connection in a half-established state which will only be resolved by a timeout. True. But what started me on this line of questioning was Toby's statement that the server does not respond to pings. Toby said it's only an issue when no servers have the file, i.e. MP has gone through every server in the list until it reaches arn.se (which is last apart from macports svn). Then it has to wait for the timeout. This is why he said it's really not that big a deal. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 28, 2009, at 13:11, David Bannister wrote: So yes, there is no connectivity to Telia, Comcast and a handful of German ISPs. This is due to some disagreements with AS1880 and those ISPs. AS1880, the transit provider for this node does not run a public network. It is a private network for personal use with over 100Gbps of transit connectivity. Why are you trying to get ports from a Swedish mirror if you are on Comcast (Norcal)? If you are looking to avoid global connectivity issues may I suggest you include GeoIP and BGP information during the selection of server to make sure things 'work.' Other people do this have have no issue. The technology exists and I will be more than happy to tell you how this stuff works. MacPorts used to not have any central mirrors, and would select a download location based on the order listed in the Portfile. Then we added the mirror at Apple, and changed MacPorts to ping each mirror and select mirrors in order of lowest to highest ping time. This has seemed to work well so far. Then the trd.no and arn.se mirrors were added, which should just serve to sweeten the deal. If arn.se happens to be the lowest ping, it will be used first. If, as Toby states, the server does not respond to ping from his network, then it should not impact the download mechanism whatsoever. If it does, then that is a bug in MacPorts base that we would want to address. Using GeoIP information would be another method by which we could select a nearby server, but we have not written code for that. Would it be better than choosing lowest ping time? I personally value the lowest ping time mechanism, because I have several machines at home, each of which is running a web server and serving its distfiles, and each machine is configured to use the others as mirrors. This helps me only download a distfile from the Internet once. I'm not familiar with how to use BGP information to select a server. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 27, 2009, at 11:21 AM, David Bannister wrote: On Jun 26, 2009, at 3:37 PM, William Siegrist wrote: (redirecting to mirror admin) On Jun 25, 2009, at 10:19 PM, Toby Peterson wrote: On Jun 25, 2009, at 10:13 PM, Ryan Schmidt wrote: On Jun 26, 2009, at 00:04, Toby Peterson wrote: On Jun 25, 2009, at 9:36 PM, Ryan Schmidt wrote: On Jun 25, 2009, at 21:48, t...@macports.org wrote: Revision: 52946 http://trac.macports.org/changeset/52946 Author: t...@macports.org Date: 2009-06-25 19:48:17 -0700 (Thu, 25 Jun 2009) Log Message: --- Remove arn.se mirror, I'm tired of having to wait for it to timeout. trd.no can stay, at least it fails immediately. I have never noticed arn.se being offline, and it is online now as far as I can tell. How long have you been experiencing the issue? What exactly happens? It's never worked for me. Can't ping, can't traceroute, http requests timeout (instead of being refused outright like trd.no). Oh well, added it back. I'll keep the change locally. Hmm, I'm not sure what's going on. Here's my traceroute: $ traceroute arn.se.distfiles.macports.org traceroute to arn.se.distfiles.macports.org (192.157.38.21), 64 hops max, 40 byte packets Anecdotal evidence suggests that they're blocking comcast (only 15 million customers)... last hop is sl-bb21- sto-14-0-0.sprintlink.net before it dies. Can we get an update on the status of the Sweden mirror? -Bill Sounds like he is a customer of Telia, in which case there is no connectivity. Comcast. So, the mirror is hosted by a small ISP that has a habit of blocking ISPs with millions of customers? Brilliant! - Toby ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 25, 2009, at 10:39 PM, David Evans wrote: So perhaps they are blocking comcast Sure looks like it. Only really matters for files that are completely unfetchable anyway, but it's still annoying. Oh well. - Toby ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
(redirecting to mirror admin) On Jun 25, 2009, at 10:19 PM, Toby Peterson wrote: On Jun 25, 2009, at 10:13 PM, Ryan Schmidt wrote: On Jun 26, 2009, at 00:04, Toby Peterson wrote: On Jun 25, 2009, at 9:36 PM, Ryan Schmidt wrote: On Jun 25, 2009, at 21:48, t...@macports.org wrote: Revision: 52946 http://trac.macports.org/changeset/52946 Author: t...@macports.org Date: 2009-06-25 19:48:17 -0700 (Thu, 25 Jun 2009) Log Message: --- Remove arn.se mirror, I'm tired of having to wait for it to timeout. trd.no can stay, at least it fails immediately. I have never noticed arn.se being offline, and it is online now as far as I can tell. How long have you been experiencing the issue? What exactly happens? It's never worked for me. Can't ping, can't traceroute, http requests timeout (instead of being refused outright like trd.no). Oh well, added it back. I'll keep the change locally. Hmm, I'm not sure what's going on. Here's my traceroute: $ traceroute arn.se.distfiles.macports.org traceroute to arn.se.distfiles.macports.org (192.157.38.21), 64 hops max, 40 byte packets Anecdotal evidence suggests that they're blocking comcast (only 15 million customers)... last hop is sl-bb21-sto-14-0-0.sprintlink.net before it dies. Can we get an update on the status of the Sweden mirror? -Bill smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 25, 2009, at 21:48, t...@macports.org wrote: Revision: 52946 http://trac.macports.org/changeset/52946 Author: t...@macports.org Date: 2009-06-25 19:48:17 -0700 (Thu, 25 Jun 2009) Log Message: --- Remove arn.se mirror, I'm tired of having to wait for it to timeout. trd.no can stay, at least it fails immediately. I have never noticed arn.se being offline, and it is online now as far as I can tell. How long have you been experiencing the issue? What exactly happens? ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 25, 2009, at 9:36 PM, Ryan Schmidt wrote: On Jun 25, 2009, at 21:48, t...@macports.org wrote: Revision: 52946 http://trac.macports.org/changeset/52946 Author: t...@macports.org Date: 2009-06-25 19:48:17 -0700 (Thu, 25 Jun 2009) Log Message: --- Remove arn.se mirror, I'm tired of having to wait for it to timeout. trd.no can stay, at least it fails immediately. I have never noticed arn.se being offline, and it is online now as far as I can tell. How long have you been experiencing the issue? What exactly happens? It's never worked for me. Can't ping, can't traceroute, http requests timeout (instead of being refused outright like trd.no). Oh well, added it back. I'll keep the change locally. - Toby ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 26, 2009, at 00:04, Toby Peterson wrote: On Jun 25, 2009, at 9:36 PM, Ryan Schmidt wrote: On Jun 25, 2009, at 21:48, t...@macports.org wrote: Revision: 52946 http://trac.macports.org/changeset/52946 Author: t...@macports.org Date: 2009-06-25 19:48:17 -0700 (Thu, 25 Jun 2009) Log Message: --- Remove arn.se mirror, I'm tired of having to wait for it to timeout. trd.no can stay, at least it fails immediately. I have never noticed arn.se being offline, and it is online now as far as I can tell. How long have you been experiencing the issue? What exactly happens? It's never worked for me. Can't ping, can't traceroute, http requests timeout (instead of being refused outright like trd.no). Oh well, added it back. I'll keep the change locally. Hmm, I'm not sure what's going on. Here's my traceroute: $ traceroute arn.se.distfiles.macports.org traceroute to arn.se.distfiles.macports.org (192.157.38.21), 64 hops max, 40 byte packets [snip] 5 gi0-4-2-6.austtxrdcsc-rtr1.austin.rr.com (24.27.13.106) 16.835 ms 16.852 ms 23.797 ms 6 gig5-3-0.hstntxl3-rtr1.texas.rr.com (72.179.205.36) 24.633 ms 23.167 ms 32.794 ms 7 xe-9-1-0.bar1.houston1.level3.net (4.79.88.25) 24.098 ms xe-9-0-0.bar1.houston1.level3.net (4.79.88.29) 32.037 ms xe-10-3-0.bar1.houston1.level3.net (4.79.88.21) 23.098 ms 8 ae-13-13.ebr1.dallas1.level3.net (4.69.137.138) 27.830 ms 39.939 ms 37.343 ms 9 ae-91-91.csw4.dallas1.level3.net (4.69.136.134) 40.349 ms 39.788 ms 36.537 ms 10 ae-4-99.edge2.dallas3.level3.net (4.68.19.204) 25.534 ms 31.703 ms 37.029 ms 11 sl-st30-dal-0-5-2-0.sprintlink.net (144.232.24.29) 43.279 ms 30.130 ms 30.162 ms 12 sl-crs2-fw-0-6-5-0.sprintlink.net (144.232.20.253) 29.198 ms 35.081 ms sl-crs1-fw-0-6-3-0.sprintlink.net (144.232.19.177) 40.559 ms 13 144.232.20.57 (144.232.20.57) 54.360 ms sl-crs2- kc-0-0-0-2.sprintlink.net (144.232.19.141) 71.386 ms 61.838 ms 14 sl-crs2-chi-0-15-2-0.sprintlink.net (144.232.24.206) 55.972 ms sl-crs1-chi-0-5-0-1.sprintlink.net (144.232.18.212) 63.161 ms sl- crs1-rly-0-2-0-0.sprintlink.net (144.232.19.222) 80.395 ms 15 sl-crs1-nyc-0-10-3-0.sprintlink.net (144.232.9.157) 88.444 ms sl- crs1-rly-0-8-2-0.sprintlink.net (144.232.8.163) 61.202 ms sl-crs1- nyc-0-2-2-0.sprintlink.net (144.232.20.103) 92.893 ms 16 sl-bb22-lon-12-0.sprintlink.net (144.232.9.162) 152.240 ms 146.645 ms sl-crs1-pen-0-5-2-0.sprintlink.net (144.232.20.211) 61.331 ms 17 sl-bb20-bru-14-0-0.sprintlink.net (213.206.129.42) 147.238 ms sl- bb21-tuk-1-0-0.sprintlink.net (144.232.9.184) 65.995 ms sl-bb20- bru-14-0-0.sprintlink.net (213.206.129.42) 302.739 ms 18 sl-bb22-lon-3-0.sprintlink.net (213.206.129.153) 238.499 ms 155.010 ms 148.901 ms 19 sl-bb20-ams-14-0-0.sprintlink.net (213.206.129.45) 177.130 ms 149.066 ms 148.406 ms 20 sl-bb21-ham-6-0-0.sprintlink.net (213.206.129.145) 158.974 ms 158.916 ms 159.116 ms 21 sl-bb21-cop-13-0-0.sprintlink.net (213.206.129.57) 187.535 ms 166.371 ms 165.541 ms 22 sl-bb21-ham-6-0-0.sprintlink.net (213.206.129.145) 158.980 ms sl- bb21-sto-14-0-0.sprintlink.net (213.206.129.34) 173.996 ms 209.338 ms 23 213.206.129.87 (213.206.129.87) 175.544 ms sl-bb21- cop-13-0-0.sprintlink.net (213.206.129.57) 165.083 ms 213.206.129.87 (213.206.129.87) 171.863 ms 24 bfr5-pos-2-0.stupi.net (192.108.195.121) 170.122 ms 172.484 ms sl-bb21-sto-14-0-0.sprintlink.net (213.206.129.34) 192.126 ms 25 213.206.129.87 (213.206.129.87) 181.029 ms bfr6-pos-5-0- gw.stupi.net (192.108.195.254) 173.680 ms 170.425 ms 26 bfr5-pos-2-0.stupi.net (192.108.195.121) 172.688 ms arn.se.distfiles.macports.org (192.157.38.21) 169.788 ms 167.946 ms ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 25, 2009, at 10:13 PM, Ryan Schmidt wrote: On Jun 26, 2009, at 00:04, Toby Peterson wrote: On Jun 25, 2009, at 9:36 PM, Ryan Schmidt wrote: On Jun 25, 2009, at 21:48, t...@macports.org wrote: Revision: 52946 http://trac.macports.org/changeset/52946 Author: t...@macports.org Date: 2009-06-25 19:48:17 -0700 (Thu, 25 Jun 2009) Log Message: --- Remove arn.se mirror, I'm tired of having to wait for it to timeout. trd.no can stay, at least it fails immediately. I have never noticed arn.se being offline, and it is online now as far as I can tell. How long have you been experiencing the issue? What exactly happens? It's never worked for me. Can't ping, can't traceroute, http requests timeout (instead of being refused outright like trd.no). Oh well, added it back. I'll keep the change locally. Hmm, I'm not sure what's going on. Here's my traceroute: $ traceroute arn.se.distfiles.macports.org traceroute to arn.se.distfiles.macports.org (192.157.38.21), 64 hops max, 40 byte packets Anecdotal evidence suggests that they're blocking comcast (only 15 million customers)... last hop is sl-bb21-sto-14-0-0.sprintlink.net before it dies. - Toby ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
On Jun 26, 2009, at 00:04, Toby Peterson wrote: On Jun 25, 2009, at 9:36 PM, Ryan Schmidt wrote: On Jun 25, 2009, at 21:48, t...@macports.org wrote: Revision: 52946 http://trac.macports.org/changeset/52946 Author: t...@macports.org Date: 2009-06-25 19:48:17 -0700 (Thu, 25 Jun 2009) Log Message: --- Remove arn.se mirror, I'm tired of having to wait for it to timeout. trd.no can stay, at least it fails immediately. I have never noticed arn.se being offline, and it is online now as far as I can tell. How long have you been experiencing the issue? What exactly happens? It's never worked for me. Can't ping, can't traceroute, http requests timeout (instead of being refused outright like trd.no). Oh well, added it back. I'll keep the change locally. Now that I think about it, if you can't ping it, MacPorts should never attempt to download from it. Do you see MacPorts delaying while trying to ping it (to determine which server has lowest ping), or is it actually trying to retrieve a file from it and then hanging? ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl
Toby Peterson wrote: On Jun 25, 2009, at 10:13 PM, Ryan Schmidt wrote: On Jun 26, 2009, at 00:04, Toby Peterson wrote: On Jun 25, 2009, at 9:36 PM, Ryan Schmidt wrote: On Jun 25, 2009, at 21:48, t...@macports.org wrote: Revision: 52946 http://trac.macports.org/changeset/52946 Author: t...@macports.org Date: 2009-06-25 19:48:17 -0700 (Thu, 25 Jun 2009) Log Message: --- Remove arn.se mirror, I'm tired of having to wait for it to timeout. trd.no can stay, at least it fails immediately. I have never noticed arn.se being offline, and it is online now as far as I can tell. How long have you been experiencing the issue? What exactly happens? It's never worked for me. Can't ping, can't traceroute, http requests timeout (instead of being refused outright like trd.no). Oh well, added it back. I'll keep the change locally. Hmm, I'm not sure what's going on. Here's my traceroute: $ traceroute arn.se.distfiles.macports.org traceroute to arn.se.distfiles.macports.org (192.157.38.21), 64 hops max, 40 byte packets Anecdotal evidence suggests that they're blocking comcast (only 15 million customers)... last hop is sl-bb21-sto-14-0-0.sprintlink.net before it dies. - Toby I can confirm Toby's results: From my home comcast account after 20 hops it hangs after sl-bb21-cop-13-0-0.sprintlink.net From my office dsl (sbcglobal) it proceeds from there as follows 21 sl-bb21-sto-14-0-0.sprintlink.net (213.206.129.34) 180.406 ms 180.323 ms 180.290 ms 22 213.206.129.87 (213.206.129.87) 180.697 ms 180.691 ms 180.038 ms 23 BFR5-POS-2-0.Stupi.NET (192.108.195.121) 180.763 ms 180.560 ms 180.175 ms 24 BFR6-POS-5-0-GW.Stupi.NET (192.108.195.254) 179.816 ms 179.581 ms 179.640 ms 25 arn.se.distfiles.macports.org (192.157.38.21) 179.160 ms 179.019 ms 178.235 ms So perhaps they are blocking comcast Dave ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
