my issue seems to be related to , but in my case, small TCP packets get lost every couple of seconds.
In my case, a DELL Latitude E6520 notebook communicates with a WAGO I/O-System device via Modbus TCP at a "high" rate of small packets (TCP_NODELAY), i. e. around 1000 packets per second (9.58 % of size 66 byte on wire, 90.42 % of size 117 or 119 byte on wire according to Wireshark).
Every couple of seconds, it happens that a reply of the WAGO device doesn't appear on the notebook, causing a delay of magnitude 3 compared to the normal packet exchange, which severely impacts the hardware controlled by the WAGO device.
Notebook and WAGO device are connected by a D-Link DGS-1210-16 switch. Activating port mirroring on the notebook port and running Wireshark on an different PC connected to the mirror port reveals, that the reply of the WAGO device is actually sent to the notebook, but the notebook doesn't see it and therefore the TCP stack on the notebook requests a retransmission after a delay of about 1 second.
I currently work around this issue by mirroring the sent packets of the WAGO device to the notebook port on the switch.
The notebook is running with current BIOS and is connected to the mains. Recent Intel network drivers are installed, using default settings. Diagnostics doesn't reveal anything bad.
What can I further do, to get that issue fixed?
Thanks in advance. Bye.
I did some further investigation. Running
netstat -e 3
showed that every couple of seconds, the number of received packets in category dropped and error increased slightly.
Searching for DGS-1210 and 82579LM yields a D-Link document which states a known problem during auto negotiation with hardware revision B of DGS-1210 (mine is revision A) and that NIC, which can be solved by disabling power saving (i. e. EEE) on the switch.
So I disabled power saving on the switch and as a result, netstat stopped increasing the number of packets in category error and dropped. Finally, I've also disabled EEE on the NIC as suggested in the other thread (which on its own didn't solve the issue yesterday).
The system seems to have no frames dropped during the past 5 hours.