Advanced Search

Ok, maybe this helps...

Originally I was using 10.10.10.1 as the IP on the Pi 5.

sudo nmcli con mod "Wired connection 1" ipv4.addresses 10.10.10.1/24

ip addr /* returned 10.10.10.1/24 */

For the past day however I have been using 10.10.10.11 because I read somewhere never to use the dot-1.

So I changed back to dot-1 and was able to get intermittant packet loss -- usually 0%, sometimes 1 packet if I used Ctrl+C (see previous posts). In one instance I was able to lose 7 packets.

Further, I was able to lock up the ethernet again.

What happens is I run this command

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

and I note that the green LEDs on the ethernet are no longer flashing at some point. So I Ctrl+C and there are lots of lost packets (23% or something like that).

But running a ping 10.10.10.10 also now fails, but if I run this again

sudo nmcli con mod "Wired connection 1" ipv4.addresses 10.10.10.11/24

then the ping starts working again and we are all good to go again.

So........ is my sin that I used 10.10.10.1 and it is conflicting with the default gateway that I have not set anywhere but is perhaps defaulting to that IP address?

Looks fine so far.

To try encouraging packet loss, I have plugged in a brushed electric drill into the same plugbox and revved it, and then plugged in a desktop PC with SMPSU. Still 0% packet loss over 10x sends of 5000 packets. Capacitors are not fitted.

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.