Hi Giovanni, Thank you for sharing some data with us!
Giovanni Biscuolo <g...@xelera.eu> 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