Extremely slow, don't know where to start

I am experiencing slow / failed rendering of sites in the browser. The browser is saying no internet intermittently – sometimes it connects lightning fast and other times it is dead. You can see this behavior approximately by looking at the output from repeated pings. I just ping www.google.com

root@turris:~ ping www.google.com
PING www.google.com (172.217.16.228) 56(84) bytes of data.
64 bytes from mad08s04-in-f4.1e100.net (172.217.16.228): icmp_req=4 ttl=54 time=1281 ms
64 bytes from mad08s04-in-f4.1e100.net (172.217.16.228): icmp_req=5 ttl=54 time=241 ms
64 bytes from mad08s04-in-f4.1e100.net (172.217.16.228): icmp_req=6 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f4.1e100.net (172.217.16.228): icmp_req=7 ttl=54 time=10.5 ms
64 bytes from mad08s04-in-f4.1e100.net (172.217.16.228): icmp_req=8 ttl=54 time=10.4 ms
64 bytes from mad08s04-in-f4.1e100.net (172.217.16.228): icmp_req=9 ttl=54 time=10.4 ms
64 bytes from mad08s04-in-f4.1e100.net (172.217.16.228): icmp_req=10 ttl=54 time=10.4 ms
64 bytes from mad08s04-in-f4.1e100.net (172.217.16.228): icmp_req=11 ttl=54 time=10.5 ms
^C
--- www.google.com ping statistics ---
11 packets transmitted, 8 received, 27% packet loss, time 10163ms
rtt min/avg/max/mdev = 10.400/198.386/1281.960/416.497 ms, pipe 2
root@turris:~ ping www.google.com
ping: unknown host www.google.com
root@turris:~ ping www.google.com
ping: unknown host www.google.com
root@turris:~ ping www.google.com
PING www.google.com (216.58.201.164) 56(84) bytes of data.
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=1 ttl=54 time=11.8 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=2 ttl=54 time=11.8 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=3 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=4 ttl=54 time=11.2 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=5 ttl=54 time=11.5 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=30 ttl=54 time=1271 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=31 ttl=54 time=241 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=32 ttl=54 time=11.9 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=33 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=34 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=35 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=36 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=37 ttl=54 time=11.3 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=38 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=39 ttl=54 time=11.3 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=64 ttl=54 time=1431 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=65 ttl=54 time=401 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=66 ttl=54 time=11.2 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=67 ttl=54 time=11.6 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=68 ttl=54 time=11.2 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=69 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=70 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=71 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=72 ttl=54 time=11.6 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=73 ttl=54 time=11.1 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=98 ttl=54 time=881 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=99 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=100 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=101 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=102 ttl=54 time=11.3 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=103 ttl=54 time=11.0 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=104 ttl=54 time=11.5 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=105 ttl=54 time=11.4 ms
64 bytes from arn02s06-in-f164.1e100.net (216.58.201.164): icmp_req=106 ttl=54 time=11.2 ms
^C
--- www.google.com ping statistics ---
110 packets transmitted, 34 received, 69% packet loss, time 112227ms
rtt min/avg/max/mdev = 11.047/134.071/1431.039/345.248 ms, pipe 2

I am just letting the ping run for a bit then cancelling it. You can see it hangs about every 8 attempts. There is definitely a pattern. As the ping is running, I can watch htop and everything is well below thresholds in total <10% of cpu is being used and memory nothing too.

Can someone point me to a troubleshooting guide? I am newish to linux, networking and know nothing about OpenWRT

Are ISP problems excluded?

I should add also that when I connect directly to the ISP provided router, I have not problems getting websites. I checked the dns resolution times, and it doesn’t seem to be the problem. When I do a traceroute -I www.google.com I get a major delay in the hops that occur right after the Turris router node is reached.

root@turris:~ traceroute www.google.com
traceroute to www.google.com (172.217.168.164), 30 hops max, 38 byte packets
 1  *  *  *
 2  *  *  *
 3  *  *  *
 4  *  *  *
 5  *  *  173.red-80-58-89.staticip.rima-tde.net (80.58.89.173)  11.002 ms
 6  *  *  *
 7  *  *  google-be4-grcmadno1.net.telefonicaglobalsolutions.com (213.140.50.43)  11.012 ms
 8  *  74.125.242.161 (74.125.242.161)  10.581 ms  *
 9  *  *  *
10  *  108.170.253.232 (108.170.253.232)  1593.243 ms  108.170.253.248 (108.170.253.248)  11.042 ms
11  mad07s10-in-f4.1e100.net (172.217.168.164)  11.131 ms  11.385 ms  74.125.242.161 (74.125.242.161)  10.746 ms
1 Like

Wow, that was fast.
I have confirmed that the ISP network works very well when I connect using their equipment.

Is the Omnia connected behind the ISP router?

Yes the Omnia is on the lan side of the ISP router, which has a fiber channel in. I spent the morning playing around with the settings of the ISP router. I don’t know how to trouble shoot whether the settings on that router are causing some sort of problem for the Omnia. That ISP router appears to just be seeing the Omnia as another device on the network.

Try bridge mode on the ISP router or buy SFP module for Omnia (it may not be supported by the ISP).

1 Like

How does the SFP module help if it’s not supported by the ISP? Really appreciate your answer in advance. Thanks a lot

Seems likely being a DNS issue on the TO. If you leverage several different upstream resolvers try to isolate them one by one and see if one is not working.

You wrote about fiber. Try bridge mode first.

I don’t think so. Above there are cases where only some ping probes are lost in a single series (i.e. cases where the part without DNS fails).

You are the resident expert on kresd, if that app is being leveraged, and knows best in which particular fashion/order multiple upstream nodes being forwarded to, it just seems like a sort of round robin issue where queries forwarded to one upstream node fail but the other are not.

On the other hand time stamps are missing from ping log, e.g. no indication of the intermittent time between the pings series -> which I was wondering about since data for the queried domain should been cached for a certain amount of time.

Nonetheless,

is clearly a DNS issue.

OK, sorry I didn’t notice there were more responses.

I am noticing now that the ping report is not fully capturing the latency that I am seeing. Sometimes, there is a big delay that is not seen in the time=.

I did experiment a little bit with different dns options found in the DNS Forwarder drop down of the admin panel. It didn’t seem to matter, but I will try again.

here’s the output from the dns forward servers. tl;dr slightly different behavior but the same pattern exists. 10 successful pings followed by one or two that take 20 seconds

Exampine: Use forwarding (options)
Disable DNSSEC = False (no check)
Enable DHCP clients in DNS = False (no check)

cz.nic
root@turris:~ ping www.youtube.com
ping: unknown host www.youtube.com
root@turris:~ ping www.youtube.com
PING youtube-ui.l.google.com (172.217.23.206) 56(84) bytes of data.
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=9 ttl=50 time=880 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=10 ttl=50 time=42.5 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=11 ttl=50 time=43.0 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=12 ttl=50 time=43.0 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=13 ttl=50 time=42.7 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=14 ttl=50 time=42.8 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=15 ttl=50 time=42.8 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=16 ttl=50 time=42.8 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=17 ttl=50 time=42.9 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=45 ttl=50 time=2650 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=46 ttl=50 time=1610 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=47 ttl=50 time=570 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=48 ttl=50 time=42.7 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=49 ttl=50 time=42.6 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=50 ttl=50 time=42.8 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=51 ttl=50 time=42.9 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=52 ttl=50 time=42.8 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=53 ttl=50 time=42.8 ms
64 bytes from prg03s05-in-f206.1e100.net (172.217.23.206): icmp_req=54 ttl=50 time=42.8 ms
^C
--- youtube-ui.l.google.com ping statistics ---
54 packets transmitted, 19 received, 64% packet loss, time 54489ms
rtt min/avg/max/mdev = 42.594/334.477/2650.450/673.621 ms, pipe 3

cloudflare
root@turris:~ ping www.youtube.com
PING youtube-ui.l.google.com (172.217.16.238) 56(84) bytes of data.
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=30 ttl=54 time=1920 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=31 ttl=54 time=880 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=32 ttl=54 time=10.6 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=33 ttl=54 time=11.4 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=34 ttl=54 time=11.6 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=35 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=36 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=37 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=38 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=39 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=67 ttl=54 time=1910 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=68 ttl=54 time=880 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=69 ttl=54 time=11.4 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=70 ttl=54 time=10.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=71 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=72 ttl=54 time=12.0 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=73 ttl=54 time=11.6 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=74 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=75 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=76 ttl=54 time=11.1 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=119 ttl=54 time=11.1 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=120 ttl=54 time=10.6 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=121 ttl=54 time=10.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=122 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=123 ttl=54 time=10.6 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=124 ttl=54 time=10.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=125 ttl=54 time=10.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=126 ttl=54 time=10.9 ms
^C
--- youtube-ui.l.google.com ping statistics ---
134 packets transmitted, 28 received, 79% packet loss, time 137381ms
rtt min/avg/max/mdev = 10.636/209.105/1920.402/523.241 ms, pipe 2

