On Wed, Dec 21, 2022 at 1:20 PM Dave Taht <dave.t...@gmail.com> wrote: > On Wed, Dec 21, 2022 at 11:58 AM William Herrin <b...@herrin.us> wrote: > > On Wed, Dec 21, 2022 at 9:10 AM Jason Iannone <jason.iann...@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/