Re: Using a CDN or some other mirror?

[Chris Marusich]

Hi Giovanni,

Thank you for sharing some data with us!

Giovanni Biscuolo <address@hidden> writes:

> measures from my office network: Italy, 20Km north Milan, FTTC
> (90Mbit/sec measured bandwidth)
>
> measure from Berlin:
>
> 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: 9051388,000 B/s

That's about 72 megabits per second.

>   time_appconnect: 0,229271 s
>   time_connect: 0,110443 s
>   time_namelookup: 0,061754 s

Latency was about 49 milliseconds (after the name lookup).

>   [...]
> latency measured with mtr:
>
> HOST: roquette                  Loss%   Snt   Last   Avg  Best  Wrst StDev
>   1.|-- 10.38.2.1                  0.0%    10    0.3   0.4   0.3   0.4   0.0
>
> [...]
>
>  18.|-- 141.80.181.40              0.0%    10  112.5  77.1  55.6 201.7  47.1
>
>
>
> from your mirror (third download):
>
> 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: 54.230.102.61
>   remote_port: 443
>   size_download: 69899433 B
>   speed_download: 9702091,000 B/s

That's about 78 megabits per second, which is 8% more than 72.

>   time_appconnect: 0,172660 s
>   time_connect: 0,037833 s
>   time_namelookup: 0,003772 s

Latency was 34 milliseconds, which is 31% less than 49.

>   [...]
>
> latency measured with mtr:
>
> HOST: roquette                   Loss%   Snt   Last   Avg  Best  Wrst StDev
>   1.|-- 10.38.2.1                   0.0%    10    0.4   0.4   0.4   0.4   0.0
>
> [...]
>
>  11.|-- ???                        100.0    10    0.0   0.0   0.0   0.0   0.0
>  12.|-- ???                        100.0    10    0.0   0.0   0.0   0.0   0.0
>  13.|-- ???                        100.0    10    0.0   0.0   0.0   0.0   0.0
>  14.|-- ???                        100.0    10    0.0   0.0   0.0   0.0   0.0
>  15.|-- 52.93.58.190                0.0%    10   36.1  34.6  32.9  37.1   1.2
>  16.|-- ???                        100.0    10    0.0   0.0   0.0   0.0   0.0
>
> 100% loss?

Yes, mtr's output here is a bit surprising.

On my end, also, mtr reported similar "loss" for intermediate hops, but
in my case the final hop did not report any loss.  Deprioritization of
ICMP traffic is common in many networks, so tools like mtr and
traceroute will sometimes report surprisingly high latency or packet
loss even when the network is just fine.

The mechanism used by tools like mtr and traceroute is to repeatedly
send "probes" with monotonically increasing TTL values.  The measurement
(even when using TCP probes) relies on (1) intermediate hops correctly
returning an ICMP "time exceeded" message when the packet lands on that
hop and the TTL expires, and (2) the ICMP "time exceeded" message
getting successfully delivered back to the mtr process.

In any case, the "100% loss" metric is clearly inaccurate, since you
successfully downloaded the file at an impressive speed.  If a hop were
truly dropping 100% of the traffic, the download would have failed.  In
addition, the latency that mtr does report seems comparable to the
latency calculated from the measure_get output (which is not influenced
by the vagaries of ICMP deprioritization).

> from here it seems Berlin is as performant as CloudFront

Yes, it seems you are already well connected to the build farm!  But
still, when you used CloudFront, your throughput went up by 7%, and your
latency went down by 31%.  Even more importantly, when you downloaded
the file from CloudFront, it placed zero additional load on the build
farm because it was served from CloudFront's cache.

Again, thank you for sharing!  This is useful information.

-- 
Chris

signature.asc
Description: PGP signature