error finishing read

I think it depends what you want to do if the older buster config wil work for you.
Support for the  R8125 was not added until Kernel 5.9 so not readilly available until Bulseye on kernel 5.10
I did compile the Realtek sources on my H2 way back before I played with Bulseye and Buster.

I'm really surprised the H3 is so bad as its not really any different to the H2.

The original Odroid H2's had a 1gb realtek NIC, I bought a batch of these and never had an issue running a 1ms servo thread. I have several in use with LinuCNC ow

The H2+ and everything after used the r8125 2.5gb NICs same as the Netcard. Up till the H3 I only ever used that NIC in an H2 with a netcard in my DIY router (as in network router, not a machine) and it's fine for that.

The H3 has been a big headache but it's probably more of a Linux issue. I already have the isolcpus thing going. I'll have to look into the bios stuff since it's not obvious what half that crap means. Do you guys have a test kernel ready besides the one linked in your doc?

I started with the H2+ and R8125 NIC. I had to compile the driver.
We just need to enable kernel tracing that is turned off when there is a packet error and have some RT devs who will review the trace.. 
Last night it did not go well due to some confusion about RT threads in use and there was nothing usable reported.
We are hoping the kernel trace at the point of failure would shed some light on ithe issue under expert eyes.

So in answer to your question, any kernel should do if you get EFR's

I suppose for the time being I may just deal with the 2ms servo thread. Hopefully by the time I get my 7i92 BoB revised something will be resolved with this shitty kernel. I don't really have time to swap kernels and build drivers all day. I've got about 9000 other unknown things on the machine I'm messing with.

I don't get this. I have a PC with R8111 NIC and 6.3 kernel. Previously it threw EFRs regularly until I applied my fixes. I wanted to revert it to  one that reliably threw packet/EFR errors for testing
So I purged the R8168 driver and reverted to a Debian 6.1 RT kernel.
The darn thing wouldn't play ball at all.
So I changed the sevo thread to 0.5 ms and it was still stable
Eventually, I could get  it to throw a couple of  packet errors with a servo cycle down to 0.15 ms
I eventually got to throw an EFR at 0.10 ms

It seems then that something has not fully reverted to the original state. I did accidentally experience something similar months ago.

Anybody got any ideas with what is going on?
 

No idea how that happened, but if those are real times, that's fantastic...

I have tested the first 6.4 RT kernel (6.4-rc2-rt1) and it seems a bit better
than the 6.3.1 kernel both on latency tests and network latency.

One change that does seem to improve network latency on my systems
is to use isolcpus and isolate the last CPU (my test systems are all 4 core)
_and_ pin the Ethernet IRQ to the last CPU.

 _and_ pin the Ethernet IRQ to the last CPU.

Any details on how to do that?

Anyone know if this is more of a problem with recent Realtek NICs or is this just a Kernel thing? A fella on the Odroid forums seemed to know a thing or 2, and on point to point pings he was getting ~0.5ms with an H3 but an H2 was a bit better. This is stock 6.08 (non RT) kernel and 8169 module. Thats not great but alot better than mine.

He suggested the issue might have something to do with the NIC switching down to 100Mbit might be the issue. When I get a chance I'll try pinging a laptop at 1Gbit see if it's any better. 

Yes for example, on a 4 CPU system with isolcpus=3
You would by setting the smp_affinity for the Ethernet IRQ to 8
(as root)

echo "8" > /proc/irq/N/smp_affinity

Where N is the Ethernet IRQ number
8 because the smp_affinity is a bit mask
(8 is CPU 3, 4 is CPU 2, 2 is CPU 1 and 1 is CPU 0, 7 is CPUs 1,2,3 etc)

There are probably scripts to do this