Installing Linuxcnc and Debian Bookworm on problematic hardware (eg. Realtek NIC

To test ping latency:

sudo chrt 99 ping -i .001 -q 10.10.10.10

and run for a day or so while torturing the computer with
you-tube videos etc

Today i made a different test. 
1. Network card configuration over the network-manager-gnome tool
Ethernet controller: Realtek 
Driver r8169
firmware-version: rtl8168h-2_0.0.2 02/26/15

740436  hm2_7i76e.0.read.tmax
1170167  servo-thread.tmax
Quick ping check AVG time: 0.062

Ethernet controller: Intel Corporation 82576 
driver: igb
firmware-version: 1.2.1

1287877  hm2_7i76e.0.read.tmax
1745947  servo-thread.tmax
Quick ping check AVG time: 0.078

2. Network card configuration direct /etc/network/interfaces and the network-manager-gnome tool delete complete

file snip
#Ethernet controller: Intel Corporation 82576
auto enp2s0f0
iface enp2s0f0 inet static
address 10.10.10.1
netmask 255.255.255.0
hardware-irq-coalesce-rx-usecs 0

#Ethernet controller: Realtek 
auto enp1s0
iface enp1s0 inet static
address 10.10.10.2
netmask 255.255.255.0

Ethernet controller: Realtek 
2622746  hm2_7i76e.0.read.tmax
2721611  servo-thread.tmax
Quick ping check AVG time: 0.082

Ethernet controller: Intel Corporation 82576 
820478  hm2_7i76e.0.read.tmax
1120263  servo-thread.tmax
Quick ping check AVG time: 0.072

I not search for any spikes in *tmax times. Maschine was running for 5 min and no stress on pc. But the difference is unbelievable.
It seems i makes a huge different how to config the card. But in the time on both near equal. Just intel has to config over /etc/network/interfaces and realtek cards need the non free firmware driver and config over the network-manager-gnome. 

 

A follow-up to my earlier post about the N5105-based mini-PC.
After doing a more thorough latency test, I got some very high numbers (not far short of 1 mS jitter).  I didn't see how the NIC could cause the symptoms (disabling the interface doesn't make any difference), but I ended up with a messed up system (somehow I "upgraded" from gcc-12 to gcc-10, which prevented the r8168-dkms package installing), so I decided to do a clean build closely following Rod's instructions to see if fixing the NIC driver helped latency.

First surprise was that I could not install the recommended weekly build ISO.  grub would not get past the grub prompt and the grub shell didn't even see the root partition.  I couldn't fix it, so I tried the debian-bookworm-DI-alpha1-amd64-netinst iso, and that worked.  This release (6.1.0-3) includes support for the UHD graphics, but the RTL8821ce WiFi driver needed to be built from source again. Using Synaptic, I installed linux-headers-6.1.0-3-rt-amd64 and linux-image-6.1.0-3-rt-amd64 from the bookworm repository, along with r8168-dkms, linux-uspace, linux-uspace-dev and mesaflash (2.9.0~pre1+git20230208.f1270d6ed7).

I did a quick test with Axis and a 7i96s on the bench.  It seemed to work Ok the first time, but when restarting Axis I got the "read finish" error (servo period 1mS).  Restarting the PC was needed to avoid the error after exiting Axis.  This aside, it seemed to work, and I got the following results:

I don't know what the root cause of the "read finish" error is, but it sounds to me that the inability to clear it is a driver bug. I did find that increasing the servo period to 2mS in pncconf eliminated the "read finish" error, even after restarting Axis.

Out of interest, I installed a TP-link UE300, a $10 USB ethernet dongle using the RTL8153. This gave me the following results:


The min and average RTTs are higher than for the RTL8168, which I suppose is due to the USB, but the max is much lower, perhaps suggesting the RTL8168 driver needs some work? Maybe I don't have it installed correctly, or maybe even have a hardware issue; I'd be interested to see what numbers other people get.

As another comparison, my previous system using Debian 4.19.0-23 and LinuxCNC 2.6.1 and a very old AMD 79C970 NIC gives the following:
My surmise is that built-in RTL8168H ethernet will probably work as well as the USB dongle or the older NIC, if the "read finish" error can be avoided by increasing the servo period. I plan on substituting the mini PC for the current PC on my mill, so we'll see if that's so.

I found a way to check "hardware-irq-coalesce-rx-usecs" status.  will show this and  will change the hardware-irq-coalesce-rx-usecs. 
 

Tried this command on the UE-300 USB dongle, and it appears to reduce average ping RTT by about 15%. However, the -c and -C commands are not available for the driver for the built-in RTL8168H. Turns out the r8168-dkms driver is a "New API" driver (version 8.051.02-NAPI). From my quick googling, it seems NAPI is an alternative to IRQ coalescing, which may or may not be better, but it means ethtool can't be used to fine tune the algorithm. We get what we get, I suppose.

"error finishing read" means that too many sequential read timeouts have occurred.
You can change the threshold and attack/decay timing (man hm2_eth)

It can be cleared in hal but this requires resetting the watchdog and
any downstream watchdogs (like sserial devices) before continuing