On Wed, Dec 21, 2022 at 1:20 PM Dave Taht <dave.taht@gmail.com> wrote:
On Wed, Dec 21, 2022 at 11:58 AM William Herrin <bill@herrin.us> wrote:
On Wed, Dec 21, 2022 at 9:10 AM Jason Iannone <jason.iannone@gmail.com> wrote:
Here's a question I haven't bothered to ask until now. Can someone please help me understand why I receive a ping reply after almost 5 seconds?
64 bytes from 4.2.2.2: icmp_seq=398 ttl=54 time=4915.096 ms 64 bytes from 4.2.2.2: icmp_seq=399 ttl=54 time=4310.575 ms 64 bytes from 4.2.2.2: icmp_seq=400 ttl=54 time=4196.075 ms 64 bytes from 4.2.2.2: icmp_seq=401 ttl=54 time=4287.048 ms 64 bytes from 4.2.2.2: icmp_seq=403 ttl=54 time=2280.466 ms 64 bytes from 4.2.2.2: icmp_seq=404 ttl=54 time=1279.348 ms 64 bytes from 4.2.2.2: icmp_seq=405 ttl=54 time=276.669 ms
Hi Jason,
This usually means a problem on the Linux machine originating the packet. It has lost the ARP for the next hop or something similar so the outbound ICMP packet is queued. The glitch repairs itself, briefly, releasing the queued packets. Then it comes right back.
There's this thing called bufferbloat...
Hi Dave, Yes, but I've seen this particular pattern before and it's generally not bufferbloat. With bufferbloat you usually see consistent long ping times: this ping is 3 seconds, the next ping is 2.9, the next is 3.2. This example had a descending pattern spread exactly the number of seconds apart that the ICMP message was sent. The descending pattern indicates something went wrong with arp, or a virtual machine was starved for CPU time and didn't run for a couple seconds, or something like that. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/