Raspberry - High network latency

English Network/Internet
1

Hi,
I’m using Raspberry Pi 1 Model B and I’m facing to a too high network latency; I’m using this rasp as a firewall, with the internal network card and a USB one (via powered, 1A but I tried also 2A, USB hub).
The problem arise only when both NICs are used at the same time:

1 NIC connected (USB plugged, cable plugged or IPv4 assigned):
64 bytes from 192.168.0.254: icmp_seq=680 ttl=64 time=0.908 ms
64 bytes from 192.168.0.254: icmp_seq=681 ttl=64 time=0.924 ms
64 bytes from 192.168.0.254: icmp_seq=682 ttl=64 time=0.903 ms
64 bytes from 192.168.0.254: icmp_seq=683 ttl=64 time=0.892 ms

Once I plug the cable, or assign manually the IP, the latency increase > 1000ms:
64 bytes from 192.168.0.254: icmp_seq=684 ttl=64 time=1000 ms
64 bytes from 192.168.0.254: icmp_seq=685 ttl=64 time=2000 ms
64 bytes from 192.168.0.254: icmp_seq=686 ttl=64 time=2000 ms
64 bytes from 192.168.0.254: icmp_seq=687 ttl=64 time=2000 ms

When I unplug the cable (from any of the both NICs) or disconnect the USB NIC from the hub, the latency became reasonable:
64 bytes from 192.168.0.254: icmp_seq=738 ttl=64 time=2891 ms
64 bytes from 192.168.0.254: icmp_seq=739 ttl=64 time=1890 ms
64 bytes from 192.168.0.254: icmp_seq=740 ttl=64 time=889 ms
64 bytes from 192.168.0.254: icmp_seq=741 ttl=64 time=1.04 ms
64 bytes from 192.168.0.254: icmp_seq=742 ttl=64 time=0.917 ms
64 bytes from 192.168.0.254: icmp_seq=743 ttl=64 time=0.946 ms

Below the env state with the 2 NICs activated:

localhost:/tmp # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:d7:a6:f6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.254/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fed7:a6f6/64 scope link 
       valid_lft forever preferred_lft forever
11: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:e0:4c:68:00:36 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:4cff:fe68:36/64 scope link tentative 
       valid_lft forever preferred_lft forever
localhost:/tmp # lsusb
Bus 001 Device 082: ID 0e8f:2517 GreenAsia Inc. 
Bus 001 Device 081: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter                     <== USB NIC
Bus 001 Device 080: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. SMC9512/9514 USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
localhost:/tmp # uname -a
Linux localhost 4.11.1-1-default #1 Mon May 15 14:33:13 UTC 2017 (a37d575) armv6l armv6l armv6l GNU/Linux

This system is a fresh install so actually I’m using wicked, but also with NetworkManager I got the same result.
I also tried to update the kernel to v4.18, but with no luck.

Any idea about this?

Thanks in advance for your time,
Have a nice day

2

I founded an old dump of the same host (an OpenSuse 13.1), and with the same HW everything works as usual:


...]
64 bytes from 172.16.0.98: icmp_seq=1939 ttl=64 time=1.01 ms
64 bytes from 172.16.0.98: icmp_seq=1940 ttl=64 time=1.00 ms
64 bytes from 172.16.0.98: icmp_seq=1941 ttl=64 time=1.05 ms
64 bytes from 172.16.0.98: icmp_seq=1942 ttl=64 time=1.10 ms
64 bytes from 172.16.0.98: icmp_seq=1943 ttl=64 time=1.10 ms
...]

Kernel used was 3.11, the new one 4.18.
Any idea?

3

No real idea why your problem,
But maybe as a starting point I’d perhaps try switching around your NICs to see if the problem might be related to your onboard or USB NIC (not necessarily the NIC itself, but the entire associated subsystems, eg USB).
Or, short of switching everything around, pinging the other interface from the “other” network.
You may find that only one of your interfaces has high latency.

I might also suggest trying a new image…
Either when a new TW image is released or a LEAP image…

TSU