ping statistics -ġ00 packets transmitted, 94 packets received, 6.0% packet loss lil.fr. ping statistics -ġ00 packets transmitted, 100 packets received, 0.0% packet loss I just realized, packet loss could lead to a low transfer rate or even to a stalled TCP connection (due to the TCP sliding window protocol). Would it be difficult to allow the user to select a mirror in the installer, in case cannot be fixed? I'm using MacPorts since the beginning of 2010, and was always very fast for me I first noticed "port selfupdate" taking longer and longer sometime last year, so I switched to the French mirror without looking into what actually happens (until last Saturday). I also performed the Vultr speed test, downloading 100MB from their Silicon Valley data center (I guess San Jose is not that far from San Francisco), to see if there are general network issues:ġ00 100M 100 100M 0 0 1499k 0 0:01:08 0:01:08 -:-:- 1588kĭownload the directory index from the Korean mirror, since Seattle seems down:ġ00 1357k 100 1357k 0 0 311k 0 0:00:04 0:00:04 -:-:- 311k I used curl to see how fast I can get the directory index, which is big enough to measure: Replying to fetching distfiles from slow as well? That's the same server. Is intentionally limiting its bandwidth for clients outside the USA? Unfortunately, I didn't see any option of selecting a different mirror in the pkg installer. Mihai Moldovan, Karlsruhe, Germany (primary) or If any problems or questions arise, please contact It though features a German RIPE failover IP. ![]() The server is physically located in Roubaix, FranceĪnd hosted by OVH. You may sync whenever and how often you want,īut keep in mind, that we enforce a maximum of 5 (five)Ĭoncurrent connections per host. $ time rsync -rztv rsync://lil.fr./release/tarballs/base.tar. $ time rsync -rztv rsync:///release/tarballs/base.tar. To make sure this isn't due to a regression in El Capitan, I tried rsync-ing base.tar manually from my Fedora netbook, and compared the main server,, with the French mirror (I'm in Germany): The first 20 minutes seem to be just the rsync-ing of base.tar and ports.tar, with a transfer rate jumping between 14KB/s and 33KB/s, as seen in Activity Monitor. The last 30 minutes of that time are spent by tclsh building the PortIndex, already reported as bug #49050. I installed MacPorts 2.3.4 using the official pkg installer on OS X 10.11.1 (first on Saturday, and now again, to try to figure out why it takes 52 minutes on my Mac Mini "late 2009").
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |