Ooops, I saw the pings but missed the disconnect window. So to my mind, the only things that could cause this is faulty hardware, crappy network cable or a flakey power supply on the Mesa card. The Mesa power can be eliminated at this point. Time to follow PCW's advice to isolate that piece of hardware is causing it.

But the ping times are also too slow.

None of my suggestions are out of scope  of a  mesa card and earlier screen dumps showed no isolcpus was set so a lot of work to do there 

Here is a checklist of the key optimizations required for a `PREEMPT_RT` real-time kernel on Debian, specifically tailored for network performance on interface `eno1`.

### 1. BIOS/UEFI & Hardware Level

* Disable **Intel SpeedStep / AMD Cool'n'Quiet**
* Disable **Global C-States** (C1E, C3, C6, etc.)
* Disable **Intel Turbo Boost / AMD Core Performance Boost**
* Disable **Hyper-Threading (SMT)** *(highly recommended for strict determinism)*
* Disable **System Management Interrupts (SMIs)** / Advanced Power Management

### 2. Boot Command Line (`grub-customizer`)
lastcore = the last CPU you have. say its 3 on a 4 core CPU but yours may be different
* Add `isolcpus=3` to isolate specific CPU cores for RT tasks
* Add `nohz_full=3` to enable full dynticks on isolated cores
* Add `rcu_nocbs=3` to move RCU callbacks off isolated cores
* Add `processor.max_cstate=0` and `intel_idle.max_cstate=0`
* Add `pcie_aspm=off` (disables PCIe Active State Power Management)
* Add `skew_tick=1`

### 3. Network Interface (`eno1`) Optimizations

* Disable **Adaptive Interrupt Moderation** (`ethtool -C eno1 adaptive-rx off adaptive-tx off`)
* Set static interrupt coalescing to 0 (`ethtool -C eno1 rx-usecs 0 tx-usecs 0`)
* Disable offloads causing latency spikes:
* Generic Receive Offload (`ethtool -K eno1 gro off`)
* Large Receive Offload (`ethtool -K eno1 lro off`)
* TCP Segmentation Offload (`ethtool -K eno1 tso off`)
* Bind `eno1` queues to the single dedicated, isolated CPU core

### 4. Operating System & IRQ Tuning

* Increase the real-time priority of the `eno1` threaded IRQ handlers (using `chrt`)
* Set the `eno1` IRQ affinity mask to use isolated core
* Set the system power management policy to performance (`cpupower frequency-set -g performance`)
* Disable the `irqbalance` daemon (`systemctl disable irqbalance`)

 

Do you have anther PC or another Mesa card to see which device is dropping the connection?

These are my HAL and INI files    
I can ping 10.10.10.10 but every time it goes over 0.500 ms it throws the error 
These are my W2 and W3 jumpers
This is power to the board 
This is the power supply to the board 
And I also have a Meanwell MDR 60 24 for testing its just a really old one. 

I'm a bit confused, Initiially an IP address was not set but in later ip a dumps it was correctly set for a Mesa board at 10.10.10.10, It was never made clear after that if the Mesa board was pingable. I assumed it was. 
I would like to see the Hal and ini files to confirm the MESA IP address.
Can you ping the card?

Also from photos of the board, it would be great if PCW could confirm that the links are set for the 10.10.10.10 address is set correctly. W2 down, W3 Up

Also, need to check out the 5 volt power supply to the board which is usually powered form field power which seems to be the case. But are the links set correctly to send 5 volts to the logic side? Can PCW confirm?

The final thing to check on physical wiring, What is the field power voltage? What is the actual power supply? What is the power supply current available? There have been numerous instances where borderline power supplies cause network failure with Mesa cards. This must be ruled out. If need be get a good industrial power supply such as Meanwell MDR-60-24.

It might be worth setting the IP address back to automatic (DHCP) and connecting the PC to your normal network using this NIC card to confirm networking is working.

I mentioned it before but be sure to set the IP address and coalescing as shown in man hm2_eth (use your IP address and 
linuxcnc.org/docs/stable/html/man/man9/h...h%20static%20address

So if all of that checks out and a new network cable does not fix things AND the network is connecting but drops out every 45 seconds or gets error finishing read., there will likely be one of several power saving settings kicking in periodically.





 

So this is the current setup 
And I have this HP PC here I can use for testing. 

Yes, this does not seem to be a latency issue but a connection issue.
Not really sure what the cause is. I have a 800 G1 here running
LinuxCNC without any Ethernet connection issues so I don't know.

Is is possible to try another PC to try and isolate the issue?



 

There are a lot more tuning settings required but lets get the main one
Can you type: echo $(nproc)
and then back in grub customizer add isolcpus=X where X = $(nproc)-1 from what is printed from the line above.
Then reboot.

My bad the PC is actually a HP Elitedesk 800 G1 USDT 
AMT is not disabled in BIOS where can I find those settings?   

OK a 8300 USDT uses Intel hardware and should be fine

Is AMT disabled in the BIOS?

So some background information my plasma table electronics and mesa 7i76e are not new the PC is new a newer HP elite 8300 USDT I swapped it out recently following issues with this post  forum.linuxcnc.org/plasmac/53087-qtplasm...e-0-in-middle-of-cut  

I am not sure how do I find host hardware? 

is the

ip a

result still reasonable?

What is the host hardware?