Rebasing Fedora Silverblue takes too long in Japan. rpm-ostree reports it is 300 kB/s. Apparently, the server is in the US.
rpm-ostree
https://ostree.fedoraproject.org/mirrorlist returns:
https://ostree.fedoraproject.org/mirrorlist
https://d2uk5hbyrobdzx.cloudfront.net/
This domain name resolves as follows:
$ dig d2uk5hbyrobdzx.cloudfront.net ; <<>> DiG 9.18.26 <<>> d2uk5hbyrobdzx.cloudfront.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12700 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;d2uk5hbyrobdzx.cloudfront.net. IN A ;; ANSWER SECTION: d2uk5hbyrobdzx.cloudfront.net. 18 IN A 3.164.148.3 d2uk5hbyrobdzx.cloudfront.net. 18 IN A 3.164.148.218 d2uk5hbyrobdzx.cloudfront.net. 18 IN A 3.164.148.115 d2uk5hbyrobdzx.cloudfront.net. 18 IN A 3.164.148.137 ;; AUTHORITY SECTION: d2uk5hbyrobdzx.cloudfront.net. 18 IN NS ns-952.awsdns-55.net. d2uk5hbyrobdzx.cloudfront.net. 18 IN NS ns-464.awsdns-58.com. d2uk5hbyrobdzx.cloudfront.net. 18 IN NS ns-1836.awsdns-37.co.uk. d2uk5hbyrobdzx.cloudfront.net. 18 IN NS ns-1513.awsdns-61.org. ;; ADDITIONAL SECTION: ns-1513.awsdns-61.org. 18 IN A 205.251.197.233 ns-1836.awsdns-37.co.uk. 18 IN A 205.251.199.44 ns-1836.awsdns-37.co.uk. 18 IN AAAA 2600:9000:5307:2c00::1 ns-464.awsdns-58.com. 18 IN A 205.251.193.208 ns-952.awsdns-55.net. 18 IN A 205.251.195.184 ;; Query time: 1 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Fri Jun 28 14:41:48 JST 2024 ;; MSG SIZE rcvd: 351
All of the IP addresses in the answer section point to the US. I believe it is because the CloudFront CDN is configured with the least price class: https://aws.amazon.com/cloudfront/pricing/
Please upgrade the price class if possible.
No due date.
This distribution is set to "Price class: Use all edge locations (best performance)" already.
Tracing those ip's from here shows them in .jp?
Can you provide a traceroute to them?
I am puzzled as to why it would be slow for you...
The problem is gone now; it now gives decent throughput. I use two Internet accesses so I show the throughput and traceroute below though they are probably useless now. I omitted the internal routes for traceroute.
I'll reopen this issue if I face it again. Thanks for your attention!
This is the network I used when I opened this issue. It now achieves 12.5 MB/s.
5 150.99.190.97 (150.99.190.97) 1.834 ms 2.065 ms 2.051 ms 6 150.99.11.33 (150.99.11.33) 2.129 ms 2.010 ms 2.092 ms 7 210.171.224.212 (210.171.224.212) 2.515 ms 2.365 ms 2.458 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
This network achieves 24 MB/s now.
2 180.8.126.170 (180.8.126.170) 5.022 ms 180.8.126.146 (180.8.126.146) 6.378 ms 180.8.126.186 (180.8.126.186) 5.674 ms 3 180.8.126.121 (180.8.126.121) 11.191 ms 153.128.214.13 (153.128.214.13) 6.298 ms 180.8.126.205 (180.8.126.205) 4.887 ms 4 210.173.176.188 (210.173.176.188) 8.899 ms 8.875 ms 210.173.176.198 (210.173.176.198) 19.389 ms 5 15.230.152.11 (15.230.152.11) 8.080 ms * * 6 52.95.30.28 (52.95.30.28) 8.003 ms 15.230.152.137 (15.230.152.137) 9.645 ms 52.95.30.36 (52.95.30.36) 7.324 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
Metadata Update from @aodaki: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.