Advanced Search

Micro SDCard.

I ran

/opt/vc/bin/vcgencmd measure_temp

So the Pi is sitting at 48.8. Running

sudo chrt 99 ping -i .001 -q 10.10.10.10 -c 50000

50000 packets transmitted, 50000 received, 0% packet loss, time 50045ms
rtt min/avg/max/mdev = 0.102/0.112/0.197/0.006 ms

/opt/vc/bin/vcgencmd measure_temp
temp=50.5'C

So the wee fan and large heatsink appear to be holding the temperature down with a 50 s length increased load.

So....... this morning the Pi 5 has been quite stable in terms if ethernet comms. I might naively be thought to have caused this because I added 1x 0.1 uF and 1x 47 uF/16 V electrolytic capacitor across the blue terminal block (photo a couple of pages back) which is across the +5V / 0V rail.

I did this for a few reasons. First, because yesterday I plugged in the 7i96s while the Pi was running which may have caused the Pi to reset. Possibly the voltage at the Pi dipped due to 7i96s capacitance. I don't know if the Pi has any decent amount of power supply capacitance -- perhaps it is hidden under the heatsink (not a good place for electrolytic capacitors to live).

Second, the 5V/3A Meanwell PSU datasheet does not specify the output capacitance (or stability if you add capacitance). But in any case, the resetting of the Pi could suggest it doesn't have a lot of output capacitance.

Third, the 5V rail wiring is a bit long and all over the place, so could be picking up noise from other appliances, so this could suppress it a bit.

I also raised the Meanwell 5V rail voltage from 5.0 to 5.1V at the PSU terminals. Voltage drop in the wiring is about 100 mV according to my dodgy DMM, thus perhaps the rail was causing instability.

Well, things were quite stable, so I reversed all of the above and things are still stable !!! I can repeatedly send 50,000 packets with 1 ms spacing and get 0% loss.

Booting from MicroSD or NVME?
If first, try a different one, if you can.
Or a USB stick...
-
If NVME, skip the above.
-
Also, in a terminal
sensors
should show temperatures, if the processor is above 60-65C, slap some cooling on it.

LOL wasn't sure whether you were having me on or not... anyways, I unplugged the wireless KB/mouse dongle and replaced it with a wired KB....... the 1x dropped packet issue remains. Weirdy.

Try another keyboard.

Probably not important, bu I cannot duplicate that:

pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
532 packets transmitted, 532 received, 0% packet loss, time 531ms
rtt min/avg/max/mdev = 0.073/0.083/0.110/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
500 packets transmitted, 500 received, 0% packet loss, time 499ms
rtt min/avg/max/mdev = 0.071/0.083/0.116/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
1143 packets transmitted, 1143 received, 0% packet loss, time 1142ms
rtt min/avg/max/mdev = 0.072/0.083/0.111/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
908 packets transmitted, 908 received, 0% packet loss, time 906ms
rtt min/avg/max/mdev = 0.073/0.083/0.114/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
565 packets transmitted, 565 received, 0% packet loss, time 564ms
rtt min/avg/max/mdev = 0.072/0.083/0.114/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
421 packets transmitted, 421 received, 0% packet loss, time 420ms
rtt min/avg/max/mdev = 0.072/0.083/0.112/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
332 packets transmitted, 332 received, 0% packet loss, time 331ms
rtt min/avg/max/mdev = 0.073/0.084/0.116/0.007 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
381 packets transmitted, 381 received, 0% packet loss, time 380ms
rtt min/avg/max/mdev = 0.072/0.084/0.112/0.007 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
588 packets transmitted, 588 received, 0% packet loss, time 587ms
rtt min/avg/max/mdev = 0.073/0.083/0.120/0.006 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
484 packets transmitted, 484 received, 0% packet loss, time 483ms
rtt min/avg/max/mdev = 0.073/0.084/0.122/0.007 ms
pcw@pcw-HP-Compaq-Elite-8300-USDT:/proc/irq/25$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
^C
--- 10.10.10.10 ping statistics ---
452 packets transmitted, 452 received, 0% packet loss, time 451ms
rtt min/avg/max/mdev = 0.073/0.084/0.109/0.006 ms

 

This command FOLLOWED BY CTRL+C consistently leads to a single dropped packet in about 50% of runs. Perhaps this is happening due to the Ctrl+C causing the code to exist a loop somewhere while not awaiting the last packet to return from the 7i96s...?

sudo chrt 99 ping -O -i .001 -q 10.10.10.10

569 packets transmitted, 568 received, 0.175747% packet loss, time 568ms

