Re: Laptop exhibits erratic responsiveness
On Mon, Nov 30, 2020 at 01:22:45PM -0800, David Wolfskill wrote: > On Mon, Nov 30, 2020 at 11:03:29PM +0200, Konstantin Belousov wrote: > > ... > > > I suppose I will be commenting out that DIAGNOSTIC option now :-} > > > > Try to just set debug.vmem_check to 0 and see if it helps. > > ... > > OK; I rebooted the new(er) laptop with the previous kernel (that was > built with "option DIAGNOSTIC") and reproduced the issue: > > --- albert.catwhisker.org ping statistics --- > 37 packets transmitted, 37 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.451/13.832/178.867/41.904 ms > > Then: > > g1-216(13.0-C)[2] sudo sysctl debug.vmem_check > Password: > debug.vmem_check: 1 > g1-216(13.0-C)[3] sudo sysctl debug.vmem_check=0 > debug.vmem_check: 1 -> 0 > > On recheck: > > --- albert.catwhisker.org ping statistics --- > 60 packets transmitted, 60 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.411/0.551/1.051/0.084 ms > > which looks pretty good to me. I wanted to change the default some time ago. Do not remember why it did not happen. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Laptop exhibits erratic responsiveness
On Mon, Nov 30, 2020 at 11:03:29PM +0200, Konstantin Belousov wrote: > ... > > I suppose I will be commenting out that DIAGNOSTIC option now :-} > > Try to just set debug.vmem_check to 0 and see if it helps. > ... OK; I rebooted the new(er) laptop with the previous kernel (that was built with "option DIAGNOSTIC") and reproduced the issue: --- albert.catwhisker.org ping statistics --- 37 packets transmitted, 37 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.451/13.832/178.867/41.904 ms Then: g1-216(13.0-C)[2] sudo sysctl debug.vmem_check Password: debug.vmem_check: 1 g1-216(13.0-C)[3] sudo sysctl debug.vmem_check=0 debug.vmem_check: 1 -> 0 On recheck: --- albert.catwhisker.org ping statistics --- 60 packets transmitted, 60 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.411/0.551/1.051/0.084 ms which looks pretty good to me. Thank you, Konstantin! :-) Peace, david -- David H. Wolfskill da...@catwhisker.org There's no point in asking Trump "Sir, have you no decency?" -- it is already well established that neither he nor his enablers have any. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Laptop exhibits erratic responsiveness
On Mon, Nov 30, 2020 at 12:48:47PM -0800, David Wolfskill wrote:
> On Mon, Nov 30, 2020 at 05:21:28AM -0800, David Wolfskill wrote:
> > ...
> > FWIW, the copy of the laptop's "head" kernel config in
> > http://www.catwhisker.org/~david/FreeBSD/head/CANARY is current.
> >
> > And the only difference between the stable/12 config and the head config
> > is:
> >
> > g1-48(12.2-S)[3] diff -u FreeBSD-1{2,3}/CANARY
> > --- FreeBSD-12/CANARY 2019-07-08 10:43:51.940026000 -0700
> > +++ FreeBSD-13/CANARY 2015-03-22 10:03:41.0 -0700
> > @@ -342,7 +342,7 @@
> > # from some parts of the kernel. As this makes everything more noisy,
> > # it is disabled by default.
> > #
> > -# options DIAGNOSTIC
> > +optionsDIAGNOSTIC
> >
> > #
> > # REGRESSION causes optional kernel interfaces necessary only for
> > regression
> >
> > Hmmm... so I suppose that re-disbling DIAGNOSTIC might be a reasonable
> > thing to try, as well, yeah...? :-}
> >
>
> Well, success(ish):
>
> * I was able to reproduce the observed effect using the newer laptop,
> running a kernel from 14 Nov (thus, r367674):
>
> * I was able to reproduce the observed effect using the newer laptop,
> running a kernel from 14 Nov (thus, r367674). (I had cloned the old
> laptop's disk drive and slapped it inito the newer laptop.)
>
> * I then updated the kernel config file ("CANARY") to comment out the
> DIAGNOSTIC option, then rebuilt/installed the kernel.
>
> * Upon reboot, "ping albert" showed remarkably consistent RTTs (compared
> to before) -- e.g., the initial example I posted showed:
>
> --- albert.catwhisker.org ping statistics ---
> 67 packets transmitted, 67 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev =3D 0.428/1024.248/68482.244/8303.513 ms
>
> On the newer laptop after the above change, I saw:
>
> --- albert.catwhisker.org ping statistics ---
> 30 packets transmitted, 30 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.463/0.574/0.671/0.054 ms
>
> Please especially note the maxima & standard deviations.
>
>
> FWIW, I do have (in /boot/loader.conf):
>
> # Try to reduce WITNESS overhead
> vm.debug.divisor=4
>
> (which I also utilize at work).
>
> I suppose I will be commenting out that DIAGNOSTIC option now :-}
Try to just set debug.vmem_check to 0 and see if it helps.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Laptop exhibits erratic responsiveness
On Mon, Nov 30, 2020 at 05:21:28AM -0800, David Wolfskill wrote:
> ...
> FWIW, the copy of the laptop's "head" kernel config in
> http://www.catwhisker.org/~david/FreeBSD/head/CANARY is current.
>
> And the only difference between the stable/12 config and the head config
> is:
>
> g1-48(12.2-S)[3] diff -u FreeBSD-1{2,3}/CANARY
> --- FreeBSD-12/CANARY 2019-07-08 10:43:51.940026000 -0700
> +++ FreeBSD-13/CANARY 2015-03-22 10:03:41.0 -0700
> @@ -342,7 +342,7 @@
> # from some parts of the kernel. As this makes everything more noisy,
> # it is disabled by default.
> #
> -# options DIAGNOSTIC
> +optionsDIAGNOSTIC
>
> #
> # REGRESSION causes optional kernel interfaces necessary only for regression
>
> Hmmm... so I suppose that re-disbling DIAGNOSTIC might be a reasonable
> thing to try, as well, yeah...? :-}
>
Well, success(ish):
* I was able to reproduce the observed effect using the newer laptop,
running a kernel from 14 Nov (thus, r367674):
* I was able to reproduce the observed effect using the newer laptop,
running a kernel from 14 Nov (thus, r367674). (I had cloned the old
laptop's disk drive and slapped it inito the newer laptop.)
* I then updated the kernel config file ("CANARY") to comment out the
DIAGNOSTIC option, then rebuilt/installed the kernel.
* Upon reboot, "ping albert" showed remarkably consistent RTTs (compared
to before) -- e.g., the initial example I posted showed:
--- albert.catwhisker.org ping statistics ---
67 packets transmitted, 67 packets received, 0.0% packet loss
round-trip min/avg/max/stddev =3D 0.428/1024.248/68482.244/8303.513 ms
On the newer laptop after the above change, I saw:
--- albert.catwhisker.org ping statistics ---
30 packets transmitted, 30 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.463/0.574/0.671/0.054 ms
Please especially note the maxima & standard deviations.
FWIW, I do have (in /boot/loader.conf):
# Try to reduce WITNESS overhead
vm.debug.divisor=4
(which I also utilize at work).
I suppose I will be commenting out that DIAGNOSTIC option now :-}
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
There's no point in asking Trump "Sir, have you no decency?" -- it is
already well established that neither he nor his enablers have any.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: Laptop exhibits erratic responsiveness
On Mon, Nov 30, 2020 at 02:10:51PM +0100, Mateusz Guzik wrote:
> ...
> > I definitely do NOT see anything like this running stable/12 (presently
> > at r368181).
> >
> > I will try some experiments with another laptop (a newer one, for which
> > the built-in mouse is detected weirdly, making it annoying to use for me
> > -- but I can still ping from it).
> >
>
> As a sanity check, does the issue manifest itself if you build a
> GENERIC-NODEBUG kernel?
>
> --
> Mateusz Guzik
>
I will try that, but I'm not sure how soon -- I use this laptop whenever
I'm interacting with computers (which is most of the time that I'm
awake). I will see what happens with the newer laptop later today.
FWIW, the copy of the laptop's "head" kernel config in
http://www.catwhisker.org/~david/FreeBSD/head/CANARY is current.
And the only difference between the stable/12 config and the head config
is:
g1-48(12.2-S)[3] diff -u FreeBSD-1{2,3}/CANARY
--- FreeBSD-12/CANARY 2019-07-08 10:43:51.940026000 -0700
+++ FreeBSD-13/CANARY 2015-03-22 10:03:41.0 -0700
@@ -342,7 +342,7 @@
# from some parts of the kernel. As this makes everything more noisy,
# it is disabled by default.
#
-# options DIAGNOSTIC
+optionsDIAGNOSTIC
#
# REGRESSION causes optional kernel interfaces necessary only for regression
Hmmm... so I suppose that re-disbling DIAGNOSTIC might be a reasonable
thing to try, as well, yeah...? :-}
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
There's no point in asking Trump "Sir, have you no decency?" -- it is
already well established that neither he nor his enablers have any.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: Laptop exhibits erratic responsiveness
On 11/30/20, David Wolfskill wrote: > On Sun, Nov 29, 2020 at 03:20:15PM +0100, Mateusz Guzik wrote: >> On 11/29/20, David Wolfskill wrote: >> > On Sat, Nov 28, 2020 at 10:47:57AM -0500, Jonathan Looney wrote: >> >> FWIW, I would try running lockstat on the box. (My supposition is that >> >> the >> >> delay is due to a lock. That could be incorrect. Lockstat may provide >> >> some >> >> clue as to whether this is a line of inquiry worth pursuing.) >> >> >> > >> > Thanks (again), Jonathan. >> > >> > So... I did that (during this morning's daily upgrade cycle); the >> > results may be "of interest" to some. >> ... >> > http://www.catwhisker.org/~david/FreeBSD/head/lockstat/README >> ... >> >> According to the data you got the entire kernel "freezes" every 11-12 >> seconds. So something way off is going on there. >> >> Given that the bug seems to be reproducible I think it would be best >> if you just bisected to the offending commit. >> >> -- >> Mateusz Guzik > > I had thought that the issue arose (as noted in my initial message) > around 09 Nov, which was the day that my daily update on head went from > r367484 to r367517. > > So for my inital attempt at a "before the breakage" kernel (& world), I > "updated" sources to r367444, as I had updated to that revision on 07 > Nov. > > Testing (again, via "ping albert") still showed most RTTs around 0.600 > ms, but (around) every 11th packet, I would see an RTT in the 400 - 650 > ms range -- around a factor of 1000(ish). So while I was not seeing > RTTs in excess of 68 seconds (as I did at least one time for the initial > message), I believe(d) that the underlying issue still existed at > r367444. > > Lather, rinse, repeat -- for: > > * r367484 (from 08 Nov) > * r367243 (from 01 Nov) > * r366312 (from 01 Oct) > * r363759 (from 01 Aug) > > At this point, I was questioning many assumptions, so I cleared /usr/obj > completely and then updated back to r368143... and the issue remained. > > (The laptop was quite busy yesterday.) > > I definitely do NOT see anything like this running stable/12 (presently > at r368181). > > I will try some experiments with another laptop (a newer one, for which > the built-in mouse is detected weirdly, making it annoying to use for me > -- but I can still ping from it). > As a sanity check, does the issue manifest itself if you build a GENERIC-NODEBUG kernel? -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Laptop exhibits erratic responsiveness
On Sun, Nov 29, 2020 at 03:20:15PM +0100, Mateusz Guzik wrote: > On 11/29/20, David Wolfskill wrote: > > On Sat, Nov 28, 2020 at 10:47:57AM -0500, Jonathan Looney wrote: > >> FWIW, I would try running lockstat on the box. (My supposition is that > >> the > >> delay is due to a lock. That could be incorrect. Lockstat may provide > >> some > >> clue as to whether this is a line of inquiry worth pursuing.) > >> > > > > Thanks (again), Jonathan. > > > > So... I did that (during this morning's daily upgrade cycle); the > > results may be "of interest" to some. > ... > > http://www.catwhisker.org/~david/FreeBSD/head/lockstat/README > ... > > According to the data you got the entire kernel "freezes" every 11-12 > seconds. So something way off is going on there. > > Given that the bug seems to be reproducible I think it would be best > if you just bisected to the offending commit. > > -- > Mateusz Guzik I had thought that the issue arose (as noted in my initial message) around 09 Nov, which was the day that my daily update on head went from r367484 to r367517. So for my inital attempt at a "before the breakage" kernel (& world), I "updated" sources to r367444, as I had updated to that revision on 07 Nov. Testing (again, via "ping albert") still showed most RTTs around 0.600 ms, but (around) every 11th packet, I would see an RTT in the 400 - 650 ms range -- around a factor of 1000(ish). So while I was not seeing RTTs in excess of 68 seconds (as I did at least one time for the initial message), I believe(d) that the underlying issue still existed at r367444. Lather, rinse, repeat -- for: * r367484 (from 08 Nov) * r367243 (from 01 Nov) * r366312 (from 01 Oct) * r363759 (from 01 Aug) At this point, I was questioning many assumptions, so I cleared /usr/obj completely and then updated back to r368143... and the issue remained. (The laptop was quite busy yesterday.) I definitely do NOT see anything like this running stable/12 (presently at r368181). I will try some experiments with another laptop (a newer one, for which the built-in mouse is detected weirdly, making it annoying to use for me -- but I can still ping from it). Peace, david -- David H. Wolfskill da...@catwhisker.org "Make America Great Again," he said -- and THIS is what he did??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Laptop exhibits erratic responsiveness
On Sun, Nov 29, 2020 at 08:16:22AM -0800, David Wolfskill wrote: > On Sun, Nov 29, 2020 at 11:04:46AM -0500, Ryan Stone wrote: > ... > > I believe that if you run lockstat with the additional "-x > > destructive" option, it will disable the responsiveness test (the > > option does sound scary but it will not have any other potentially > > destructive effect) > > Thanks; the laptop is presently running head @r368143, building > head @r367410 (which is gthe last point before the issues were > observed, I think), so I have fired that up. > And that attempt completed; the reulting typescript may be found at http://www.catwhisker.org/~david/FreeBSD/head/lockstat/lockstat_head_new Peace, david -- David H. Wolfskill da...@catwhisker.org "Make America Great Again," he said -- and THIS is what he did??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Laptop exhibits erratic responsiveness
On Sun, Nov 29, 2020 at 11:04:46AM -0500, Ryan Stone wrote: > On Sun, Nov 29, 2020 at 9:12 AM David Wolfskill wrote: > > OK, and demonstrated some long RTTs about every 11 packets or so, but we > > see thing come to a screeching halt with: > > > > ... > > 64 bytes from 172.16.8.13: icmp_seq=534 ttl=63 time=0.664 ms > > lockstat: dtrace_status(): Abort due to systemic unresponsiveness > > 64 bytes from 172.16.8.13: icmp_seq=535 ttl=63 time=9404.383 ms > > > > and we get no lockstat output. :-/ > > I believe that if you run lockstat with the additional "-x > destructive" option, it will disable the responsiveness test (the > option does sound scary but it will not have any other potentially > destructive effect) Thanks; the laptop is presently running head @r368143, building head @r367410 (which is gthe last point before the issues were observed, I think), so I have fired that up. Peace, david -- David H. Wolfskill da...@catwhisker.org "Make America Great Again," he said -- and THIS is what he did??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Laptop exhibits erratic responsiveness
On Sun, Nov 29, 2020 at 9:12 AM David Wolfskill wrote: > OK, and demonstrated some long RTTs about every 11 packets or so, but we > see thing come to a screeching halt with: > > ... > 64 bytes from 172.16.8.13: icmp_seq=534 ttl=63 time=0.664 ms > lockstat: dtrace_status(): Abort due to systemic unresponsiveness > 64 bytes from 172.16.8.13: icmp_seq=535 ttl=63 time=9404.383 ms > > and we get no lockstat output. :-/ I believe that if you run lockstat with the additional "-x destructive" option, it will disable the responsiveness test (the option does sound scary but it will not have any other potentially destructive effect) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Laptop exhibits erratic responsiveness
On Sun, Nov 29, 2020 at 03:20:15PM +0100, Mateusz Guzik wrote: > ... > According to the data you got the entire kernel "freezes" every 11-12 > seconds. So something way off is going on there. I'm (quite) prepared to believe that. :-} > Given that the bug seems to be reproducible I think it would be best > if you just bisected to the offending commit. Hmm OK; thanks, Mateusz. > -- > Mateusz Guzik I'll see what I can do. Peace, david -- David H. Wolfskill da...@catwhisker.org "Make America Great Again," he said -- and THIS is what he did??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Laptop exhibits erratic responsiveness
On 11/29/20, David Wolfskill wrote: > On Sat, Nov 28, 2020 at 10:47:57AM -0500, Jonathan Looney wrote: >> FWIW, I would try running lockstat on the box. (My supposition is that >> the >> delay is due to a lock. That could be incorrect. Lockstat may provide >> some >> clue as to whether this is a line of inquiry worth pursuing.) >> > > Thanks (again), Jonathan. > > So... I did that (during this morning's daily upgrade cycle); the > results may be "of interest" to some. > > I have placed copies of the typescripts in: > > http://www.catwhisker.org/~david/FreeBSD/head/lockstat/ > > I also scribbled a "README" in that same directory (though it doesn't > seem to show up in the listing); it may be accessed via > > http://www.catwhisker.org/~david/FreeBSD/head/lockstat/README > > My prior message in this thread showed what I saw during a "ping albert" > from the laptop while it was running head -- most RTTs were around 0.600 > ms, but some were notably longer, with at least one that was over 68 > seconds. > > So I did a "lockstat ping -c 64 albert" while the laptop was running > stable/12@r368123 (as a reference point); it is probably boring. :-} > > Then (this morning), I tried a simple "lockstat sleep 600" on the laptop > while it was running head@r368119 (and building head@r368143); we see > the "lockstat" output in the "lockstat_head" file. > > It then occurred to me that trying a "lockstat ping albert" might be > useful, so I fired up "lockstat ping -c 600 albert" -- which started up > OK, and demonstrated some long RTTs about every 11 packets or so, but we > see thing come to a screeching halt with: > > ... > 64 bytes from 172.16.8.13: icmp_seq=534 ttl=63 time=0.664 ms > lockstat: dtrace_status(): Abort due to systemic unresponsiveness > 64 bytes from 172.16.8.13: icmp_seq=535 ttl=63 time=9404.383 ms > > and we get no lockstat output. :-/ > > > Finally, as another "control," I ran similar commands from freebeast, > while it was running head@r368119 (and building head@r368143). Those > results are in the "lockstat_freebeast" file. > According to the data you got the entire kernel "freezes" every 11-12 seconds. So something way off is going on there. Given that the bug seems to be reproducible I think it would be best if you just bisected to the offending commit. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Laptop exhibits erratic responsiveness
On Sat, Nov 28, 2020 at 10:47:57AM -0500, Jonathan Looney wrote: > FWIW, I would try running lockstat on the box. (My supposition is that the > delay is due to a lock. That could be incorrect. Lockstat may provide some > clue as to whether this is a line of inquiry worth pursuing.) > Thanks (again), Jonathan. So... I did that (during this morning's daily upgrade cycle); the results may be "of interest" to some. I have placed copies of the typescripts in: http://www.catwhisker.org/~david/FreeBSD/head/lockstat/ I also scribbled a "README" in that same directory (though it doesn't seem to show up in the listing); it may be accessed via http://www.catwhisker.org/~david/FreeBSD/head/lockstat/README My prior message in this thread showed what I saw during a "ping albert" from the laptop while it was running head -- most RTTs were around 0.600 ms, but some were notably longer, with at least one that was over 68 seconds. So I did a "lockstat ping -c 64 albert" while the laptop was running stable/12@r368123 (as a reference point); it is probably boring. :-} Then (this morning), I tried a simple "lockstat sleep 600" on the laptop while it was running head@r368119 (and building head@r368143); we see the "lockstat" output in the "lockstat_head" file. It then occurred to me that trying a "lockstat ping albert" might be useful, so I fired up "lockstat ping -c 600 albert" -- which started up OK, and demonstrated some long RTTs about every 11 packets or so, but we see thing come to a screeching halt with: ... 64 bytes from 172.16.8.13: icmp_seq=534 ttl=63 time=0.664 ms lockstat: dtrace_status(): Abort due to systemic unresponsiveness 64 bytes from 172.16.8.13: icmp_seq=535 ttl=63 time=9404.383 ms and we get no lockstat output. :-/ Finally, as another "control," I ran similar commands from freebeast, while it was running head@r368119 (and building head@r368143). Those results are in the "lockstat_freebeast" file. Peace, david -- David H. Wolfskill da...@catwhisker.org "Make America Great Again," he said -- and THIS is what he did??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Laptop exhibits erratic responsiveness
I've delayed trying to send this, as I wasn't clear on how to express it -- and I had hoped that the problem would "go away" before I figured that part out: I first observed it around 09 Nov, which is when I updated the laptop (via in-place source upgrade, as usual) from r367484 to r367517. One of the issues I faced with respect to expressing the nature of the problem was "how to quantify" it. And as I was trying to get some work done on another machine, it ocurred to me that perhaps pinging that other machine might illustrate things adequately, so: g1-48(13.0-C)[17] ping albert PING albert.catwhisker.org (172.16.8.13): 56 data bytes 64 bytes from 172.16.8.13: icmp_seq=0 ttl=63 time=0.511 ms 64 bytes from 172.16.8.13: icmp_seq=1 ttl=63 time=0.667 ms 64 bytes from 172.16.8.13: icmp_seq=2 ttl=63 time=0.537 ms 64 bytes from 172.16.8.13: icmp_seq=3 ttl=63 time=0.618 ms 64 bytes from 172.16.8.13: icmp_seq=4 ttl=63 time=0.647 ms 64 bytes from 172.16.8.13: icmp_seq=5 ttl=63 time=0.538 ms 64 bytes from 172.16.8.13: icmp_seq=6 ttl=63 time=0.538 ms 64 bytes from 172.16.8.13: icmp_seq=7 ttl=63 time=0.543 ms 64 bytes from 172.16.8.13: icmp_seq=8 ttl=63 time=0.571 ms 64 bytes from 172.16.8.13: icmp_seq=9 ttl=63 time=0.500 ms 64 bytes from 172.16.8.13: icmp_seq=10 ttl=63 time=0.618 ms 64 bytes from 172.16.8.13: icmp_seq=11 ttl=63 time=0.548 ms 64 bytes from 172.16.8.13: icmp_seq=12 ttl=63 time=0.532 ms 64 bytes from 172.16.8.13: icmp_seq=13 ttl=63 time=0.532 ms 64 bytes from 172.16.8.13: icmp_seq=14 ttl=63 time=0.613 ms 64 bytes from 172.16.8.13: icmp_seq=15 ttl=63 time=0.593 ms 64 bytes from 172.16.8.13: icmp_seq=16 ttl=63 time=0.501 ms 64 bytes from 172.16.8.13: icmp_seq=17 ttl=63 time=0.630 ms 64 bytes from 172.16.8.13: icmp_seq=18 ttl=63 time=0.556 ms 64 bytes from 172.16.8.13: icmp_seq=19 ttl=63 time=0.566 ms 64 bytes from 172.16.8.13: icmp_seq=20 ttl=63 time=0.642 ms 64 bytes from 172.16.8.13: icmp_seq=21 ttl=63 time=0.611 ms 64 bytes from 172.16.8.13: icmp_seq=22 ttl=63 time=0.628 ms 64 bytes from 172.16.8.13: icmp_seq=23 ttl=63 time=92.473 ms 64 bytes from 172.16.8.13: icmp_seq=24 ttl=63 time=0.647 ms 64 bytes from 172.16.8.13: icmp_seq=25 ttl=63 time=0.483 ms 64 bytes from 172.16.8.13: icmp_seq=26 ttl=63 time=0.476 ms 64 bytes from 172.16.8.13: icmp_seq=27 ttl=63 time=0.561 ms 64 bytes from 172.16.8.13: icmp_seq=28 ttl=63 time=0.560 ms 64 bytes from 172.16.8.13: icmp_seq=29 ttl=63 time=0.599 ms 64 bytes from 172.16.8.13: icmp_seq=30 ttl=63 time=0.677 ms 64 bytes from 172.16.8.13: icmp_seq=31 ttl=63 time=0.563 ms 64 bytes from 172.16.8.13: icmp_seq=32 ttl=63 time=0.609 ms 64 bytes from 172.16.8.13: icmp_seq=33 ttl=63 time=0.558 ms 64 bytes from 172.16.8.13: icmp_seq=34 ttl=63 time=0.527 ms 64 bytes from 172.16.8.13: icmp_seq=35 ttl=63 time=0.610 ms 64 bytes from 172.16.8.13: icmp_seq=36 ttl=63 time=0.621 ms 64 bytes from 172.16.8.13: icmp_seq=37 ttl=63 time=0.501 ms 64 bytes from 172.16.8.13: icmp_seq=38 ttl=63 time=68482.244 ms 64 bytes from 172.16.8.13: icmp_seq=39 ttl=63 time=0.672 ms 64 bytes from 172.16.8.13: icmp_seq=40 ttl=63 time=0.635 ms 64 bytes from 172.16.8.13: icmp_seq=41 ttl=63 time=0.585 ms 64 bytes from 172.16.8.13: icmp_seq=42 ttl=63 time=0.629 ms 64 bytes from 172.16.8.13: icmp_seq=43 ttl=63 time=0.566 ms 64 bytes from 172.16.8.13: icmp_seq=44 ttl=63 time=0.641 ms 64 bytes from 172.16.8.13: icmp_seq=45 ttl=63 time=0.638 ms 64 bytes from 172.16.8.13: icmp_seq=46 ttl=63 time=0.645 ms 64 bytes from 172.16.8.13: icmp_seq=47 ttl=63 time=0.540 ms 64 bytes from 172.16.8.13: icmp_seq=48 ttl=63 time=0.487 ms 64 bytes from 172.16.8.13: icmp_seq=49 ttl=63 time=13.063 ms 64 bytes from 172.16.8.13: icmp_seq=50 ttl=63 time=0.567 ms 64 bytes from 172.16.8.13: icmp_seq=51 ttl=63 time=0.487 ms 64 bytes from 172.16.8.13: icmp_seq=52 ttl=63 time=0.428 ms 64 bytes from 172.16.8.13: icmp_seq=53 ttl=63 time=0.692 ms 64 bytes from 172.16.8.13: icmp_seq=54 ttl=63 time=0.605 ms 64 bytes from 172.16.8.13: icmp_seq=55 ttl=63 time=0.630 ms 64 bytes from 172.16.8.13: icmp_seq=56 ttl=63 time=0.561 ms 64 bytes from 172.16.8.13: icmp_seq=57 ttl=63 time=0.634 ms 64 bytes from 172.16.8.13: icmp_seq=58 ttl=63 time=0.571 ms 64 bytes from 172.16.8.13: icmp_seq=59 ttl=63 time=0.577 ms 64 bytes from 172.16.8.13: icmp_seq=60 ttl=63 time=0.592 ms 64 bytes from 172.16.8.13: icmp_seq=61 ttl=63 time=0.455 ms 64 bytes from 172.16.8.13: icmp_seq=62 ttl=63 time=0.585 ms 64 bytes from 172.16.8.13: icmp_seq=63 ttl=63 time=0.548 ms 64 bytes from 172.16.8.13: icmp_seq=64 ttl=63 time=0.443 ms 64 bytes from 172.16.8.13: icmp_seq=65 ttl=63 time=0.584 ms 64 bytes from 172.16.8.13: icmp_seq=66 ttl=63 time=0.592 ms ^C --- albert.catwhisker.org ping statistics --- 67 packets transmitted, 67 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.428/1024.248/68482.244/8303.513 ms g1-48(13.0-C)[18] Please note that no packets are dropped, and that most exhibit an RTT of around 0.6 ms, and that no packets are dropped -- which is ...
