Rustup: Super slow downloads, who to talk to to find a solution?
Hey, I know this isn't a rustup issue, but the downloads from the current CloudFront setup (https://static.rust-lang.org) here in central Tokyo are INCREDIBLY slow. After the initial burst of perhaps 1MB/s it quickly falls to below <100KB/s. It can easily take half an hour for rustup update to finish. Manual wget does more or less the same so there shouldn't be anything wrong with rustup itself.
I'm wondering where I should report this to. https://github.com/rust-lang/rust-www has links to downloads, but I believe it doesn't actually know anything more about them. https://github.com/rust-lang/rust seems too generic. Ideas?
sorccu
All 12 comments
Our cloudfront distribution is only configured with US and Europe endpoints. We could add Asia but I'm not convinced that will make it better - I don't see why your throughput would be so bad even going across the ocean. I've heard reports of good throughput in Korea, and bad throughput in Canada.
brson
on 3 Jun 2016
Looking into prices for just turning on all the edge locations.
brson
on 3 Jun 2016
As an organizer of Tokyo Rust Meetup, I can tell you it would do wonders if we could give the APAC region a little love. If it's not too much trouble to turn the edge locations on, I'd be happy to report back with results. I believe there will be a noticeable change, but if not - well, we could at least say we tried.
For what it's worth, I get 80-90 Mbps on https://fast.com/ very consistently.
sorccu
on 3 Jun 2016
I'm discussing the billing changes internally.
brson
on 3 Jun 2016
I've turned on all edge servers for both static.rlo and www.rlo. Let me know if you notice any different performance.
brson
on 4 Jun 2016
Oh man, the difference is like night and day... downloading at several MB/s now, best value 5.9MB/s so far. And the completion ETA actually decreases with time unlike before! You've done a huge service to the APAC region.
This is from yesterday:
% ping static.rust-lang.org
PING d3ah34wvbudrdd.cloudfront.net (52.84.24.100): 56 data bytes
64 bytes from 52.84.24.100: icmp_seq=0 ttl=48 time=132.127 ms
64 bytes from 52.84.24.100: icmp_seq=1 ttl=48 time=131.933 ms
64 bytes from 52.84.24.100: icmp_seq=2 ttl=48 time=132.096 ms
Request timeout for icmp_seq 3
64 bytes from 52.84.24.100: icmp_seq=3 ttl=48 time=1002.080 ms
64 bytes from 52.84.24.100: icmp_seq=4 ttl=48 time=131.733 ms
64 bytes from 52.84.24.100: icmp_seq=5 ttl=48 time=131.069 ms
64 bytes from 52.84.24.100: icmp_seq=6 ttl=48 time=131.217 ms
64 bytes from 52.84.24.100: icmp_seq=7 ttl=48 time=132.088 ms
64 bytes from 52.84.24.100: icmp_seq=8 ttl=48 time=131.984 ms
64 bytes from 52.84.24.100: icmp_seq=9 ttl=48 time=131.358 ms
64 bytes from 52.84.24.100: icmp_seq=10 ttl=48 time=132.111 ms
64 bytes from 52.84.24.100: icmp_seq=11 ttl=48 time=1007.176 ms
Now:
% ping static.rust-lang.org
PING d3ah34wvbudrdd.cloudfront.net (54.230.111.10): 56 data bytes
64 bytes from 54.230.111.10: icmp_seq=0 ttl=47 time=24.866 ms
64 bytes from 54.230.111.10: icmp_seq=1 ttl=47 time=25.446 ms
64 bytes from 54.230.111.10: icmp_seq=2 ttl=47 time=25.617 ms
64 bytes from 54.230.111.10: icmp_seq=3 ttl=47 time=24.547 ms
64 bytes from 54.230.111.10: icmp_seq=4 ttl=47 time=26.130 ms
64 bytes from 54.230.111.10: icmp_seq=5 ttl=47 time=26.089 ms
64 bytes from 54.230.111.10: icmp_seq=6 ttl=47 time=24.854 ms
64 bytes from 54.230.111.10: icmp_seq=7 ttl=47 time=25.695 ms
64 bytes from 54.230.111.10: icmp_seq=8 ttl=47 time=25.969 ms
64 bytes from 54.230.111.10: icmp_seq=9 ttl=47 time=25.780 ms
64 bytes from 54.230.111.10: icmp_seq=10 ttl=47 time=24.936 ms
64 bytes from 54.230.111.10: icmp_seq=11 ttl=47 time=25.720 ms
64 bytes from 54.230.111.10: icmp_seq=12 ttl=47 time=25.831 ms
64 bytes from 54.230.111.10: icmp_seq=13 ttl=47 time=25.738 ms
However it's not peak time right now so I'll post a few more results later. I'm not expecting huge changes, though, as it didn't impact the slowness much either.
sorccu
on 4 Jun 2016
Solid 3-6MB/s throughout the day, I think we can call this issue fixed.
sorccu
on 4 Jun 2016
I am in china,and I am running curl -sSf https://static.rust-lang.org/rustup.sh | sh -s -- --channel=nightly
only 50 k/s,
wsdjeg
on 5 Jun 2016
Still very very fast for me, going up to 6.5MB/s easily. Definitely fixed it for Japan at least.
I'm not sure if much can be done about the China thing. I would recommend creating a separate issue for that, as the Chinese internet is kind of special.
Closing this issue as fixed. Thanks @brson!
sorccu
on 6 Jun 2016
I'm happy it wored for you @sorccu.
@wsdjeg I do encourage you to make another issue about Chinese download speed.
brson
on 6 Jun 2016
For what it's worth, I've tried to update nightly from Australia four times in the last two days, and each component peaks at ~200 KiB/s and just slows down from there until until one of them times out. Each failure is caused by 'Timeout was reached (Operation too slow. Less than 10 bytes/sec transferred the last 30 seconds)'. This is on a 15Mb/s connection, which is normal for Australia and 100x faster than these channel updates. And I've never seen rustup go faster than this.
cormacrelf
on 19 Apr 2017
@cormacrelf late reply but using a US VPN made it go from ~200 KiB/s to ~3 MiB/s 馃檮
gabbyzhat
on 4 Sep 2018
Related issues
wezm
路
3Comments
mcandre
路
4Comments
Stargateur
路
3Comments
KasMA1990
路
3Comments
lilred
路
3Comments
Most helpful comment
For what it's worth, I've tried to update nightly from Australia four times in the last two days, and each component peaks at ~200 KiB/s and just slows down from there until until one of them times out. Each failure is caused by 'Timeout was reached (Operation too slow. Less than 10 bytes/sec transferred the last 30 seconds)'. This is on a 15Mb/s connection, which is normal for Australia and 100x faster than these channel updates. And I've never seen rustup go faster than this.