[Riyad Kalla]

Your tracert actually looks pretty good… another alternative is to use a download manager that can resume broken downloads as opposed to your browser’s built in download to get around that problem.

[Scott Anderson]

Thanks for posting this. We did some research from one of our download servers using tracepath followed by a “ping flood” to check connectivity. I tried the tracepath to the first routable address you list, 213.46.162.17, and got the following:

Results of:  tracepath 213.46.162.17
1:  iits01180.inlink.com (209.135.140.180)                 0.211ms pmtu 1500
1:  iits01254.inlink.com (209.135.140.254)                 1.202ms
2:  primary-rose-gw.primary.net (206.196.99.249)           3.042ms
3:  stl-core-01.primary.net (216.87.63.10)                 3.819ms
4:  198.88.239.197 (198.88.239.197)                      asymm 12  13.895ms
5:  p6-0.core01.ord01.atlas.cogentco.com (154.54.3.65)   asymm 11  13.818ms
6:  p14-0.core01.bos01.atlas.cogentco.com (66.28.4.109)  asymm 15  39.613ms
7:  p3-0.core01.lon01.atlas.cogentco.com (130.117.0.45)  asymm 15 110.512ms
8:  p15-0.core01.par01.atlas.cogentco.com (130.117.1.122) asymm 14 112.081ms
9:  p9-0.core01.lys01.atlas.cogentco.com (130.117.1.102) asymm 15 119.158ms
0:  upc.par01.atlas.cogentco.com (130.117.14.94)         asymm 13 146.430ms
1:  fr-par02a-rd1-pos-1-0.aorta.net (213.46.160.25)      144.965ms
2:  uk-lon01a-rd1-pos-2-0.aorta.net (213.46.160.230)     asymm 11 128.064ms
3:  uk-lon01a-rd2-10ge-7-0.aorta.net (213.46.174.34)     asymm 12 126.771ms
4:  no reply
5:  no reply

Once the path goes asymmetric through aorta.net we can’t track it any further as it gets lost in aorta.net somewhere. However, it looks like it makes it close to you (213.46.174.34) without issue. The next test was a ping flood to check for packet loss. Naturally, I tested as far as I could penetrate with the traceroute.

Results of: ping -f -c 100 -s 1000 213.46.174.34
PING 213.46.174.34 (213.46.174.34) 1000(1028) bytes of data.

--- 213.46.174.34 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 1417ms
rtt min/avg/max/mdev = 102.835/106.915/142.126/7.521 ms, pipe 11, ipg/ewma 14.316/104.071 ms

There was no packet loss and the times are quite good. However, testing to 213.46.162.17 produced 100% packet loss, as expected, since no routing to it could be found.

From the results here, it looks like the issue seems to be at the last piece of the hop, closest to you, within your ISP. I’d suggest contacting them and asking them why your route to downloads.myeclipseide.com is so sporadic. I believe they’re likely prioritizing the traffic differently than EU traffic since it has to go trans-atlantic. Many ISP’s use transparent proxies to share bandwidth for long hops like this, to save money, but it greatly reduces the throughput you’ll see. From the asymmetric route and the fact that the times into your ISP in general are good, I believe only they can address the issue of the speed of the final hop to you. Hope that helps give you some ammunition to ask the right questions.

[Prasanna Tuladhar]

The download speed is quite slow around 10 kbs/sec though I have a 4MB DSL connection.
I think MyEclipse Team should seriously think about creating a mirror for European countries or at least changing their current hosting site or strategy and find a way to get rid of this problem.
I cannot simply understand how this problem has been resurfacing time and again.

1 15 ms 14 ms 19 ms dslb-084-056-000-001.pools.arcor-ip.net [84.56.0
.1]
2 19 ms 19 ms 19 ms mue-145-254-13-129.arcor-ip.net [145.254.13.129]

