May-6th-2019, 04:26 PM
(This post was last modified: May-6th-2019, 04:27 PM by Armin@netPI.)
Well I tried the very same thing
but here as you can see every ping works.
Is there additional traffic running across this specific IP address or is it just the ping command as only message? What else are you running on your netPI? Other containers that could occupy the CPU a lot? What is the general traffice running over this network the cifx0 interface is connected to?
What is true is that the Ethernet LAN interface across netX chip (which was initially made for supporting industrial networks) is 10 times slower in communication and throughput than the standard eth0 interface. We have to pack all TCP/IP traffic into acyclic messages between Raspberry CPU and netX and as you know this interface is an SPI connection at 25Mhz clock rate only. But I doubt this is a root cause for loosing IP packets.
Code:
64 bytes from 192.168.30.253: icmp_seq=1 ttl=64 time=4.48 ms
64 bytes from 192.168.30.253: icmp_seq=2 ttl=64 time=2.34 ms
64 bytes from 192.168.30.253: icmp_seq=3 ttl=64 time=1.68 ms
64 bytes from 192.168.30.253: icmp_seq=4 ttl=64 time=1002 ms
64 bytes from 192.168.30.253: icmp_seq=5 ttl=64 time=1.49 ms
64 bytes from 192.168.30.253: icmp_seq=6 ttl=64 time=1.78 ms
64 bytes from 192.168.30.253: icmp_seq=7 ttl=64 time=1.78 ms
64 bytes from 192.168.30.253: icmp_seq=8 ttl=64 time=1.04 ms
64 bytes from 192.168.30.253: icmp_seq=9 ttl=64 time=2.13 ms
64 bytes from 192.168.30.253: icmp_seq=10 ttl=64 time=1.46 ms
64 bytes from 192.168.30.253: icmp_seq=11 ttl=64 time=2.21 ms
64 bytes from 192.168.30.253: icmp_seq=12 ttl=64 time=2.19 ms
64 bytes from 192.168.30.253: icmp_seq=13 ttl=64 time=1.78 ms
64 bytes from 192.168.30.253: icmp_seq=14 ttl=64 time=1.45 ms
64 bytes from 192.168.30.253: icmp_seq=15 ttl=64 time=1.82 ms
64 bytes from 192.168.30.253: icmp_seq=16 ttl=64 time=1.40 ms
64 bytes from 192.168.30.253: icmp_seq=17 ttl=64 time=1.84 ms
64 bytes from 192.168.30.253: icmp_seq=18 ttl=64 time=1.64 ms
64 bytes from 192.168.30.253: icmp_seq=19 ttl=64 time=2.26 ms
64 bytes from 192.168.30.253: icmp_seq=20 ttl=64 time=1.97 ms
64 bytes from 192.168.30.253: icmp_seq=21 ttl=64 time=2.97 ms
64 bytes from 192.168.30.253: icmp_seq=22 ttl=64 time=1.95 ms
64 bytes from 192.168.30.253: icmp_seq=23 ttl=64 time=2.49 ms
64 bytes from 192.168.30.253: icmp_seq=24 ttl=64 time=1.41 ms
64 bytes from 192.168.30.253: icmp_seq=25 ttl=64 time=1.35 ms
64 bytes from 192.168.30.253: icmp_seq=26 ttl=64 time=1.71 ms
64 bytes from 192.168.30.253: icmp_seq=27 ttl=64 time=2.88 ms
64 bytes from 192.168.30.253: icmp_seq=28 ttl=64 time=1.46 ms
64 bytes from 192.168.30.253: icmp_seq=29 ttl=64 time=1.76 ms
64 bytes from 192.168.30.253: icmp_seq=30 ttl=64 time=1.48 ms
64 bytes from 192.168.30.253: icmp_seq=31 ttl=64 time=2.10 ms
64 bytes from 192.168.30.253: icmp_seq=32 ttl=64 time=1.90 ms
64 bytes from 192.168.30.253: icmp_seq=33 ttl=64 time=2.26 ms
64 bytes from 192.168.30.253: icmp_seq=34 ttl=64 time=2.12 ms
64 bytes from 192.168.30.253: icmp_seq=35 ttl=64 time=1.73 ms
64 bytes from 192.168.30.253: icmp_seq=36 ttl=64 time=1.66 ms
64 bytes from 192.168.30.253: icmp_seq=37 ttl=64 time=2.31 ms
64 bytes from 192.168.30.253: icmp_seq=38 ttl=64 time=1.85 ms
64 bytes from 192.168.30.253: icmp_seq=39 ttl=64 time=2.39 ms
64 bytes from 192.168.30.253: icmp_seq=40 ttl=64 time=2.37 ms
64 bytes from 192.168.30.253: icmp_seq=41 ttl=64 time=1.93 ms
64 bytes from 192.168.30.253: icmp_seq=42 ttl=64 time=1.96 ms
64 bytes from 192.168.30.253: icmp_seq=43 ttl=64 time=2.10 ms
64 bytes from 192.168.30.253: icmp_seq=44 ttl=64 time=1.56 ms
but here as you can see every ping works.
Is there additional traffic running across this specific IP address or is it just the ping command as only message? What else are you running on your netPI? Other containers that could occupy the CPU a lot? What is the general traffice running over this network the cifx0 interface is connected to?
What is true is that the Ethernet LAN interface across netX chip (which was initially made for supporting industrial networks) is 10 times slower in communication and throughput than the standard eth0 interface. We have to pack all TCP/IP traffic into acyclic messages between Raspberry CPU and netX and as you know this interface is an SPI connection at 25Mhz clock rate only. But I doubt this is a root cause for loosing IP packets.
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)