From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Using a CDN or some other mirror? Date: Fri, 14 Dec 2018 04:17:50 -0800 Message-ID: <87ftv0xpxt.fsf@gmail.com> References: <20181203154335.10366-1-ludo@gnu.org> <87tvju6145.fsf@gnu.org> <87ftv7l6gy.fsf@gmail.com> <87h8fhhjds.fsf@roquette.mug.biscuolo.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([208.118.235.92]:52471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gXmPp-0007Iw-FW for guix-devel@gnu.org; Fri, 14 Dec 2018 07:18:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gXmPm-00066e-Rc for guix-devel@gnu.org; Fri, 14 Dec 2018 07:18:01 -0500 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]:43333) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gXmPm-00066M-Ka for guix-devel@gnu.org; Fri, 14 Dec 2018 07:17:58 -0500 Received: by mail-pf1-x42e.google.com with SMTP id w73so2761074pfk.10 for ; Fri, 14 Dec 2018 04:17:58 -0800 (PST) In-Reply-To: <87h8fhhjds.fsf@roquette.mug.biscuolo.net> (Giovanni Biscuolo's message of "Thu, 13 Dec 2018 10:21:35 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Giovanni Biscuolo Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Giovanni, Thank you for sharing some data with us! Giovanni Biscuolo 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/1bq783rbkzv9z9zdhivbvfz= hsz2s5yac-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 4= 7.1 > > > > from your mirror (third download): > > url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z= 9zdhivbvfzhsz2s5yac-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 StD= ev > 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. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlwTn24ACgkQ3UCaFdgi Rp2FRQ//frF4lJBzK6+lYIZwFi5a3N/eOvlM9gJlTU5dzpJrKwI8nJ2USaTnyL5j 1g59rDrtu2H0fuLfTX8r0M0b9ndWND38bCXmTxgnCFZ3TF6yRadYF/yRYdQ0yAmV Aty2a8wtwLZ9lkR1xoEOWRpzToiRXfUmDBkCYMt200b0ZLV3tm7qnN/MDzT3vaJp 5YL3GyQq5yfCH/uNLL+Ex2H0UCDF41urcCljGgBV25npVFYXdKijRxnykLXEBd2t 113IKsyaB83pVYijRnAQcnlfuCtu3yt9puDALA9IFrPn8rmp0L7G8LwYBmFchnCT iO57nkAb3Kztgfml4A23Eyr1WsnKZGX2OL5dLgzLNzQw/hvbJDzJpOiariD8jsR+ 8vLYbA1gwEGSi2ixkgICt7Xw2EXgOe9fyMjgNrnrvLaOxrhYGjOP+t/oQ2jKqiEQ uHIKxLtf5TtSALGBvl1C8vTtBYwnqwHRAhoX23Qn+Zy75jNokWBXtP8LqhYbbRTt dHkf7iAz5I4E9uGM02E8OgHSNU7Y7W+x0F3yKg94vJr8DYWp0wOEOyU05/gVhyqJ 6buVRRxkqNmpRcWnw81ObPex08vx2+fxGde2xWcM9kfmdhSV8Pp1p/YTDPMoJmw9 zRQmTT7pZ/8ASRapZVoX0QWAKlKgV8NIpJX3U9BvU/KU2sGE91o= =GK8r -----END PGP SIGNATURE----- --=-=-=--