• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Langsame Netzwerkverbindung

K

kruppa

Hi,

auf meinem Fileserver funktioniert die Netzwerkverbindung nicht so schnell wie ich es erwarten würde. Ich habe einen 1000 Mbit/s Anschuss. Aufgefallen ist mir das bei folgendem Speedtest:

Code: 
speedtest-cli
Retrieving speedtest.net configuration...
Testing from Vodafone DSL (x.x.x.x)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by DNS:NET Internet Service GmbH (Berlin) [xxx.xx km]: 36.595 ms
Testing download speed................................................................................
Download: 316.36 Mbit/s
Testing upload speed................................................................................................
Upload: 53.23 Mbit/s

Ich dachte erst es liegt am Router oder Vodafone, aber das konnte ich ausschließen. Ich habe auch mehrfach und mit verschiedenen Gegenstellen getestet. Woran kann das liegen?

Hier noch die Ausgabe vom Testscript:

Code: 
network_test.sh V0.7.5.8 2016/05/22/15:43:21 - e8982e6

This program comes with ABSOLUTELY NO WARRANTY; This is free software, and you are welcome to redistribute it under certain conditions

--- Welcher Netzwerkverbindungtyp soll getestet werden?
--- (2) Kabelgebundene Verbindung

--- Welche Netzwerktopologie liegt vor?
--- (2) DSL HW router <---> LinuxClient

--- Auf welchem Rechner wird das Script ausgeführt?
--- (1) LinuxClient

--- NWCollect sammelt Netzwerkkonfigurationsinformationen in Datei network_test.txt ...

--- NWEliza untersucht das System nach häufigen Netzwerkkonfigurationsfehlern ...
!!! CND0110E: Es wurde keine aktives Netzwerkinterface auf dem System für der gewählten Verbindungstyp gefunden

--- Gehe zu http://www.linux-tips-and-tricks.de/CND um detailliertere Hinweise
--- zu den Fehlermeldungen/Warnungen zu bekommen und wie die Fehler selbst beseitigt werden können.

