Hello,

 

using the latest beta I have got a lot of dropped packets on my unRAID server. I already changed the cables. That changed nothing.

 

root@Tower:~# ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.1.43  netmask 255.255.255.0  broadcast 192.168.1.255

        ether bc:5f:f4:5b:62:0f  txqueuelen 1000  (Ethernet)

        RX packets 110009239  bytes 134435075472 (125.2 GiB)

        RX errors 0  dropped 6514  overruns 0  frame 0

        TX packets 106170615  bytes 142142339312 (132.3 GiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

What can I test to find out what's wrong?

 

Bye.

When the system receives unknown or unsupported packets/protocols, it results in packet drops at the ethernet layer, avoiding the need for further processing at higher layers.

 

Dropped packets doesn't mean there is something wrong, and changing cabling or hardware won't change the situation. You may try to find out the source of the "unknown/unsupported" packets and possibly stop it, but then again there is no real need to do that.

 

Thanks. I will see if problems occur during operation (mainly streaming to my popcorn hour). If I discover something like that  I will re-open this thread.

 

BTW: Happy new year.

I also just noticed that I have a lot of dropped packets listed for eth0 receive, is there a way to troubleshoot why or how these packets are getting dropped?

 

I'm only running plex when it comes to plugins.

Packet loss isn't a major problem as long as its not excessive, but if you really want to diagnose it you can check out https://kb.meraki.com/knowledge_base/troubleshooting-packet-loss 

 

On WAN connections (out to the internet), packet loss is going to happen.  Nothing you can do about it.  The internet is way too convoluted to expect 100% perfect transmission of 100% of packets 100% of the time.

 

run ping google.com for a couple of hours and you'll see the odd packet dropped.

 

If LAN packets are being dropped however the odds are most likely either a bad / flakely port on the switch / router or cabling issue.  Ping another computer in your house to see.

 

Cabling you may or may not be able to anything about.  It could be as simple as a bad termination, or a kink in the wire or tie straps too tight (changing the electrical characteristics) (in an ideal world, tie straps are never used on data cables), or running too close to power wires. 

 

Or, lightning could have induced a momentary RF surge and scrambled a packet or two.

 

Net result:  If its not an issue, don't worry about it.  I would far rather have a dropped packet than for a corrupted packet to have been received and not recognized.

 

My ifconfig is currently reporting 4315 dropped packets out of a total of 44707839 for a total loss of 0.00965%, and the computer is constantly downloading.  My other server which only contacts the internet for plugin updates, etc reports a loss of 0.00011%

 

The OP's percentage is 6514 / 110009239 = 0.0059%  Hardly earth shattering.

 

For comparision, for VOIP applications, packet  loss up to 20% is acceptable

Packet loss isn't a major problem as long as its not excessive, but if you really want to diagnose it you can check out https://kb.meraki.com/knowledge_base/troubleshooting-packet-loss 

 

On WAN connections (out to the internet), packet loss is going to happen.  Nothing you can do about it.  The internet is way too convoluted to expect 100% perfect transmission of 100% of packets 100% of the time.

 

run ping google.com for a couple of hours and you'll see the odd packet dropped.

 

If LAN packets are being dropped however the odds are most likely either a bad / flakely port on the switch / router or cabling issue.  Ping another computer in your house to see.

 

Cabling you may or may not be able to anything about.  It could be as simple as a bad termination, or a kink in the wire or tie straps too tight (changing the electrical characteristics) (in an ideal world, tie straps are never used on data cables), or running too close to power wires. 

 

Or, lightning could have induced a momentary RF surge and scrambled a packet or two.

 

Net result:  If its not an issue, don't worry about it.  I would far rather have a dropped packet than for a corrupted packet to have been received and not recognized.

 

My ifconfig is currently reporting 4315 dropped packets out of a total of 44707839 for a total loss of 0.00965%, and the computer is constantly downloading.  My other server which only contacts the internet for plugin updates, etc reports a loss of 0.00011%

 

The OP's percentage is 6514 / 110009239 = 0.0059%  Hardly earth shattering.

 

For comparision, for VOIP applications, packet  loss up to 20% is acceptable

 

Fair enough...

 

I might delve into this a bit more later, right now I'm showing Received: 992427 Drops: 59817 which is 6.02%... slightly higher then I expected... I guess it's not a huge concern. When i pinged Google 20 times I got 0% loss though... i suppose that 20 isn't really a great sample... but I digress.

I might delve into this a bit more later, right now I'm showing Received: 992427 Drops: 59817 which is 6.02%... slightly higher then I expected... I guess it's not a huge concern. When i pinged Google 20 times I got 0% loss though... i suppose that 20 isn't really a great sample... but I digress.

 

6% is a bit high, but if they are only coming through the WAN and not the LAN there may not be anything you can do about it. 

6% is unacceptable. TCP should operate with less than 1% packet loss unless something is wrong with the network. UDP service like VOIP is not relevant unless the server is running a UDP service. This is most likely due to a bad physical connection.

I might delve into this a bit more later, right now I'm showing Received: 992427 Drops: 59817 which is 6.02%... slightly higher then I expected... I guess it's not a huge concern. When i pinged Google 20 times I got 0% loss though... i suppose that 20 isn't really a great sample... but I digress.

 

6% is a bit high, but if they are only coming through the WAN and not the LAN there may not be anything you can do about it.

 

6% is unacceptable. TCP should operate with less than 1% packet loss unless something is wrong with the network. UDP service like VOIP is not relevant unless the server is running a UDP service. This is most likely due to a bad physical connection.

 

Most of my traffic should be within my LAN... I'm only running Plex, and APCUPSD (networked with a windows pc on the same UPS but that's still within the lan...).

 

Oh well, I'm not super worried but I am going to look into this more. It's possible something is configured incorrectly, or there is a bad connection somewhere.

Just want to say I did a bit more digging on this, and it seems that there are a lot of dropped packets early on (after a reboot, maybe I should have mentioned that before, but the earlier numbers were after a reboot) and sense then has been really solid driving the ratio way down.

 

Is there a reason why I would expect a higher percentage of drops early with a lower and lower number as time goes on?

Hi everyone,

i recently started monitoring my server with netdata, and i started getting a lot of messages from the service about packet loss on various virtual interfaces all comming down to eth0

 

# uptime
 15:16:58 up 3 days,  1:53,  1 user,  load average: 1.81, 2.01, 2.15
# ifconfig eth0
eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 3c:7c:3f:7d:42:a0  txqueuelen 1000  (Ethernet)
        RX packets 67059799  bytes 74451288124 (69.3 GiB)
        RX errors 0  dropped 32374  overruns 0  frame 0
        TX packets 49994008  bytes 41492480626 (38.6 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

for my setup eth0 is used for dockers and vms and unraid access, except my pfsense VM running completely on a different separate intel network card.

 

This means that i have a 0,04% of packet loss on my eth0 interface since last reboot for 12 release, which i guess is acceptable, however i would like to get rid of it.

 

Do you have any hints of what could be going wrong here?

 

Thank you in advance.