[PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

[PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

[Ludovic Courtès]

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

Re: [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

[Mark H Weaver]

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

[bug#33600] [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

[Ricardo Wurmus]

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

[bug#33600] Using a CDN or some other mirror?

[Giovanni Biscuolo]

[-- 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 --]

[bug#33600] Using a CDN or some other mirror?

[Hartmut Goebel]

[-- 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 --]

[bug#33600] Compressing nars with lzip or similar

[Ludovic Courtès]

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

[bug#33600] Compressing nars with lzip or similar

[Ludovic Courtès]

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

[bug#33600] guix.gnu.org sub-domain

[Chris Marusich]

[-- 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 --]

[bug#33600] CDN performance

[Meiyo Peng]

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.

[bug#33600] CDN performance

[Meiyo Peng]

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.

[bug#33600] CDN performance

[Marius Bakke]

[-- 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 --]