On 05/30/2017 05:10 PM, Greg Freemyer wrote:
On Tue, May 30, 2017 at 7:27 PM, Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
On 05/30/2017 03:30 PM, Greg Freemyer wrote:
On Tue, May 30, 2017 at 6:10 PM, Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
On 05/30/2017 11:22 AM, Greg Freemyer wrote:
I happened to look at netstat -in with a large SMB upload ongoing and was surprised to see dropped packets.
I'm on the client that is uploading the data to a Windows fileserver.
They are on receive side which should not have much data in the packets at all. Just ACKs for the data being uploaded:
netstat -in; sleep 120; netstat -in Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 1446805 0 105154 0 10527829 0 0 0 BMRU lo 65536 0 69 0 0 0 69 0 0 0 LRU
Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 1759965 0 105198 0 13887199 0 0 0 BMRU lo 65536 0 69 0 0 0 69 0 0 0 LRU
If you look at the delta over those 2 minutes, it's 44 dropped RX packets out of a little over 300,000 overall received packets.
It's not outrageous, but it caught me off-guard. And I don't often look at the number of dropped packets.
The machines are just a few feet apart and connected to the same 1Gbit switch.
Hi Greg,
That seems a bit high to me too. Do you have another switch to drop into place as a test? Maybe try some different cables too? You might be able to eliminate the switch entirely if your NIC's auto sense. That, or try a cross-over cable?
Regards, Lew
There are 4 computers on the switch and an uplink headed to the Internet connected router in the closet. So bypassing the switch isn't going to fly. Or at least not for long.
I likely have a spare switch I could grab, and plenty of cables. I just didn't want to start troubleshooting a non-existent problem.
I think something's wrong. You seem to be dropping almost 6% of your packets.
For example, here's one of my boxes with an uptime of 52-days
Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg enp5s0f0 1500 0 11758029247 0 0 0 52174553831 0 0 0 BMRU eth0 1500 0 4188629239 0 31 0 12046855552 0 0 0 BMRU lo 65536 0 376527440 0 0 0 376527440 0 0 0 LRU
The enp5s0f0 interface connects to an RFC-1918 private subnet. So the outside eth0 interface has a drop rate of .0000000074, or so. Agreed.
But what does that actually mean. Network gear is store and forward, so I assume a packet checksum is verified at every hop, including the switch that is mounted to my workstation.
And then when a TCP packet gets to my openSUSE 42.2 client the sequence tracker for the TCP packets is checked.
Does a 6% drop rate mean 6% of my packets are dropped due to a bad packet checksum?
Or does it mean 6% of my packets are TCP packets coming in out of order and resends have to be requested?
I think that a failed checksum will give you an RX-ERR. Dropped packets could be caused by the buffers overflowing in the switch or receiving NIC. I think that a rule-of-thumb for drops is they aren't really too significant until they reach 1% of your total packet count. At 6% I'd think that you'd have noticeable performance issues cause by the requirement to re-transmit those dropped packets. Dropped packets aren't out-of-order packets, but they do require retransmits to get the order right. Out-of-order packets wouldn't necessarily cause retransmits, I'd think. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org