Advanced Search

Being new hardware, its possible you are a victim of enegy efficient ethernet.

ref: www.juniper.net/documentation/us/en/soft...e%20link%20is%20idle.

Could you try disbale it by adding
igb.EEE=0

to your boot parameters (where you put isolcpus) I think its boot.txt on the pi
I have no idea if this will work!
 

Running this on RPi 5 8 GB with Mesa 7i96s:

latency-histogram --nobase --sbinsize 1000

With essentially no load on the Pi, have after about 400 seconds:

min (us) = -18.8
max (us) = 19.2
sdev (us) = 0.9

With 1x Glxgears, after about 80 seconds:

min (us) = -16.6
max (us) = 14.5
sdev (us) = 0.9

With 2x Glxgears, after about 80 seconds:

min (us) = -20.4
max (us) = 15.2
sdev (us) = 1.6

With 3x Glxgears, after about 80 seconds:

min (us) = -18.6
max (us) = 16.5
sdev (us) = 2.2

With 4x Glxgears, after about 80 seconds:

min (us) = -17.2
max (us) = 18.3
sdev (us) = 2.6

With 5x Glxgears, after about 80 seconds:

min (us) = -21.6
max (us) = 20.6
sdev (us) = 3.0

With 6x Glxgears, after about 80 seconds:

min (us) = -16.5
max (us) = 18.1
sdev (us) = 3.1

With 10x Glxgears, after about 80 seconds:

min (us) = -23.8
max (us) = 16.6
sdev (us) = 3.5

Seems that the 7i96s ethernet connection to the Pi has died again during these tests.

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

Repeating the 10 gears version on HP i5 8100 Elite SFF x86_64 6.1.0-13-rt-amd64 2.9.1 3.6 GHz

With 10x Glxgears, after about 200 seconds:

(1000 us servo thread)
min (us) = -80.8
max (us) = 79.3
sdev (us) = 1.5

(25 us base thread)
min (us) = -24.9
max (us) = 42.4
sdev (us) = 0.8
 

@CORBETT

good point - I myself try to search here, which hardware work.
I bought some used hp prodesk, just to find out that it has realtek NIC, which has problems with latency.
Now I bought two dell optiplexes and they have intel NIC and much more settings available in BIOS regarding latency tuning.
But with new raspberry pi 5, someone has to find out first

Anyway, last comment from Bjarne says, that it is possible to port macb driver and suggested to compare some existing drivers (orig vs ethercat) to see what it takes.
However this is beyond my knowledge, so we have to find someone who is capable and willing to do it.

Or I can ask for quote at IGH.

Hey @rodw

I think I stated it somewhere in the thread over ther, but I used this image:
rpi-5-debian-bookworm-6.1.61-rt15-arm64-ext4-2023-11-17-1520.img.xz
from linuxcnc.org/downloads/

Isn't your pursuit somewhat of a wild goose chase? You're only running a servo thread so I'm assuming you have a hardware motion controller like a mesa card, and if that's the case, is there any benefit to having 20us max jitter vs 60 or even 80? I'm sure someone more knowledgeable will correct me if I'm wrong, but with a mesa board even 100us max jitter should be fine. In the context of linuxcnc (and real-time in general), it's more of a "works/doesn't work" rather than "this works faster".

I'm actually quite please with this computer. There are multiple threads here struggling with just the right raspberry pi config with a custom linuxcnc image, or threads about other SBCs working with linuxcnc at all - orange pi, banana pi, odroid and so on, while this one seems to work just fine out of the box with the regular x86 image. No messing about.

I'll do as tommylight suggested and run it overnight soon so we'll see, but that puts us back to the works/doesn't work thing. if it works fine with high jitter, it really doesn't matter that other cpus can do the same job with lower jitter, no?

Hey Richie, how did you go with the RPi 5? I have the same + Mesa 7i96s in Blenheim…

Thanks, I will give that a try tomorrow and report back.

Its a hardware issue. please read my tutorial here
docs.google.com/document/d/1jeV_4VKzVmOI...diY/edit?usp=sharing

The good news is that the RPi and Mesa 7i96s are communicating and appeared to be doing so reliably using the Dragon GUI until a string of these messages appeared:

hm2/hm2_7i92.0: error queuing read! iter=xxx
hm2/hm2_7i92.0: error finishing write! iter=xxx

If I run the following, there appears to be dropped packets:

sudo chrt 99 ping -i .001 -q 10.10.10.10  /* forum.linuxcnc.org/27-driver-boards/4837...rite?start=20#266420 */

About 25% were dropped when using a 30 cm CAT cable (not sure what type, shown in photo above). Changing to a longer CAT 5e cable resulted in a tiny percentage of dropped packets. Nevertheless, the errors keep appearing when running Dragon GUI -- I'm not suggesting that Dragon GUI is the issue here.

Did this ever get resolved?  I have a Raspberry Pi 5 and 7i96s and I am seeing the same issues:

hm2/hm2_7i92.0: error queuing read! iter=xxx
hm2/hm2_7i92.0: error finishing write! iter=xxx

forum.linuxcnc.org/9-installing-linuxcnc...i-5?start=110#293125

Yup, I find it kinda funny that a site catering to technology uses such a terrible editor :-D

I have used a lot of forums but never seen one this bad :-D

If it wasn't for the great people here it'd just be too painful hahahah.

@0x2102
Hey man, thanks for posting that.  I haven’t had this problem before, but I like learning new info in case I ever do!!!  Nice…


@ zmrdko
Thanks for sharing your info.  I knew the “generic” component was slower as Dominik had stated so years ago, and I always try to avoid hardware that is not already in the driver… 

 

Now try to reducing those two settings:

sudo ethtool -C eth0 rx-usecs 0
sudo ethtool -C eth0 tx-usecs 0

If that errors out, try 1 or the lowest number the driver accepts.

Regarding Bjarnes comments on your issue about debian could you advise if you are using the image on the Downloads page?

Hi!
thanks for reply.

see output in attachment