--- Wenn eigene Lösungsversuche erfolglos waren dann den Inhalt der Datei network_test.txt im Netz ablegen
--- (Links siehe http://www.linux-tips-and-tricks.de/CND_UPL)
--- und dann der nopaste Link im bevorzugten Linux Forum posten.

==================================================================================================================
===== cat /etc/*[-_]release || cat /etc/*[-_]version =============================================================
/etc/centos-release
/etc/os-release
/etc/redhat-release
/etc/system-release
CentOS Linux release 7.7.1908 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.7.1908 (Core)
CentOS Linux release 7.7.1908 (Core)
===== uname -a ===================================================================================================
Linux server3.fritz.box 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18 17:15:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
===== cat /etc/sysconfig/network-scripts/ifcfg-[earwd]* | grep -v "^#|^$" | grep -v "=''" ========================
--- /etc/sysconfig/network-scripts/ifcfg-eno1
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=@@@@@@
UUID=xxx
DEVICE=eno1
ONBOOT=yes
IPADDR=192.168.0.3
PREFIX=24
GATEWAY=192.168.0.1
DNS1=192.168.0.1
IPV6_PRIVACY=no
ZONE=public
--- /etc/sysconfig/network-scripts/ifcfg-eno1.bak
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=@@@@@@
UUID=xxx
DEVICE=eno1
ONBOOT=yes
IPADDR=192.168.0.3
PREFIX=24
GATEWAY=192.168.0.1
DNS1=192.168.0.1
IPV6_PRIVACY=no
===== ping tests =================================================================================================
Ping of 8.8.8.8 OK
Ping of www.google.com OK
===== cat /etc/resolv | grep -i "nameserver" =====================================================================
nameserver 192.168.0.1
===== cat /etc/hosts =============================================================================================
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
===== (route -n && route -A inet6 -n) | egrep "(en|wl|eth|ath|ra|wlan|dsl|ppp)" ==================================
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 eno1
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eno1
Kernel IPv6 Routentabelle
fe80::/64                      ::                         U    100 0      4 eno1
ff00::/8                       ::                         U    256 2      7 eno1
===== ifconfig (filtered for en|wl|eth|wlan|ra|ath|dsl|ppp) ======================================================
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.3  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 xxx  prefixlen 64  scopeid 0x20<link>
        ether ##:##:##:##:##:#1  txqueuelen 1000  (Ethernet)
        RX packets 868623181  bytes 1075133191537 (1001.2 GiB)
        RX errors 0  dropped 4070462  overruns 0  frame 0
        TX packets 279203574  bytes 159534229610 (148.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
===== lspci ======================================================================================================
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c)
        Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet [1458:e000]
        Kernel driver in use: r8169
        Kernel modules: r8169
===== lsusb | grep -v "root hub" =================================================================================
Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
===== lshw -C network (filtered) =================================================================================
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp aui bnc mii fibre 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 duplex=full firmware=rtl8168g-2_0.0.1 02/06/13 ip=192.168.0.3 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
===== lsmod (filtered) ===========================================================================================
| ablk_helper     | aesni_intel     | ahci            | ansi_cprng      | coretemp         |
| dm_log          | dm_mirror       | dm_region_hash  | drbg            | drm              |
| drm_kms_helper  | drm_panel_orientation_quirks| ebtable_broute  | ebtable_filter  | ebtable_nat      |
| ebtables        | fb_sys_fops     | gf128mul        | ghash_clmulni_intel| glue_helper      |
| i2c_algo_bit    | i2c_i801        | i915            | intel_powerclamp| intel_rapl       |
| iosf_mbi        | ip_set          | ip_tables       | irqbypass       | jbd2             |
| kvm             | kvm_intel       | libahci         | libata          | llc              |
| lrw             | mbcache         | nfnetlink       | nvme            | nvme_core        |
| pinctrl_geminilake| pinctrl_intel   | ppdev           | r8169           | sd_mod           |
| serio_raw       | sg              | stp             | syscopyarea     | sysfillrect      |
| sysimgblt       | uas             | usb_storage     | xfs             |
===== egrep 'en|wl|eth|ath|wlan|ra|ppp' /etc/udev/rules.d/*net_persistent* /etc/udev/rules.d/*persistent-net* ====
==================================================================================================================
*** NWElizaStates
PNIN:1 CFR:1 DI:0 FALON:1 NI:1 cNI:1 NIWD:0 IP6:0 WLW:0 RTDT:redhat GUI:0 UID:0
 
OP
K

kruppa

Ich habe eine Fritz!Box Cable 6591, die ist mit einem Switch verbunden und dort hängt der Fileserver dran. Ein Windows Notebook am selben Kabel hat bei speedtest.net über 900Mbit/s erreicht.
 
S

spoensche

Code: 
dropped 4070462

Auf deinem Netzwerkinterface werden sehr viele Pakete gedroppt. Das führt bei TCP zu einem Retransmit der Pakete. Bei UDP hingegen werden die gedroppten Pakete nicht erneut versendet.

Ursachen für den Paketverlust kann z.B. das Vollaufen der Queue des Netzwerkinterface sein, eine gestörte Verbindung zum Provider etc.

Eine weitere Ursache kann IPv6 sein.

Sieh mal auf deiner Fritzbox nach, wie der Status zum Vodafone Zugangspunkt ist. Ggf. mal neu synchronisieren.

Wenn du kein IPv6 verwendest, dann schalte es ab.
Dazu öffnest du die Datei /etc/sysctl.d/99-sysctl.conf in einem Editor und fügst folgendes ein:

Code: 
net.ipv6.all.conf.disable_ipv6

Anschließend einen Reboot durchführen.

Poste mal die Ausgabe von
Code: 
ethtool -k eno1
 
OP
K

kruppa

Das Abschalten von IPv6 scheint nichts gebracht zu haben.

Code: 
ethtool -k eno1

liefert:

Code: 
Features for eno1:
rx-checksumming: on
tx-checksumming: off
        tx-checksum-ipv4: off
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: off
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: off
        tx-scatter-gather: off
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: off
        tx-tcp-mangleid-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
busy-poll: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
rx-gro-hw: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
 
S

spoensche

Häufige Ursache für fehlerhafte Checksummen im Header ist das Ofloading auf die Karte.

Schalte mal GRO aus.
Code: 
ethtool -K GRO off eno1

Poste mal bitte die Memory Konfig deines Interfaces.

Code: 
ethtool -g eno1
 
OP
K

kruppa

Da bekomme ich leider nur einen Fehler:

Code: 
ethtool -g eno1
Ring parameters for eno1:
Cannot get device ring settings: Operation not supported
 
S

spoensche

Führe bitte mal den Speedtest von http://www.dslreports.com/speedtest aus und poste die Werte von Down- Up Stream und den Bufferbloat.
 
OP
K

kruppa

Der Download war da ziemlich gut, bei speedtest.net aber immer noch wie bisher.

http://www.dslreports.com/speedtest/65994222
 
S

spoensche

Die Geschwindigkeit bei dsl-reports ist gut. Durch Optimierung der Send- Receive Buffers könnte man evtl. noch etwas heraus holen.
Durch Traffic Shaping kann noch der Buffer bloat verbessert werden, also von C auf B. Ein Buffer Bloat entsteht, wenn die Paketqueue deines Kabelmodems voll ist, weil die Pakete nicht schnell genug gesendet werden können. Dies hängt mit der Queue auf der Provider Seite zusammen.

Klar könnte man jetzt noch Diskutieren, welcher Speedtest den der genauere ist, allerdings ist für einen genauen Vergleich der Quellcode nötig, um beide Messverfahren zu vergleichen.

Fazit. Es liegt nicht an deiner Leitung oder Konfiguration, sondern am verwendeten Speedtest.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben