Re: Large RTT or Why doesn't my ping traffic get discarded?

[William Herrin <bill () herrin us>]

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/