Ping blip every 60 seconds on Pi2

[SteveDee]

I'm more curious than bothered about this ping problem;

I did a fresh install of Jessie (full version) on a Pi2 this morning, then updated/graded.

All seemed well, but while running ping I noticed that every 60th ping was long (typically 1800ms) followed by a shorter one (say 800ms) then ping times returned to normal (just a few ms) for the next 58 pings.

When I replace the Edimax AC600 dongle with an Edimax EW-7811Un I get the same effect, but the blip is typically 800ms with no real secondary tremor.

A second Pi2 is running an up-to-date OS, but this has been updated over time, and does not have this problem.

Running uname -a gives the same on both systems:-
4.4.12-v7+ #892 smp Thu Jun 2 15:41:19 BST 2016

When I swap the uSD between systems, the problem follows the uSD.

I guess I have differences in config files, so that will be my next step, but I thought I'd share this quirk with you anyway.

[MarkHaysHarris777]

What makes you think this is a problem?

[stderr]

All seemed well, but while running ping I noticed that every 60th ping was long (typically 1800ms) followed by a shorter one (say 800ms) then ping times returned to normal (just a few ms) for the next 58 pings.

Have you checked to see if there is a pause in your ability to send and receive data? What happens if you flood ping one way and then the other?

[SteveDee]

What makes you think this is a problem?

I don't know that it is, but it is not "usual".

Having just reached the end of our bird box (nesting) season, I thought I'd make a start on next years design while I'm still eager and keen. Fundamentally, I need a good, solid (wifi) network. So that's why I'm investigation this blip.

If I cant find a solution, I'll probably just clone the working image.

[SteveDee]

...What happens if you flood ping one way and then the other?

I don't really understand what you are saying, but I think it involves a command like this:-
sudo ping -f 192.168.0.1

I don't know how to interpret the results, but I'll look for some info on the net and give it a try.

That aside, I did check along the way:-
(i) loop-back ping: this didn't exhibit the problem
(ii) ping in and out (between to Pi2 boards): only pinging out was a problem from the new image uSD.
(iii) final testing just involved pinging the router (192.168.0.1)

And I keep coming back to the fact that the hardware is the same in both cases, so it must be a software/config issue.

Although the two uSD cards are upgraded to the same level, there are differences in several files including cmdline.txt, config.txt, interfaces and wpa_supplicant.conf.

And the new build has an empty /boot folder, which I guess is now populated when the Pi boots.

[stderr]

...What happens if you flood ping one way and then the other?

I don't really understand what you are saying, but I think it involves a command like this:-
sudo ping -f 192.168.0.1
I don't know how to interpret the results,

It's a good way to see if you are losing data or having slow downs. It prints a . when it sends out a ping and it erases a . when it gets one back. So if you start seeing a lot of dots, you are sending out pings but not getting all of them back in a timely manner. I wondered if every 60 seconds, say, there was suddenly a bunch of . showing up, which I think is what should happen if every 60 seconds your pings get a lot of latency. It doesn't explain why, of course.

[MarkHaysHarris777]

What makes you think this is a problem?

I don't know that it is, but it is not "usual".

Its pretty usual. Well, usually the 'blip' as you call it isn't like clockwork every 60 seconds, but here's the deal... some sites (machines) block ICMP traffic period; you can't ping them at all ! Some machines will periodically buffer a ping (or hold it for a while, for various reasons) some machines (or network components) will drop packets and you'll never see the response from those ever. Ping is not consistent, and ping is not reliable (that is, not reliable for throughput) and ping results will vary wildly depending on circumstances. I would not make decisions about my network based on just PING. You'll want other tools in place before you suspect you have a problem... netstat, traceroute, ping flood (you must be root, and don't do it on the open network or your work network, it make admins grumpy)... and others.

You have a ping anomaly, but not a problem.

[SteveDee]

...Ping is not consistent, and ping is not reliable...You have a ping anomaly, but not a problem.

