LinuxCNC and Linux and Ubuntu and PC and RPi ping issues with Mesa 7i96s

Hi, I’m hoping that someone with a RPi Raspberry Pi 4 or 5 or a LinuxCNC desktop/laptop and Mesa 7i96s (or similar Ethernet card) can give me a little bit of assistance.

Could someone please try pinging the Mesa card for 5 or 10 or 15 minutes using the following commands to see if the ethernet comms stops communicating?

I have tried this myself using quite a few different permutations as hinted at in this post title, and in every case I have found the ethernet communications to fail within a few minutes. I am documenting this now and will post it below in a day or two.

==========================================================================

These are the commands I use on a fresh OS install and with Mesa card set to 10.10.10.10 using the W5 jumper.

nmcli con show // look for the ethernet name, probably “Wired connection 1”

sudo nmcli con mod “Wired connection 1” ipv4.addresses 10.10.10.11/24  // See the ethernet port to this address with mask 255.255.255.0

ping 10.10.10.10  // ping the Mesa card to see if the ethernet comms is working (assuming card is at address 10.10.10.10)

sudo chrt 99 ping -i 0.001 10.10.10.10  // repeatedly ping the card at 1 ms intervals and wait to see if the comms stops (5 minutes typ. in my experience)

==========================================================================

If you don’t get a failure of the communications, could you please post the version of Linux that you are using? You can use the following command.

uname -a

Thanks in advance.

For reference: 7i92 intermittant comms --->  forum.linuxcnc.org/27-driver-boards/3656...2-read-error?start=0

 

Why don't you set the IP address as described in man hm2_eth?
Does it make any difference?

Hi Rod, are you referring to this?

Configure network with static address

Add these lines to the file /etc/network/interfaces to configure eth1 with a static address:

auto eth1
iface eth1 inet static
address 192.168.1.1
hardware-irq-coalesce-rx-usecs 0

===========================================

"hardware-irq-coalesce-rx-usecs" decreases time waiting to receive a packet on most systems, but on at least some Marvel-chipset NICs it is harmful. If the line does not improve system performance, then remove it. A reboot is required for the value to be set back to its power-on default. This requires the ethtool package to be installed.

===========================================

knowledge.informatica.com/s/article/80204?language=en_US

"Interrupt coalescing is the standard terminology for batching network data at the network interface card (NIC) in order to increase the amount of data delivered to the kernel with one hardware interrupt."

rx-usecs  "Number of microseconds to delay an RX interrupt after packet arrival. If 0, only rx-max-frames is used."

tommylight wrote:

Rod is still sleeping, but yes, he is referring to that.

Its actually early evening here.
The coalesce settings are required for intel NICs for RT performance.
I have a feeling that the broadcom NIC's may have some similar settings.

Here in New Zealand I should be sleeping...

I have been searching for "Broadcom" and "coalesce" and have found nothing so far. However, I did find that both the Pi 4 and Pi 5 both use the same Broadcom chips:

Broadcom BCM54213 Gigabit Ethernet PHY

Source: en.wikipedia.org/wiki/Raspberry_Pi#Specifications

The good news for me at this stage (following Rod's suggestion) is that I have run 500,000 pings between my Pi 5 and 7i96s and unlike previous horrors there were 0 lost packets !!! I am now running it overnight with a target of 30,000,000 pings, so here's hoping.

Thanks a lot guys for the pointer on this. The learning curve is steep, but if the RPi 5 can perform, it would be a great solution. It boots to the log screen in about 5 s so is pretty quick. It would be nice to physically mount it on or above the Mesa card...

If you are willing and able, could you take a minute and describe what you think the coalesce setting is doing? My understanding is that once an interrupt is generated by an incoming packet, future interrupts are disabled for some time period and replaced with polling in order to reduce CPU overhead required by the interrupt operation.

RNZ wrote:

Here in New Zealand I should be sleeping...
 

Nah the night is still early. I tried to go to bed at midnight last night but was wide awake so stayed up to 3:30 so pulled an all nighter NZ time..
Bloody prednisone!

30_000_000 pings last night with zero failed packets.

I would love to know the technical reasons that (I) packets are lost, and (I) Ethernet transfers stop, if the coalesce setting is not used.

It may have to do with the default rx-usecs setting.
If I run the ping test with a a small (but non zero) rx-usecs
setting, I don't lose any packets but if I use a larger value
(say 300 usec) I start to lose the first packet.

I never lose more than the first however.

Losing the link sounds more like a driver bug with the coalesce setting...