1400 packets transmitted, 1399 received, 0.0714286% packet loss, time 1400ms

320 packets transmitted, 319 received, 0.3125% packet loss, time 319ms

Changing to

sudo chrt 99 ping -O -i .001 -q 10.10.10.10 -c 500

where the -c 500 causes the ping code to exit after 500 cycles consistently (100%) results in 0% packet loss (ca. 20 attempts).

this has become a race on "how many posts i find by the time i post this"

RNZ wrote:

To be clear, I have a Raspberry Pi 5 and have been having ethernet stability issues when connecting to my 7i96s card. Thus during debugging I want to make sure I have the latest / most stable software versions installed.

Those are RPI issues, never ever Mesa issues.
The only things that sould cause those issues with a Mesa ethernet board are bad cable (rarely) and bad 5V supply (very often).
Otherwise, always, always host PC issues with latency due to power saving/sleep states/hyperthreading/thermal throttling/failing power supply/failing memory/failing hard drives.
On RPI i would look for power supply and thermal throttling, then follow one of the many howto's for setting whatever RPI needs to have set.
Sorry but i do not use RPI, so can not help much.

RNZ wrote:

Yes, I have those feels right now

To be clear, I have a Raspberry Pi 5 and have been having ethernet stability issues when connecting to my 7i96s card. Thus during debugging I want to make sure I have the latest / most stable software versions installed.

Of course, latest does not equal most stable, so it would be helpful to know whether I am running version 1.0.0 or 1.0.15 if you get my drift.
 

I should note that the Ethernet code has been basically unchanged for about 12 years
there have been minor tweaks and bug fixes (the latest change (to V18) fixed a bug in
the user LED options in V17) but none have changed basic Ethernet communications.

Yes, I have those feels right now

To be clear, I have a Raspberry Pi 5 and have been having ethernet stability issues when connecting to my 7i96s card. Thus during debugging I want to make sure I have the latest / most stable software versions installed.

Of course, latest does not equal most stable, so it would be helpful to know whether I am running version 1.0.0 or 1.0.15 if you get my drift.

Here's half a days worth of pinging a 7i96S on a Intel PC:

sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.

^C--- 10.10.10.10 ping statistics ---
72908387 packets transmitted, 72908387 received, 0% packet loss, time 72908386ms
rtt min/avg/max/mdev = 0.067/0.082/0.361/0.010 ms

 

Seems ATM the RPi5 isn't the best candidate for Linuxcnc.

Replaced RPi 5 with HP desktop running LinuxCNC 0.29.1, connected to 7i96s over CAT6 cable.

sudo chrt 99 ping -i .001 -q 10.10.10.10

Quick test shows 0% packet loss for 40,000 packets.

And a longer test:

2312351 sent, 2312350 received  <<<<<<<  Loss of 1 packet

rtt min/avg/max/mdev = 0.177/0.266/0.455/0.019 ms

I think this is particularly concerning. The ethernet connection just seems unstable. As pointed out, there simply should not be packet loss.

I will try replacing the Pi 5 with a PC tomorrow to trying eliminating the 7i96s as part of the problem.

cnc@linuxcnc:~/Downloads/7i96s/configs/hostmot2$ sudo chrt 99 ping -i .001 -q 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.

--- 10.10.10.10 ping statistics ---
7234 packets transmitted, 7233 received, 0.0138236% packet loss, time 7240ms
rtt min/avg/max/mdev = 0.101/0.106/0.132/0.002 ms

After a bit of poking around, I found a directory

/boot/broadcom

which contains a lot of files including

cmdline.txt

and

config.txt

I have added the igb.EEE=0 to the end of cmdline.txt as this has "isolcpus" in it.

Full file =

console=serial0,115200 console=tty1 root=PARTUUID=486f86bd-02 rootfstype=ext4 fsck.repair=yes loglevel=5 net.ifnames=0 processor.max_cstate=1 isolcpus=2,3 firmware_class.path=/lib/firmware/updates/brcm rootwait cfg80211.ieee80211_regdom=NZ igb.EEE=0

Will now reboot...

Here is part of dmesg.

[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1080 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 smsc95xx.macaddr=D8:3A:DD:E8:87:4E vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000  console=ttyAMA10,115200 console=tty1 root=PARTUUID=486f86bd-02 rootfstype=ext4 fsck.repair=yes loglevel=5 net.ifnames=0 processor.max_cstate=1 isolcpus=2,3 firmware_class.path=/lib/firmware/updates/brcm rootwait cfg80211.ieee80211_regdom=NZ igb.EEE=0

dmesg | grep EEE shows only the line above (e.g. no errors with EEE in them).