Dropped RX packets - RPi 1, 2, and 3 #1954
Comments
|
Any relevant messages in syslog? Also, any ideas when this problems started to occur? |
JamesH65
added
Waiting for external input
JamesH65
removed
the
Waiting for external input
|
A quick glance and some minor debugging at the driver level seems to indicate that it is not the driver itself that is dropping the packet - the code that increments the rx_dropped counter is not called. So presumably somewhere else in the stack is deciding to drop the packet. I'm not sure how to find out where in the stack though! Will investigate further. |
|
It's quite possible this is harmless. The dropped packet count is not only used for errors, but also flagging up packets that are dropped because the linux stack doesn't handle them (some IPv6 stuff if you don't have IPv6 enabled for example). This might be one of those messages. I will try and find out which it is. |
|
It's not IPv6 related as first thing I usually do after installation is
disabling IPv6 on all interfaces via sysctl.conf kernel parameter.
Is it harmless? You never really know, dropped packets shouldn't be there
for sure.
19.05.2017. 17.11, "James Hughes" <notifications@github.com> је написао/ла:
… It's quite possible this is harmless. The dropped packet count is not only
used for errors, but also flagging up packets that are dropped because the
linux stack doesn't handle them (some IPv6 stuff if you don't have IPv6
enabled for example). This might be one of those messages. I will try and
find out which it is.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1954 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMNhf-Eu7da9v0nABpFCHCfdfwgiJGI5ks5r7bEhgaJpZM4M33E8>
.
|
|
OK, not IPv6, but that was only given as an example of some packets that are simply discarded by the network stack. Dropped packets are not, necessarily, an error. If the stack gets a correctly formatted packet it doesn't implement, then it is dropped. It's not an error as such. So it is perfectly reasonable to be getting dropped packets and not worry about them. However, in this case I would like to know whether this is the case here. |
|
Here is some (probably quite old) text on why a packet may be dropped. Also worth noting that even if IPv6 is disable on the Pi, it could still receive IPv6 packets from other devices on the network, which will cause dropped packets
|
|
After much faffing, I have build a utility I found called dropwatch, rebuilt the kernel to turn on a particular form of net logging and now have a list of addresses where packets are being dropped. However, cross references those addresses to the kernel isn't giving valid results, so i suspect all the drops are in modules. What is worth noting is that the ifconfig dropped packets counter is a small subset of the actual number of packets dropped. I can see which address in my list is causing the ifconfigs drops, just need to figure out what code corresponds to that location. |
|
OK, thanks to a timely intervention from @pelwell I do have some idea of the code that is dropping the packets. The ifconfig dropped packet counter appears to be incremented in the __netif_receive_skb_core function, approx line 4214. Still some effort required in backtracking from there to determine the reason for the dropped packets. |
|
I also see these these drops on my pi3
If you need more infos feel free to ask ! |
|
@JamesH65 so we can conclude issue is located in the kernel core? On some cloud providers I also experience dropped packets in RX line. |
|
I don't think any conclusion can be made since I don't yet know the cause of the dropped packets - it could be entirely benign. I think everyone sees the dropped packets on the Pi, I certainly have been seeing them for years, but ignored then. |
|
Well, it started to happen only after kernel/firmware update year ago or so. On this version I have zero dropped packets: Heh, it might be that this old version has a bug of not incrementing counter 😆 |
|
Or newer version added more places where the counter could be incremented... |
|
stamster, can you identify the exact update which caused this. See: If you click on each commit the end of the url contains a git hash. Run (I suspect it will be one of the major bumps - e.g. the first 4.4 kernel) |
|
I've been super busy recently - I'll try to experiment with down-grades this weekend. |
|
I was doing some testing today with the latest Raspbian release, 5GB of data transferred with no dropped packets. This was on ethernet. If doing testing check the latest release first. |
|
Well, I got that kernel 5 days ago and still there were dropped packets. Let's see... |
|
Let me add my stats: RX drop was about 4% with unpatched rasbian-jessie. |
|
I still have drops, even with latest kernel.
|
|
Hmm, just been doing some testing on this, not seeing dropped packets on the ethernet at all. It is possible that this is environmental? |
|
A similar issue has just come up on the linux networking list, unrelated to Pi. Suggestion is RX queueing problem. I'm not sure how to go further here, since I cannot see any dropped packets on the ethernet connection at all. This is a continuation of the previous stats, after leaving it over the weekend, not though with anything hammering the connection. |
|
@stamster Could you give me some idea of how your network is set up? Since I (nd others) am seeing no errors on the onboard Ethernet at all, it would be interesting to know if you have some odd setup that might be causing an issue. |
JamesH65
added
the
Waiting for external input
|
ping @stamster Are you still seeing this? If so are there any strange things on your network that might have some effect. Also, I'm currently using Stretch with a 4.13 kernel and seeing no drops. It would be interesting, if you have the ability to build your own kernel and install it, to see if you still see errors with the latest kernel code. |
|
I tested with over 10GB of data sent back and forth with no dropped packets at all. This is on Stretch with a 4.13 kernel (admittedly not yet a release kernel, but will be released eventually). I'm inclined, unless I hear otherwise to close this issue. |
|
Ah, forgot was using Jessie. sudo apt dist-upgrade instead? |
|
Go straight to 4.14 with |
|
Is there a way to setup a local rpi-update repository as i need to update units inside a very restricted network? |
|
You mean only for kernel? What about core packages (apt)? |
|
Thank you! We got a limited time window with open network ;) |
|
Are people still seeing overly high dropped packet counts with the latest Raspbian? Or even with rpi-update kernel (4.14.50) if you fancy trying it out? |
|
+1 getting drops on
|
|
Hmm. No idea what this is. Out of 4M packets sent in a currently running test, I see 7 dropped packets. I can only think its environmental. Bad cable somewhere? Bad router? Interference? |
|
In the same room I have another RPi mentioned earlier, which is unaffected. Same switch used. The only difference I see is the kernel / firmware version (latest vs. older kernel) - e.g. software layer brings this issue. As a matter of fact, SSH connections are stable 100%, but it's TCP layer to polish things behind the scenes I guess. So no issues I can think of - only that RX dropped counter is increasing constantly. |
|
Can you put both rpi’s one on top of eachother... to check if there is some
interference of other wifi’s on one or other... or mybe none at some point
Dne pon., 2. jul. 2018 ob 23:51 je Jonathan Aaron Steel <
notifications@github.com> napisal/-a:
In the same room I have another RPi mentioned earlier, which is
unaffected. Same switch used. The only difference I see is the kernel /
firmware version (latest vs. older kernel).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1954 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKj8_52d7S1Qt4-xqqkO0FdtBl-Sdk93ks5uCpXfgaJpZM4M33E8>
.
--
*Alen Lončarič *
------------------------------------------------------------------------------------------------------------------------------------------------------
*Avera d.o.o.* ● Pristava pri Mestinju 23 ● 3253 Pristava pri Mestinju
● Slovenia
*e: *alen.loncaric@avera.si ● *g**: *+386 40 818 861 ● *www**: *
www.avera.si
------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
Would it be possible to measure throughput on the two Pi's? It would be interesting to know if the one showing dropped packets is actually slower. |
|
I have recently discovered that Raspbian Stretch has a bug which very, very infrequently causes ethernet packets to be dropped. By running 'sudo rpi-update' on my Pi 3b, which upgraded the kernel from 4.7 to 4.14, I have completely eliminated the 2-5 per day kiwirecorder.py restarts from which I was previously suffering. Running 4.14, my WSPR decoding script 'kiwiwspr.sh' can simultaneously record 17 uncompressed audio streams (3.5 Mbps = 750 receive packets per second ) from 3 Kiwis on one Pi without a single restart in 24 hours. |
|
I'm running the latest kernel (4.19.42-v7+) on a 3B and I see 7-15% packets dropped on ping. Transfer speeds are affected by this, too. In my particular case it's on AP mode and wlan0 bridged with eth0. There are no losses when pinging the ethernet side. |
|
Samie issue here with RPI3 and RPI4. |
|
I have seen discussions elsewhere that seemed to indicate that the ethernet connection is the most power hungry, and low power or inconsistent power to the RPi results in RX errors as the most obvious symptom. You may want to verify that the correct power is being supplied. |
|
[ Unconstructive diversion deleted - I don't want to lock this thread ] |
|
You may as well lock it since you're not addressing the issue anyway. That's how things work around here... |
|
No, it really isn't how things work around here. If we close the issue, we no longer have it visible, so it gets forgotten and will never get fixed. Right now, it's visible, and when time allows someone will look at it. However, we are a tiny team, with a lot to do, and since this only reduces bandwidth, rather than killing anything completely, it's lower priority than many other issues. |
|
Not having a reliable way to reproduce an issue also makes it incredibly hard to work on. Reports of it being seen on a Pi4 make it even stranger as Pi3B+ and Pi4 have a totally different ethernet interfaces to Pi1/2/3B, which makes it seem more systemic than just the ethernet chip driver. Pi4 is over a totally different interface too (inbuilt as opposed to USB). |
|
@6by9 |
|
I have this issue with RX dropped packets on all of my Ubuntu 20.04 LTS Server on Raspberry Pi 4 8GB model as you can see below: Are there any workarounds or fixes planned? |
Hello,
I have multiple RPi's running on two locations. I noticed that each of them report dropped packets, but only in RX direction.
RPi 3:
RPi 2:
Just rebooted after latest rpi-firmware patch, and only 4 mins of uptime getting:
RX packets:689 errors:0 dropped:5 overruns:0 frame:0RPi 1 model B:
RX packets:647 errors:0 dropped:28 overruns:0 frame:0RPi 1:
RX packets:209844 errors:0 dropped:14892 overruns:0 frame:0The only single RPi which does not seem to be affected by this issue is another RPi 1 model B, where I didn't upgraded firmware.
So if it's a firmware related issue, the last known good firmware/kernel w/o RX drops is this one:
10 days uptime, and not a single drop:
RPi's behave exactly the same on other networks, so it's not LAN related, since other PC's and devices do not have any drops with uptime of 250 days.
The text was updated successfully, but these errors were encountered: