1 2 Previous Next 15 Replies Latest reply on Feb 6, 2018 7:37 PM by Intel Corporation

    I219-LM UDP Transport Issue

    jgplmco

      We have procured over a dozen NUC6i7KYK (mfg 07/2017) to act as a receiver of a moderate rate (~320Mbps) UDP stream of data. We have found that the I219-LM adapter is dropping packets. We have been able to replicate the issue using the iperf tool. For the application (and for my troubleshooting tests) the NUC will be direct connected to the data source via a new, short (~1m), patch cord.

       

      We have the latest BIOS (KYSKLi70.86A.0050.2017.0831.1924) and we are using Ubuntu 16.04.3. We have also tried Ubuntu 16.04.2 and 17.10. We have tried the distro provided e1000e 3.2.6-k driver as well as the latest e1000e 3.3.6 driver.

      We have set net.core.rmem_max to 33554432 and net.core.wmem_max to 576000.

      We have set coalescence to zero: ethtool -C eno1 rx-usecs 0.

      We have maxed the receive ring buffer: ethtool -G eno1 rx 4096.

      We have ensured max CPU frequency via cpufreq setting it to "performance".

       

      Data loss is non-deterministic and sometimes happens immediately, after several minutes, or several hours. Typically it is a single missing packet. We can not afford any lost data.

       

      I had a ZBOX-CI323NANO with openSuSE 42.3 on it. This low performance device has Realtek RTL8111/8168/8411 PCIe GbE adapters. It received UDP data with zero losses. That's the sort of results I expect from this NUC.

      It has net.core.rmem_max and net.core.wmem_max set to 16777216.


      We also have used a Pluggable USB3.0 GbE adapter. It also runs with no lost data - however, it tends to "go away" after indeterminate periods of time - not sure if that's a NUC, OS, or pluggable issue.

       

      I saw this thread that looks familiar to my problem:UDP packets frozen with at least I219-V, I219-LM and I217-LM

       

      When I run wireshark, occasionally I see the interpacket gap be ~10ms instead of the typical handful of microseconds.

        1 2 Previous Next