3 19 ms 19 ms 19 ms mue-145-254-16-86.arcor-ip.net [145.254.16.86]
4 19 ms 29 ms 16 ms so-1-0.hsa2.Munich1.Level3.net [212.162.47.105]

5 19 ms 19 ms 19 ms ae-0-15.mp1.Munich1.Level3.net [195.122.176.161]

6 20 ms 29 ms 19 ms so-0-1-0.bbr2.Frankfurt1.Level3.net [4.68.128.54
]
7 119 ms 119 ms 119 ms as-1-0.bbr2.NewYork1.Level3.net [64.159.1.85]
8 120 ms 119 ms 119 ms ge-2-1.core1.NewYork1.Level3.net [4.68.97.72]
9 119 ms 119 ms 119 ms Broadwing-Level3-oc12.NewYork1.Level3.net [63.21
1.54.70]
10 119 ms 118 ms 119 ms so7-1-0.a1.nwaknj.broadwing.net [216.140.8.202]

11 119 ms 119 ms 119 ms s0-1-0.c1.nwyk.broadwing.net [216.140.8.197]
12 140 ms 139 ms 139 ms 216.140.15.70
13 139 ms 139 ms 139 ms p2-2.a0.cncn.broadwing.net [216.140.15.73]
14 140 ms 139 ms 139 ms 65.91.145.18
15 140 ms 139 ms 139 ms 198.88.239.198
16 180 ms 179 ms 180 ms stl-colo-01.primary.net [216.87.63.12]
17 170 ms 169 ms 159 ms r-1.core04.stl.rosehosting.com [206.196.99.250]

18 160 ms 159 ms 159 ms iits01120.inlink.com [209.135.140.120]

[Scott Anderson]

The download speed is quite slow around 10 kbs/sec though I have a 4MB DSL connection.
I think MyEclipse Team should seriously think about creating a mirror for European countries or at least changing their current hosting site or strategy and find a way to get rid of this problem.
I cannot simply understand how this problem has been resurfacing time and again.

I agree that at the time of your post that download speed is certainly down from where we’d like from time to time. One possible problem is that there are currently several hundred downloads in progress and even though we have a dedicated 100Mbps channel from our servers, when that bandwidth is divided across that number of users, the rate for any individual user suffers. The reason this issue resurfaces is that these posts about the download rate always occur during the very peak server loads of new releases. And, during those peak times, with loads this high, the total pipe size can become the limiting factor.

We’ve tried to compensate over time, both by providing the BitTorrent downloads (have you tried those by any chance?) and increasing our dedicated bandwidth. Of course, download speed also varies with the path to the servers. For example, I’m downloading right now at over 600KB/sec, even though our servers are several states away from our office location.

Thank you for providing the tracing information as we requested so we can continue to try to improve the download experience for everyone, wherever they’re located.

Oh, and for those of you reading this that are wondering when the best time to download would be, based on the lowest server load level, that is sometime between 16:00 and 18:00 CST.

[Scott Anderson]

OK everyone,

We’ve added a dedicated server in London to handle all EU and Asian traffic. It’s hooked to a dedicated 100Mbps pipe and our tests show it at least doubles the download speed in Europe. You don’t need to do anything special to use it — once you start a download, we check your IP and if it’s from Europe or Asia we silently redirect you to the new server. Hope you like it…

[parsnip]

Is the London server still operating? I’m trying to download the MyEclipse 7.0 M2 and the best I’m getting is 50KB/s on a 20MB cable connection that gets up to 2.2MB/s for other downloads. Every other release of MyEclipse I’ve tried to download over the past couple of years has had the same problem. I thought it was just throttling at your end until I spotted this forum topic. Obviously, I’d prefer not to wait for 4 hours to download MyEclipse every time. Any idea where the problem lies?

[Riyad Kalla]

parsnip,

You can try the Pulse-optimized install for MyEclipse, it’s a multithreaded downloader that will attempt to pull MyEclipse from all of the mirrors, can greatly increase install time for any Eclipse-based install.

[Author]

Posts