Since you and others get high speeds it is seems not to be a server issue. It must be something along the way.
And @hansd is probably on the same cable path as me to Europe. Nothing on the web about cable faults, but they like to keep them secret.
Back on March 2nd I posted a similar question on the slow nightly download.
I hope we can use the Digi-Key mirror soon.
I’m downloading again today and am getting 5M/sec. Probably was congestion somewhere.
There is this (US hosted mirror?), but it has not been updated (8-(
Still impossible from SE Asia
Sourceforge would work if updated, their main server for me is in Japan
Still the same for Australia on the 10/3.
That’s not official. Be wary.
I do not experience issues from western US locations (I max out my download bandwidth at about 8MB/s). This generally runs over the cogentco route across the US before getting to Europe, so 20 hops before hitting CERN.
I’m curious to hear whether people who experience issues see the same slow speeds when they disable their download managers? If they do, it would be informative to see the output of the command
traceroute kicad-downloads.s3.cern.ch
Mine looks like (removing the first hop with my actual IP)
3 ae-101-rur02.davis.ca.ccal.comcast.net (68.87.201.25) 14.289 ms 12.960 ms 17.773 ms
4 ae-33-rur102.sacramento.ca.ccal.comcast.net (68.85.120.246) 14.128 ms 16.242 ms 14.839 ms
5 ae-2-ar01.fresno.ca.ccal.comcast.net (68.85.120.201) 25.318 ms 19.773 ms 20.015 ms
6 be-33667-cr02.losangeles.ca.ibone.comcast.net (68.86.93.37) 26.272 ms 25.186 ms 26.631 ms
7 be-11599-pe01.losangeles.ca.ibone.comcast.net (68.86.84.194) 27.200 ms 26.371 ms 25.872 ms
8 50.248.118.250 (50.248.118.250) 26.067 ms 27.302 ms 25.439 ms
9 be3271.ccr41.lax01.atlas.cogentco.com (154.54.42.101) 26.151 ms 25.914 ms 25.705 ms
10 be2932.ccr32.phx01.atlas.cogentco.com (154.54.45.161) 37.721 ms 38.038 ms 38.404 ms
11 be2930.ccr21.elp01.atlas.cogentco.com (154.54.42.78) 54.430 ms
be2929.ccr21.elp01.atlas.cogentco.com (154.54.42.66) 49.576 ms 50.491 ms
12 be2928.ccr42.iah01.atlas.cogentco.com (154.54.30.161) 61.639 ms 63.418 ms 61.979 ms
13 be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) 70.660 ms
be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 71.172 ms
be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) 71.937 ms
14 be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 99.357 ms
be2113.ccr42.dca01.atlas.cogentco.com (154.54.24.221) 82.263 ms
be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 83.884 ms
15 be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 92.013 ms 89.015 ms
be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 91.413 ms
16 be3627.ccr41.par01.atlas.cogentco.com (66.28.4.198) 160.785 ms
be3628.ccr42.par01.atlas.cogentco.com (154.54.27.170) 161.875 ms 160.682 ms
17 be2471.rcr21.lys01.atlas.cogentco.com (130.117.49.38) 177.840 ms
be2472.rcr21.lys01.atlas.cogentco.com (130.117.49.122) 165.770 ms
be2471.rcr21.lys01.atlas.cogentco.com (130.117.49.38) 168.898 ms
18 be3056.rcr21.gva01.atlas.cogentco.com (154.54.58.206) 174.498 ms 172.321 ms 173.623 ms
19 be3557.nr51.b022783-0.gva01.atlas.cogentco.com (154.25.4.198) 173.482 ms 172.896 ms 173.676 ms
20 cern.demarc.cogentco.com (149.6.55.58) 172.201 ms 179.144 ms 170.985 ms
21 e773-e-rbrxl-2-ne10.cern.ch (192.65.184.158) 175.495 ms 184.778 ms 177.642 msCERN is now fast again from a different location in Malaysia, so maybe a routing error fixed
Still having issues. It looks like the message gets tossed around at Cern with a few timeouts thrown in.
Microsoft Windows [Version 10.0.17134.590]
© 2018 Microsoft Corporation. All rights reserved.
tracert kicad-downloads.s3.cern.ch
Tracing route to s3.cern.ch [188.185.77.113]
over a maximum of 30 hops:
2 55 ms 55 ms 55 ms 203.23.237.11
3 56 ms 80 ms 100 ms 203.23.236.49
4 56 ms 55 ms 55 ms 202.139.16.65
5 * * * Request timed out.
6 56 ms 56 ms 56 ms 59.154.18.6
7 212 ms 212 ms 212 ms 203.208.174.49
8 * * * Request timed out.
9 340 ms 340 ms 339 ms ae14.cs1.lax112.us.eth.zayo.com [64.125.27.40]
10 366 ms 342 ms 341 ms ae3.cs1.dfw2.us.eth.zayo.com [64.125.29.52]
11 340 ms 344 ms 342 ms ae5.cs1.iah1.us.eth.zayo.com [64.125.28.98]
12 342 ms 343 ms 341 ms ae3.cs1.dca2.us.eth.zayo.com [64.125.29.48]
13 341 ms * 342 ms ae4.cs1.lga5.us.eth.zayo.com [64.125.29.202]
14 341 ms 341 ms 341 ms ae5.cs1.lhr11.uk.eth.zayo.com [64.125.29.127]
15 341 ms 340 ms 340 ms ae27.mpr2.lhr2.uk.zip.zayo.com [64.125.30.237]
16 341 ms 340 ms 340 ms ae11.mpr1.lhr15.uk.zip.zayo.com [64.125.30.53]
17 * * * Request timed out.
18 355 ms 354 ms 354 ms ae6.mx1.lon2.uk.geant.net [62.40.98.37]
19 355 ms 356 ms 355 ms ae0.mx1.par.fr.geant.net [62.40.98.77]
20 369 ms 369 ms 369 ms ae2.mx1.gen.ch.geant.net [62.40.98.153]
21 367 ms 367 ms 367 ms cern-ias-cern-gw.gen.ch.geant.net [83.97.88.34]
22 358 ms 358 ms 358 ms e773-e-rbrxl-2-ne10.cern.ch [192.65.184.158]
23 * * * Request timed out.
24 * * * Request timed out.
25 355 ms 356 ms 355 ms b773-b-rbrml-2-sg7.cern.ch [192.65.196.57]
26 359 ms 358 ms 358 ms k513-b-rjuxl-v1-cd10.cern.ch [192.65.196.198]
27 * * * Request timed out.
28 366 ms 366 ms 366 ms cephgabe-rgw-9b7f976aa8.cern.ch [188.185.77.113]
Trace complete.
Hi everyone. I’m the guy who maintain(s,ed) the Sourceforge mirror.
I got frustrated with download speeds from KiCad’s original Paris-based server to my location and saw that others were having problems as well. I knew Sourceforge had a pretty good CDN for their file release service and wanted to take advantage of that.
So I took the initiative of creating a project, with KiCad’s logo (sorry if TM infringement), making it clear that it is unofficial, and copying all the files from the official server. Then set up a scheduled sync every 12 hours so I could get the nightlies within a reasonable amount of time.
Then Sourceforge wanted to migrate to a new datacenter, breaking shell access for a prolonged period of time. This cause some people to conclude that the mirror was dead already. I planned to upload KiCAD 5.0 manually if it was released during that time, but thankfully SF finally finished their migration and shell access was restored!
…With one crucial roadblock - no outgoing connections allowed! I could no longer sync directly to the download server.
There was no other option but to use myself as an intermediary: I have plenty of space on a NAS to also have a local copy, which would then be pushed up to SF. Thankfully I also have unmetered quota with my ISP and a UPS, so it should always work!
Then KiCad decided to migrate their downloads to AWS S3. Yay! More robust connectivity! Boo! The new web pages broke my scripts! Oh, well. My mirror is probably no longer needed.
Now I wake up this morning to an email from @iabarry who points me to this thread and I see that downloads are still not great.
Well, I know what I’m doing today!
Addendum:
As for trust, I won’t blame you. I’m just a rando on the Internet.
As far as I know, I have no way of proving that the files on SF exactly match the files from CERN. I do know that the Windows builds are signed by Simon Richter.
1 Like
@hansd- Thanks! I note in your link, the majority of time is between NSW and the US backbone (zayo.com). This indicates a routing error (or other issue like congestion) with your local connection. Once you reach the US, it is about 20ms to CERN. 300ms to get over the southern cross cable seems awfully high.
If all of the folks having issues with downloads right now are in the same vicinity of the world, we might have a culprit.
edit: It looks like you are routing through Singapore for 150ms and then another 200ms over one of the Singapore-US links. So not the standard Southern Cross Cable but maybe routing around something?
Tracing route to s3.cern.ch [2001:1458:201:e4:100:5e7]
over a maximum of 30 hops:
1 3 ms 3 ms 3 ms
2 * 372 ms 381 ms 2600:1011:b11b:95ee:0:72:1860:f240
3 * * * Request timed out.
4 383 ms 362 ms 369 ms 2001:10:10::1
5 * * * Request timed out.
6 * * * Request timed out.
7 386 ms 381 ms 359 ms 2001:4888:66:207b:645:26::
8 386 ms 333 ms 351 ms 2001:4888:66:200e:645:25:0:1
9 346 ms * 395 ms 2001:4888:66:2000:645:26:0:2
10 378 ms 375 ms 384 ms 2001:4888:6f:4192:645:1:0:1
11 381 ms 380 ms * 2001:4888:6f:4192:645:1:0:1
12 366 ms 378 ms 364 ms 2001:4888:66:1002:645:24::
13 374 ms 379 ms 374 ms 2610:18:116:8000::1
14 378 ms 372 ms 372 ms lca1.phoenix-az.us.xo.net [2610:18::5905]
15 378 ms 376 ms 370 ms 2610:18::5501
16 358 ms 359 ms * ctr1.la-ca.us.xo.net [2610:18::2084]
17 370 ms 390 ms 378 ms be3015.ccr41.lax05.atlas.cogentco.com [2001:550:3::e9]
18 * 387 ms * be3359.ccr42.lax01.atlas.cogentco.com [2001:550:0:1000::9a36:345]
19 378 ms * * be2932.ccr32.phx01.atlas.cogentco.com [2001:550:0:1000::9a36:2da1]
20 * 397 ms * be2930.ccr21.elp01.atlas.cogentco.com [2001:550:0:1000::9a36:2a4e]
21 * 422 ms * be2927.ccr41.iah01.atlas.cogentco.com [2001:550:0:1000::9a36:1ddd]
22 * * * Request timed out.
23 * * * Request timed out.
24 * 463 ms * be2806.ccr41.jfk02.atlas.cogentco.com [2001:550:0:1000::9a36:2869]
25 * * * Request timed out.
26 494 ms * * be2471.rcr21.lys01.atlas.cogentco.com [2001:550:0:1000::8275:3126]
27 454 ms 527 ms 525 ms be3056.rcr21.gva01.atlas.cogentco.com [2001:550:0:1000::9a36:3ace]
28 532 ms 486 ms * be3557.nr51.b022783-0.gva01.atlas.cogentco.com [2001:550:0:1000::9a19:4c6]
29 519 ms 516 ms 496 ms 2001:978:2:2::21:2
30 529 ms 500 ms * e773-e-rbrxl-2-ne10.cern.ch [2001:1458:0:32::2]
Trace complete.
@Sprig: Yours looks to be a Verizon Wireless issue as the first 372ms is just getting out to the first AP. After that, you are 180ms to CERN (looks to be along the same backbone I use). Interestingly, you are using IPv6, so the route looks a be more direct after you get to Phoenix (hop 14)
note: In these comments, I should be careful to delineate that ping time is not the same as bandwidth. However, if the ACK packet is delayed due to network lag, the overall download speed will be throttled.
1 Like
I don’t know that I have an issue. I have not tried to download any build in the last few weeks.
It only took me a few moments to fetch the tracert for someone in the middle of the desert where there were up to a million other RV’ers in the same desert only a few weeks back.
We aren’t using S3. It’s CERN’s Ceph cluster with S3 api. That’s why the url has s3 in it as silly as it is.
We are working on getting another mirror that may actually be on AWS.
1 Like
Thanks for your reply. I understood the difference after reading the current mailing list thread on this topic.
As I understand it, the Ceph S3 API is compatible with all the usual relevant AWS tools. I’m trying to use s3fs in order to eliminate the need for my local copy, but I may have the bucket name wrong. Is it kicad-downloads?
As far as I am aware, Simon Richters signature is a good proof that a file is genuine
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.