Hi,
I have a stretch box configured as VLAN router (Cubox -i2ex). There is a
drastic difference between the bandwidth of the uplink (VLAN1) and the
downlinks (VLAN 2 to 7):
On 192.168.7.1 (VLAN 7: eth0.7) I see arround 9 MB/s in a simple test:
rd@home:~$ wget -O /dev/null http://fs/debian-9.3.0-amd64-netinst.iso
[...] (9.08 MB/s)
rd@home:~$
On 192.168.0.30 (VLAN 1: eth0.1) is see less than 10%:
rd@home:~$ wget -O /dev/null https://git.kernel.org/torvalds/t/linux-5.3-rc1.tar.gz
--2019-07-27 14:46:38-- https://git.kernel.org/torvalds/t/linux-5.3-rc1.tar.gz
[...] (339KB/s)
To prove that it has nothing to do with the uplink (there is a Fritzbox 6430)
itself, I connected another machine on same VLAN 1 (192.168.0.203). So
overall, the network looks like this
Internet
|
|
Fritz-Box
|
| 192.168.0.203
|--------------------------------------- x86
|
| 192.168.0.30
|
Cubox i
|
| 192.168.7.*
|
Note, the Cubox-i has only 1 physical interface, drawn are the virtual
interface.
The x86 machine reaches also a much higher network bandwidth:
rd@h370:~/tmp.nobackup$ wget -O /dev/null https://git.kernel.org/torvalds/t/
linux-5.3-rc1.tar.gz
[...] (5,49 MB/s)
rd@h370:~/tmp.nobackup$
I did run ifstat to confirm that there is no other traffic which consumes all the
bandwidth:
rd@home:/etc/shorewall$ ifstat -i eth0.1 1
eth0.1
KB/s in KB/s out
495.00 16.34
417.14 16.03
484.33 16.53
384.80 11.96
393.33 12.67
632.59 17.68
607.90 17.91
354.39 12.00
678.58 20.97
1119.24 26.88
1185.20 27.27
925.91 21.84
1245.82 27.88
940.69 26.06
1023.72 26.89
1114.13 26.33
997.74 24.56
876.72 19.49
1167.56 27.73
906.41 24.30
1127.62 27.36
919.79 20.01
915.31 20.95
990.86 23.97
1119.22 26.94
905.54 26.40
1143.21 28.44
1096.15 26.98
924.62 24.89
1076.53 24.87
1004.04 23.99
811.11 23.13
983.71 24.46
885.05 23.19
1052.26 43.33
1230.55 37.11
1517.61 33.67
818.60 24.37
1057.24 26.63
1131.38 26.47
1278.43 30.12
1123.24 24.31
788.14 21.74
757.56 23.86
1135.29 27.91
1161.76 25.15
1465.32 32.04
1175.41 26.16
1371.36 31.56
811.73 21.70
540.97 16.91
381.78 20.95
306.44 13.07
378.02 12.93
603.65 16.67
418.31 16.35
393.71 16.46
479.89 15.05
436.74 13.85
395.96 12.05
476.41 14.51
470.09 18.23
322.02 12.20
427.35 14.33
464.25 14.39
404.19 11.09
999.41 24.39
931.23 24.89
Also top does not show any obvious overload:
rd@home:~$ top
top - 14:51:53 up 34 days, 1:18, 3 users, load average: 1.10, 1.11, 1.24
Tasks: 177 total, 2 running, 125 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.2 us, 5.2 sy, 0.0 ni, 87.9 id, 0.2 wa, 0.0 hi, 1.5 si, 0.0
st
KiB Mem : 2062764 total, 89308 free, 239480 used, 1733976 buff/cache
KiB Swap: 4726172 total, 4726172 free, 0 used. 1740396 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13341 rd 20 0 12072 7196 3716 S 3.6 0.3 0:01.33 wget
7221 root 20 0 62236 3508 2468 S 2.9 0.2 394:36.44 owserver
1257 rd 20 0 4036 2304 2052 S 2.0 0.1 945:39.61 reed-
contact-mo
7687 rd 20 0 4712 2508 1596 S 2.0 0.1 571:54.03 monitor.sh
13597 rd 20 0 7212 2900 2276 R 1.6 0.1 0:00.53 top
1040 asterisk 20 0 221968 58292 30316 S 1.3 2.8 565:37.76 asterisk
17 root 20 0 0 0 0 S 0.7 0.0 434:16.89 ksoftirqd/1
10 root 20 0 0 0 0 R 0.3 0.0 94:31.09 rcu_sched
202 root 20 0 27144 6192 5760 S 0.3 0.3 89:57.07 systemd-
journal
8678 root 0 -20 0 0 0 I 0.3 0.0 0:22.47 kworker/
2:2H-kb
21622 root 20 0 0 0 0 I 0.3 0.0 0:01.57 kworker/
u8:3-ev
32581 root 0 -20 0 0 0 I 0.3 0.0 0:18.03 kworker/
0:1H-kb
1 root 20 0 26672 5236 3852 S 0.0 0.3 2:42.16 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:07.14 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00
mm_percpu_wq
9 root 20 0 0 0 0 S 0.0 0.0 4:43.82 ksoftirqd/0
11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_bh
12 root rt 0 0 0 0 S 0.0 0.0 2:43.11 migration/0
So in summary:
-> The uplink of the cubox to the internet is slow (<10% of available
bandwidth)
-> The cubox can run on the physical interface (the0) much higher traffic (as
shown on VLAN 7)
-> Another x86 host can run much higher traffic into the Internet
Any idea on what could restrict the bandwidth on the Cubox uplink is very
welcome. Also any ideas to diagnose the issue further would be useful for me.
Many thanks
Rainer
--
Rainer Dorsch
http://bokomoko.de/