CERN 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.