* [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org) @ 2018-12-03 15:43 Ludovic Courtès 2018-12-03 23:44 ` Mark H Weaver [not found] ` <87tvju6145.fsf@gnu.org> 0 siblings, 2 replies; 11+ messages in thread From: Ludovic Courtès @ 2018-12-03 15:43 UTC (permalink / raw) To: guix-patches; +Cc: guix-devel Hello Guix! These patches (actually the last one) switch Guix to default to <https://ci.guix.info> for substitutes, in preparation for the upcoming 0.16.0 release (hopefully this week!). Rationale: • berlin.guixsd.org generally performs better than hydra.gnu.org; • berlin supports x86, ARMv7, and AArch64 (hydra lacks AArch64); • berlin has much more storage space than hydra; • berlin runs Cuirass on GuixSD, so software-wise, it corresponds to what we want to push; Cuirass still has limitations in some ways compared to Hydra, but we’re getting there, and hydra.gnu.org is still up and running so we can still use it, e.g., to track build progress until Cuirass is as convenient. For the domain name I initially wanted “ci.guix.gnu.org” but we failed to set that up. Oh well, I think that’s OK. This change modifies the manual. Translations will thus be stale; Julien, do you think it’d be reasonable to push a new pre-release to the Translation Project? Or should be just live with the slight inaccuracy? Thanks, Ludo’. Ludovic Courtès (3): etc: Add "ci.guix.info.pub" public key file. Remove most references to hydra.gnu.org. build: Default to https://ci.guix.info for substitutes. Makefile.am | 5 +- build-aux/check-available-binaries.scm | 4 +- .../check-final-inputs-self-contained.scm | 2 +- config-daemon.ac | 10 +-- doc/contributing.texi | 2 +- doc/guix.texi | 67 +++++++++---------- etc/substitutes/ci.guix.info.pub | 1 + gnu/services/base.scm | 4 +- gnu/system/install.scm | 2 +- guix/scripts/build.scm | 2 +- guix/scripts/size.scm | 2 +- guix/scripts/substitute.scm | 2 +- guix/self.scm | 3 + guix/store.scm | 2 +- 14 files changed, 51 insertions(+), 57 deletions(-) create mode 120000 etc/substitutes/ci.guix.info.pub -- 2.19.2 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org) 2018-12-03 15:43 [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org) Ludovic Courtès @ 2018-12-03 23:44 ` Mark H Weaver 2018-12-04 5:55 ` [bug#33600] " Ricardo Wurmus [not found] ` <87tvju6145.fsf@gnu.org> 1 sibling, 1 reply; 11+ messages in thread From: Mark H Weaver @ 2018-12-03 23:44 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, guix-patches Hi Ludovic, Ludovic Courtès <ludo@gnu.org> writes: > These patches (actually the last one) switch Guix to default to > <https://ci.guix.info> for substitutes, in preparation for the > upcoming 0.16.0 release (hopefully this week!). Who owns the guix.info domain? Also, who owns the guixsd.org domain? Thanks, Mark ^ permalink raw reply [flat|nested] 11+ messages in thread
* [bug#33600] [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org) 2018-12-03 23:44 ` Mark H Weaver @ 2018-12-04 5:55 ` Ricardo Wurmus 0 siblings, 0 replies; 11+ messages in thread From: Ricardo Wurmus @ 2018-12-04 5:55 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel, 33600 Hi Mark, > Ludovic Courtès <ludo@gnu.org> writes: > >> These patches (actually the last one) switch Guix to default to >> <https://ci.guix.info> for substitutes, in preparation for the >> upcoming 0.16.0 release (hopefully this week!). > > Who owns the guix.info domain? I registered it and offered it to Guix Europe (though we aren’t yet sharing administration of the domain). -- Ricardo ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <87tvju6145.fsf@gnu.org>]
[parent not found: <87ftv7l6gy.fsf@gmail.com>]
[parent not found: <d870d06a-a95c-2b0b-a196-b5166d50400a@goebel-consult.de>]
[parent not found: <87pnua244k.fsf@gnu.org>]
* [bug#33600] Using a CDN or some other mirror? [not found] ` <87pnua244k.fsf@gnu.org> @ 2018-12-11 16:38 ` Giovanni Biscuolo 2018-12-14 8:35 ` Hartmut Goebel 1 sibling, 0 replies; 11+ messages in thread From: Giovanni Biscuolo @ 2018-12-11 16:38 UTC (permalink / raw) To: Ludovic Courtès, Hartmut Goebel; +Cc: guix-devel, 33600 [-- Attachment #1: Type: text/plain, Size: 2785 bytes --] Hi all, my two cents... (I can't still help with a public cache, I hope soon...) Ludovic Courtès <ludo@gnu.org> writes: [...] >> TL;DR: A CDN is a centralized infrastructure, allowing to collect >> information about valuable vulnerability information of almost all >> Guix-users and -systems. This is might become a thread to freedom of >> speech, human rights, democracy and economics. Guix should build on a >> decentralized infrastructure. I completely agree with you, decentralization is the solution unfortunately the **only functioning** way is to avoid current Internet, since it's broken (https://youbroketheinternet.org/); I see GuixSD as an integral part of The Project Map™ https://youbroketheinternet.org/map ...but to fix the situation we need a substantial GNUnet(work) effect and for that we _need_ GuixSD substitutes to be easily and quickly downloaded (can we avoid this asking potential adopters to be patient or to build?) maybe we should divide this task in two steps: 1. distributed substitutes: caching servers hosted by a network of friendly institutions and companies donated to GNU/GuixSD, with a haproxy frontend for geolocated load-balancing [1] 2. decentralized substitutes: caching servers on IPFS or better (since it allows complete anonimity) on GNUnet > Heck it would be ironic to find myself arguing in favor of centralized > commercial services. So I won’t do that. :-) I see no problems with commercial services, _unfortunately_ nowadays this *almost* always means centralized silos, usually exploited for global surveillance (since Internet is broken) [...] > The operator of a substitute server (or caching proxy), in general, > knows which IPs downloaded vulnerable software. This is the main > threat. on Internet, and on IPFS? (sorry for the ignorance) on GNUNet filesharing can be completely anonymous, but the performace is degraded (so we need a large network effect here) > This can be mitigated by talking to nearby mirrors and not just > ci.guix.info, a feature we implemented a year ago (see > <https://gnu.org/s/guix/blog/2017/reproducible-builds-a-status-update/>), > or by using several substitute servers, or by not using (or not always > using) substitutes. Few distros have all these options. > > We might also be able to somehow balance requests between several CDNs > or mirrors. did someone explored an haproxy (with geolocation) solution? is there a wip-haproxy attempt? [...] HTH Giovanni [1] in the next few weeks I'm going to test an haproxy instance with geolocated ACLs following this directions https:/www.haproxy.com/blog/use-geoip-database-within-haproxy/ -- Giovanni Biscuolo Xelera IT Infrastructures [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* [bug#33600] Using a CDN or some other mirror? [not found] ` <87pnua244k.fsf@gnu.org> 2018-12-11 16:38 ` [bug#33600] Using a CDN or some other mirror? Giovanni Biscuolo @ 2018-12-14 8:35 ` Hartmut Goebel [not found] ` <87tvjgeb12.fsf@ambrevar.xyz> 1 sibling, 1 reply; 11+ messages in thread From: Hartmut Goebel @ 2018-12-14 8:35 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Chris Marusich, Ricardo Wurmus, guix-devel, 33600 [-- Attachment #1: Type: text/plain, Size: 773 bytes --] Am 09.12.2018 um 14:58 schrieb Ludovic Courtès: >> I could try and ask a few organizations in my area, but I would need >> figures for this. > What would you need to know? ‘guix weather’ can provide info about > storage size. I don't know yet, which info the admins need for a decision. FMPOV I'd says: Disk-space and traffic to be expected. `guix weather` only provides the disk-space, but even this is not obvious for me: 13912.1 MiB of nars (compressed) 41176.6 MiB on disk (uncompressed) From reading the manual, I assume 13.9 GB are required on the server (which is quite a lot IMHO). Is this correct? -- +++hartmut | Hartmut Goebel | | | hartmut@goebel-consult.de | www.goebel-consult.de | [-- Attachment #2: Type: text/html, Size: 1400 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <87tvjgeb12.fsf@ambrevar.xyz>]
* [bug#33600] Compressing nars with lzip or similar [not found] ` <87tvjgeb12.fsf@ambrevar.xyz> @ 2018-12-14 14:48 ` Ludovic Courtès [not found] ` <878t0sdthe.fsf@ambrevar.xyz> 0 siblings, 1 reply; 11+ messages in thread From: Ludovic Courtès @ 2018-12-14 14:48 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: guix-devel, Hartmut Goebel, 33600 Pierre Neidhardt <mail@ambrevar.xyz> skribis: > Talking about this, I recently discussed with Ludovic the idea of compressing > nars in Lzip instead of gzip. > > http://lzip.nongnu.org/lzip.html (benchmark included) > > I can work on some Lzip guile-bindings, it should be quite easy, then we could > save some 10-50% (!!!) disk usage. That would be sweet! Though we have to keep in mind that today’s ‘guix substitute’ doesn’t know about lzip at all (see (guix scripts substitute) and ‘call-with-decompressed-port’.) So while lzip would be my preference, we may not be able to use it until we can be sure our users can actually unpack it. Ludo’. ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <878t0sdthe.fsf@ambrevar.xyz>]
[parent not found: <87k1kbrnlq.fsf@ambrevar.xyz>]
* [bug#33600] Compressing nars with lzip or similar [not found] ` <87k1kbrnlq.fsf@ambrevar.xyz> @ 2018-12-15 18:06 ` Ludovic Courtès 0 siblings, 0 replies; 11+ messages in thread From: Ludovic Courtès @ 2018-12-15 18:06 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: guix-devel, Hartmut Goebel, 33600 Pierre Neidhardt <mail@ambrevar.xyz> skribis: > I've done some quick research over the various options. > > - lzip: better than gz and bzip2 for sure, possibly better than xz (at > least according to the author). > > - plzip: for "parallel lzip". With 4 threads I was able to compress > icecat 2.5x faster. It used 5x more memory though. The compression > ratio is 1-2% worse. > > - lrzip: it would crash whenever I would change the compression level. > Seems less stable. It's as fast as plzip, while being 1-2% less > compressed. I don't think it's worth using. > > All in all, lzip is a definite win over most options. The main question > is: lzip or plzip? ‘guix publish’ has its own worker pool and handles parallelism internally, so in that context plain sequential lzip would be more appropriate IMO. Ludo’. ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <871s6qzo6m.fsf_-_@gnu.org>]
[parent not found: <87y38tx365.fsf@gmail.com>]
[parent not found: <874lbg76b2.fsf_-_@gnu.org>]
* [bug#33600] guix.gnu.org sub-domain [not found] ` <874lbg76b2.fsf_-_@gnu.org> @ 2018-12-15 23:20 ` Chris Marusich 0 siblings, 0 replies; 11+ messages in thread From: Chris Marusich @ 2018-12-15 23:20 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Hartmut Goebel, Ricardo Wurmus, guix-devel, 33600 [-- Attachment #1: Type: text/plain, Size: 271 bytes --] Hi Ludo, Ludovic Courtès <ludo@gnu.org> writes: > I’m sure Julien wouldn’t mind getting some help or insight, so please do > get in touch! OK, I'll speak privately with Julien about the DNS setup to avoid adding noise to this email thread. -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <878t0thfp9.fsf@roquette.mug.biscuolo.net>]
[parent not found: <874lbfd0sd.fsf@netris.org>]
[parent not found: <87imzpd70s.fsf@roquette.mug.biscuolo.net>]
* [bug#33600] CDN performance [not found] ` <87imzpd70s.fsf@roquette.mug.biscuolo.net> @ 2018-12-21 20:47 ` Marius Bakke 0 siblings, 0 replies; 11+ messages in thread From: Marius Bakke @ 2018-12-21 20:47 UTC (permalink / raw) To: Giovanni Biscuolo, Mark H Weaver; +Cc: guix-devel, 33600 [-- Attachment #1: Type: text/plain, Size: 929 bytes --] Giovanni Biscuolo <g@xelera.eu> writes: > Mark H Weaver <mhw@netris.org> writes: > >> Giovanni Biscuolo <g@xelera.eu> writes: >>> with a solid infrastructure of "scientifically" trustable build farms, >>> there are no reasons not to trust substitutes servers (this implies >>> working towards 100% reproducibility of GuixSD) >> >> What does "scientifically trustable" mean? > > I'm still not able to elaborate on that (working on it, a sort of > self-research-hack project) but I'm referencing to this message related > to reduced bootstrap tarballs: > > https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00347.html > > and the related reply by Jeremiah (unfortunately cannot find it in > archives, Message-ID: <877eh81tm4.fsf@ITSx01.pdp10.guru>) FWIW the GNU list search can take message IDs: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=877eh81tm4.fsf%40ITSx01.pdp10.guru&submit=Search&idxname=guix-devel [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <874lbk63se.fsf@gmail.com>]
[parent not found: <877egdyk82.fsf@gmail.com>]
* [bug#33600] CDN performance [not found] ` <877egdyk82.fsf@gmail.com> @ 2018-12-17 6:48 ` Meiyo Peng [not found] ` <87o99f9o2t.fsf@gmail.com> 0 siblings, 1 reply; 11+ messages in thread From: Meiyo Peng @ 2018-12-17 6:48 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel, 33600 Hi Chris, Chris Marusich <cmmarusich@gmail.com> writes: > Meiyo Peng <meiyo.peng@gmail.com> writes: > >> After careful thought, I realized the new CDN won't benefit China >> residents as planned. Any popular CDN outside China is significantly >> throttled by ISP/GFW and the situation is worse every year. A CDN will >> be a great improvement for western countries but not for many asia >> countries. > > Could you try running the measure_get shell function I included in the > following email? > > https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00192.html > > For convenience, here is the definition: > > measure_get () { > curl -L \ > -o /dev/null \ > -w "url_effective: %{url_effective}\\n\ > http_code: %{http_code}\\n\ > num_connects: %{num_connects}\\n\ > num_redirects: %{num_redirects}\\n\ > remote_ip: %{remote_ip}\\n\ > remote_port: %{remote_port}\\n\ > size_download: %{size_download} B\\n\ > speed_download: %{speed_download} B/s\\n\ > time_appconnect: %{time_appconnect} s\\n\ > time_connect: %{time_connect} s\\n\ > time_namelookup: %{time_namelookup} s\\n\ > time_pretransfer: %{time_pretransfer} s\\n\ > time_redirect: %{time_redirect} s\\n\ > time_starttransfer: %{time_starttransfer} s\\n\ > time_total: %{time_total} s\\n" \ > "$1" > } > > Specifically, I am curious to know what performance you get when you run > > measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 > > from a computer in China. Please be sure to run it two times in a row, > to ensure that CloudFront has cached the object. > > CloudFront has edge locations in Hong Kong, so I am curious to know what > performance improvement, if any, you observe. Sorry for the delay. My computer was reinstalled with Windows and taken away by my girlfriend. So I have been waiting for my new computer that I bought online to arrive. Finally, it arrived yesterday and I successfully installed Guix on it. I tested your script several times. 1. Tested today at home. China Unicom home broadband. 50Mb/s. The result is slow as usual. curl failed once. berlin-mirror.marusich.info is resolved to Seattle, WA, US. #+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 55 66.6M 55 36.9M 0 0 17926 0 1:04:59 0:36:02 0:28:57 17733 url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.151 remote_port: 443 size_download: 38764357 B speed_download: 17926.000 B/s time_appconnect: 6.078850 s time_connect: 3.006821 s time_namelookup: 2.659785 s time_pretransfer: 6.079097 s time_redirect: 0.000000 s time_starttransfer: 9.626001 s time_total: 2162.379211 s curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2) ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 109k 0 0:10:25 0:10:25 --:--:-- 241k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.22 remote_port: 443 size_download: 69899433 B speed_download: 111816.000 B/s time_appconnect: 3.507528 s time_connect: 2.650373 s time_namelookup: 2.261801 s time_pretransfer: 3.507637 s time_redirect: 0.000000 s time_starttransfer: 5.995298 s time_total: 625.129571 s ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 109k 0 0:10:23 0:10:23 --:--:-- 141k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.22 remote_port: 443 size_download: 69899433 B speed_download: 112187.000 B/s time_appconnect: 2.280972 s time_connect: 1.407197 s time_namelookup: 1.056180 s time_pretransfer: 2.281234 s time_redirect: 0.000000 s time_starttransfer: 3.167703 s time_total: 623.061584 s #+END_EXAMPLE 2. Tested 3 days ago at my office. China Telecom enterprise broadband. 50Mb/s. Unusually fast! berlin-mirror.marusich.info is resolved to Seattle, WA, US. I have no idea why it's so fast that day. #+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 1364k 0 0:00:50 0:00:50 --:--:-- 1352k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 13.35.20.109 remote_port: 443 size_download: 69899433 B speed_download: 1397429.000 B/s time_appconnect: 2.432387 s time_connect: 0.200842 s time_namelookup: 0.000446 s time_pretransfer: 2.432659 s time_redirect: 0.000000 s time_starttransfer: 2.673045 s time_total: 50.020945 s ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 1592k 0 0:00:42 0:00:42 --:--:-- 2506k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 13.35.20.109 remote_port: 443 size_download: 69899433 B speed_download: 1630687.000 B/s time_appconnect: 0.653270 s time_connect: 0.209455 s time_namelookup: 0.001582 s time_pretransfer: 0.658399 s time_redirect: 0.000000 s time_starttransfer: 0.883126 s time_total: 42.865868 s #+END_EXAMPLE 3. Tested today at my office. China Telecom enterprise broadband. 50Mb/s. Slow as usual. berlin-mirror.marusich.info is still resolved to Seattle, WA, US. I killed the program several times because it hung there with no data transfer for a few minutes. The TCP connection was probably closed by GFW. This is very common here. #+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 48110 0 0:24:12 0:24:12 --:--:-- 41808 url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.151 remote_port: 443 size_download: 69899433 B speed_download: 48110.000 B/s time_appconnect: 0.872926 s time_connect: 0.282048 s time_namelookup: 0.000524 s time_pretransfer: 0.873099 s time_redirect: 0.000000 s time_starttransfer: 1.187467 s time_total: 1452.904154 s ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 2 66.6M 2 1809k 0 0 5760 0 3:22:15 0:05:21 3:16:54 0^C% ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 52 66.6M 52 34.9M 0 0 16772 0 1:09:27 0:36:26 0:33:01 0^C% ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 58181 0 0:20:01 0:20:01 --:--:-- 87975 url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.22 remote_port: 443 size_download: 69899433 B speed_download: 58181.000 B/s time_appconnect: 2.297713 s time_connect: 1.904176 s time_namelookup: 1.727602 s time_pretransfer: 2.297974 s time_redirect: 0.000000 s time_starttransfer: 2.503263 s time_total: 1201.408929 s #+END_EXAMPLE Well. As you see, the network in China is both slow and unstable. ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <87o99f9o2t.fsf@gmail.com>]
* [bug#33600] CDN performance [not found] ` <87o99f9o2t.fsf@gmail.com> @ 2018-12-21 16:04 ` Meiyo Peng 0 siblings, 0 replies; 11+ messages in thread From: Meiyo Peng @ 2018-12-21 16:04 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel, 33600 Hi Chris, Thank you for your patience! Chris Marusich <cmmarusich@gmail.com> writes: > Can you also share what numbers you get when you run measure_get against > berlin.guixsd.org directly? Clearly, the connection from you to > CloudFront is not as performant as it is for others in other parts of > the world, but I wonder if it's still better than accessing berlin > directly. If you could run measure_get against berlin directly and > share the numbers, we can see if it represents any significant > improvement for you. 1. Tested today at home. China Unicom home broadband. 50Mb/s. berlin.guixsd.org: #+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 54 66.6M 54 36.3M 0 0 14981 0 1:17:45 0:42:25 0:35:20 0 url_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 141.80.181.40 remote_port: 443 size_download: 38141765 B speed_download: 14981.000 B/s time_appconnect: 3.228601 s time_connect: 2.213136 s time_namelookup: 0.856194 s time_pretransfer: 3.228820 s time_redirect: 0.000000 s time_starttransfer: 3.851583 s time_total: 2545.889968 s curl: (56) GnuTLS recv error (-54): Error in the pull function. ➜ ~ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 20415 0 0:57:03 0:57:03 --:--:-- 25983 url_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 141.80.181.40 remote_port: 443 size_download: 69899433 B speed_download: 20415.000 B/s time_appconnect: 2.005881 s time_connect: 0.785257 s time_namelookup: 0.000520 s time_pretransfer: 2.006124 s time_redirect: 0.000000 s time_starttransfer: 3.031582 s time_total: 3423.813489 s #+END_EXAMPLE berlin-mirror.marusich.info: #+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 1470k 0 0:00:46 0:00:46 --:--:-- 2368k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 13.35.20.87 remote_port: 443 size_download: 69899433 B speed_download: 1505934.000 B/s time_appconnect: 3.343496 s time_connect: 3.164926 s time_namelookup: 3.060655 s time_pretransfer: 3.343581 s time_redirect: 0.000000 s time_starttransfer: 5.766543 s time_total: 46.416495 s ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 3182k 0 0:00:21 0:00:21 --:--:-- 4612k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 13.35.20.87 remote_port: 443 size_download: 69899433 B speed_download: 3259170.000 B/s time_appconnect: 0.225982 s time_connect: 0.070428 s time_namelookup: 0.000483 s time_pretransfer: 0.226055 s time_redirect: 0.000000 s time_starttransfer: 0.306621 s time_total: 21.447966 s #+END_EXAMPLE 2. Tested today at my office. China Telecom enterprise broadband. 50Mb/s. berlin.guixsd.org: #+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 3091k 0 0:00:22 0:00:22 --:--:-- 3649k url_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 141.80.181.40 remote_port: 443 size_download: 69899433 B speed_download: 3166021.000 B/s time_appconnect: 3.288213 s time_connect: 2.733554 s time_namelookup: 2.486754 s time_pretransfer: 3.288320 s time_redirect: 0.000000 s time_starttransfer: 3.780341 s time_total: 22.078489 s ➜ ~ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 3499k 0 0:00:19 0:00:19 --:--:-- 4011k url_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 141.80.181.40 remote_port: 443 size_download: 69899433 B speed_download: 3583667.000 B/s time_appconnect: 0.761166 s time_connect: 0.244415 s time_namelookup: 0.000981 s time_pretransfer: 0.761275 s time_redirect: 0.000000 s time_starttransfer: 1.247935 s time_total: 19.505515 s #+END_EXAMPLE berlin-mirror.marusich.info: #+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 49 66.6M 49 32.8M 0 0 19012 0 1:01:16 0:30:13 0:31:03 29265 url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.22 remote_port: 443 size_download: 34488133 B speed_download: 19012.000 B/s time_appconnect: 2.958899 s time_connect: 2.487483 s time_namelookup: 2.271520 s time_pretransfer: 2.959321 s time_redirect: 0.000000 s time_starttransfer: 5.447693 s time_total: 1813.938029 s curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2) #+END_EXAMPLE Although both 13.35.20.0/24 and 52.85.158.0/24 IP ranges are located at Seattle, the result shows that the connection to 13.35.20.0/24 is significantly faster. This is pretty normal in China. It's definitely caused by the GFW. Giant internet service providers (e.g. AWS) are the primary targets of the GFW. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-12-21 20:48 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-12-03 15:43 [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org) Ludovic Courtès 2018-12-03 23:44 ` Mark H Weaver 2018-12-04 5:55 ` [bug#33600] " Ricardo Wurmus [not found] ` <87tvju6145.fsf@gnu.org> [not found] ` <87ftv7l6gy.fsf@gmail.com> [not found] ` <d870d06a-a95c-2b0b-a196-b5166d50400a@goebel-consult.de> [not found] ` <87pnua244k.fsf@gnu.org> 2018-12-11 16:38 ` [bug#33600] Using a CDN or some other mirror? Giovanni Biscuolo 2018-12-14 8:35 ` Hartmut Goebel [not found] ` <87tvjgeb12.fsf@ambrevar.xyz> 2018-12-14 14:48 ` [bug#33600] Compressing nars with lzip or similar Ludovic Courtès [not found] ` <878t0sdthe.fsf@ambrevar.xyz> [not found] ` <87k1kbrnlq.fsf@ambrevar.xyz> 2018-12-15 18:06 ` Ludovic Courtès [not found] ` <871s6qzo6m.fsf_-_@gnu.org> [not found] ` <87y38tx365.fsf@gmail.com> [not found] ` <874lbg76b2.fsf_-_@gnu.org> 2018-12-15 23:20 ` [bug#33600] guix.gnu.org sub-domain Chris Marusich [not found] ` <878t0thfp9.fsf@roquette.mug.biscuolo.net> [not found] ` <874lbfd0sd.fsf@netris.org> [not found] ` <87imzpd70s.fsf@roquette.mug.biscuolo.net> 2018-12-21 20:47 ` [bug#33600] CDN performance Marius Bakke [not found] ` <874lbk63se.fsf@gmail.com> [not found] ` <877egdyk82.fsf@gmail.com> 2018-12-17 6:48 ` Meiyo Peng [not found] ` <87o99f9o2t.fsf@gmail.com> 2018-12-21 16:04 ` Meiyo Peng
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).