google
root@turris:~ ping www.youtube.com
PING youtube-ui.l.google.com (172.217.16.238) 56(84) bytes of data.
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=5 ttl=54 time=2560 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=6 ttl=54 time=1510 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=7 ttl=54 time=471 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=8 ttl=54 time=10.9 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=9 ttl=54 time=10.6 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=10 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=11 ttl=54 time=10.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=12 ttl=54 time=10.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=13 ttl=54 time=11.6 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=14 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=15 ttl=54 time=10.6 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=55 ttl=54 time=2960 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=56 ttl=54 time=1920 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=57 ttl=54 time=880 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=58 ttl=54 time=11.0 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=59 ttl=54 time=10.9 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=60 ttl=54 time=10.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=61 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=62 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=63 ttl=54 time=10.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=64 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=65 ttl=54 time=10.6 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=99 ttl=54 time=880 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=100 ttl=54 time=10.6 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=101 ttl=54 time=11.3 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=102 ttl=54 time=10.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=103 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=104 ttl=54 time=11.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=105 ttl=54 time=10.7 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=106 ttl=54 time=10.8 ms
64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_req=107 ttl=54 time=10.7 ms
^C
--- youtube-ui.l.google.com ping statistics ---
108 packets transmitted, 31 received, 71% packet loss, time 110264ms
rtt min/avg/max/mdev = 10.629/369.235/2960.455/779.642 ms, pipe 3

quad9
root@turris:~ ping www.youtube.com
ping: unknown host www.youtube.com
root@turris:~ ping www.youtube.com
PING youtube-ui.l.google.com (172.217.16.142) 56(84) bytes of data.
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=1 ttl=52 time=36.3 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=2 ttl=52 time=36.4 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=3 ttl=52 time=36.7 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=4 ttl=52 time=36.7 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=38 ttl=52 time=36.0 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=39 ttl=52 time=36.8 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=40 ttl=52 time=36.9 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=41 ttl=52 time=36.7 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=42 ttl=52 time=36.6 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=43 ttl=52 time=36.8 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=44 ttl=52 time=36.5 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=45 ttl=52 time=36.9 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=73 ttl=52 time=2880 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=74 ttl=52 time=1840 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=75 ttl=52 time=800 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=76 ttl=52 time=36.0 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=77 ttl=52 time=37.0 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=78 ttl=52 time=36.7 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=79 ttl=52 time=36.8 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=80 ttl=52 time=36.8 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=81 ttl=52 time=36.7 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=82 ttl=52 time=36.8 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=83 ttl=52 time=36.8 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=111 ttl=52 time=2790 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=112 ttl=52 time=1750 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=113 ttl=52 time=720 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=114 ttl=52 time=36.4 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=115 ttl=52 time=37.0 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=116 ttl=52 time=36.8 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=117 ttl=52 time=36.6 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=118 ttl=52 time=36.8 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=119 ttl=52 time=36.8 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=120 ttl=52 time=36.8 ms
64 bytes from zrh04s06-in-f142.1e100.net (172.217.16.142): icmp_req=121 ttl=52 time=36.3 ms
^C
--- youtube-ui.l.google.com ping statistics ---
126 packets transmitted, 34 received, 73% packet loss, time 128788ms
rtt min/avg/max/mdev = 36.073/347.423/2880.546/759.918 ms, pipe 3

As I look at it, it appears possible that some of those pings that appear to be fast but are slow in reality are incrementing the icmp_req parameter a bunch of times.

I believe that the ping command only resolves address(es) once at the beginning and then doesn’t use DNS anymore.

Yes, DNS failed in that case, but when network on IP layer has problems, DNS typically also has problems (except for fully cached answers).

Holes in the icmp_req counter mean packet loss (i.e. no reply within reasonable time). You can see that in the summary, too.

1 Like

I am new to this. I only ever used ping before to check if I have connectivity, never to do any diagnostic analysis.

What is unexpected is that the timer sometimes doesn’t reflect the network latency caused by packet loss, other times it seems to. The only way I am observing some of the latency is by watching the ping output and seeing a lag.

That was my point


a more comprehensible tool might be mtr

Bridge mode is solution.

1 Like

I am looking into how to do that on my ISP router, and I will report back.