Thanks Marcus, I basically agree with your comments. Ultimately I will be testing the system when streaming video, but for the moment I see an anomaly/issue/problem worthy of investigation.

It is perfectly normal to see random variations in ping times.That is why the ping summary shows the average and range of values. Variations are usually random and spread over a range. So I think there are two characteristics of my anomaly which make it interesting:-

Code: Select all

64 bytes from 192.168.0.1: icmp_seq=235 ttl=64 time=15.1 ms
64 bytes from 192.168.0.1: icmp_seq=236 ttl=64 time=5.41 ms
64 bytes from 192.168.0.1: icmp_seq=237 ttl=64 time=1.53 ms
64 bytes from 192.168.0.1: icmp_seq=238 ttl=64 time=1.58 ms
64 bytes from 192.168.0.1: icmp_seq=239 ttl=64 time=12.0 ms
64 bytes from 192.168.0.1: icmp_seq=240 ttl=64 time=4.32 ms
64 bytes from 192.168.0.1: icmp_seq=241 ttl=64 time=1.48 ms
64 bytes from 192.168.0.1: icmp_seq=242 ttl=64 time=3.39 ms
64 bytes from 192.168.0.1: icmp_seq=243 ttl=64 time=1.49 ms
64 bytes from 192.168.0.1: icmp_seq=244 ttl=64 time=2.03 ms
64 bytes from 192.168.0.1: icmp_seq=245 ttl=64 time=1.91 ms
64 bytes from 192.168.0.1: icmp_seq=246 ttl=64 time=1.44 ms
64 bytes from 192.168.0.1: icmp_seq=247 ttl=64 time=5.48 ms
64 bytes from 192.168.0.1: icmp_seq=248 ttl=64 time=1592 ms
64 bytes from 192.168.0.1: icmp_seq=249 ttl=64 time=588 ms
64 bytes from 192.168.0.1: icmp_seq=250 ttl=64 time=9.85 ms
64 bytes from 192.168.0.1: icmp_seq=251 ttl=64 time=1.38 ms
64 bytes from 192.168.0.1: icmp_seq=252 ttl=64 time=6.70 ms
64 bytes from 192.168.0.1: icmp_seq=253 ttl=64 time=1.44 ms
^C
--- 192.168.0.1 ping statistics ---
253 packets transmitted, 253 received, 0% packet loss, time 252410ms
rtt min/avg/max/mdev = 1.376/54.648/1859.892/262.102 ms, pipe 2

First of all, the blip is typically 100 times larger than the basic, random high value (e.g. in the data above; 15.1ms >> 1592ms). And secondly the blip occurs like clockwork, which makes me think that the Pi is saying "hang on a moment, I've just got to do something real important, a task that needs doing every 60s".

As mentioned in my first post, it looks like you may only see this anomaly with a fresh install using the latest download. I understand there has been a lot of work on Raspbian Jessie recently to get the on-board wifi/bluetooth to work properly, and one of the reasons for sharing this is that I wondered whether there was still more work needed in this area.

But hey! if its only me that has noticed it, no worries.

I'll be sure to report back here if I find anything significant. Thanks once again for your input.

[SteveDee]

A few final observations on this, in case it helps anyone.

I have 3 uSD cards containing Raspbian: 4.4.12-v7+ #892 smp Thu Jun 2 15:41:19 BST 2016

The image on two of these uSD include dhcpcd. These have the ping-blip problem when used in a Pi-2 or Pi-3 with Edimax wifi dongles (EW-7811Un or AC600).
Using the Pi-3 with internal wifi does not show ping-blip problem.
Having run ping-blip image for longer periods, I now notice that it is prone to randomly drop network connection, and when it does, dhcpcdui reports "No APs found - scanning" and I need a re-boot to fix it.

The uSD without dhcpcd (which has gradually been updated/graded to the current version) runs as sweet as a nut, so that's the one I'll be using for a while.