Wlan um das 2- bis 3-fache schneller bei Dateiübertragung?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo

    ich bin etwas überrascht und suche nach einer Erklärung - und dann ggf. nach Abhilfe.
    Ich habe auf dem RPi4 einen Medienserver aufgesetzt, übertrage jetzt auf eine USB-Festplatte die Dateien über SMB, nutze dazu GoodSync. Über LAN zeigte mir GoodSync Transfergeschwindigkeiten zwischen 30 und 60 MB/s Sekunde an. Über WLAN liege ich zwischen 100 und 120 MB/s, kleine Ausreisser nach unten bis 80 MB/s - und das bei gleicher Quelle und gleichem Ziel.

    Meine Frage: woher kommt dieser große Unterschied? Ganz egal, ob ich den absoluten Werten von 120 MB/s traue, die da angeblich auf die Raid0 im Raspi geschrieben werden - hier geht's ja um den relativen Unterschied.

    Damit Ihr das einschätzen könnt, hier das "Setup".

    Quelle: WHS Server von HP -> FritzBox 7590 per Gigabit-LAN -> RPi4 im Geekworm Gemini Dual 2.5 V2 Gehäuse (bindet 2 Festplatten per USB und Raid-Controller ein), 2x5TB Seagate als Raid0, EXT4 formatiert. LAN Kabel sind Cat 8.1, beim WLAN zeigt die FritzBox 5 GHz, 292 / 260 Mbit/s

    Könnt Ihr's erklären? Und gibt es ggf. etwas, das ich am LAN bzw. der Konfiguration im RPi4 ändern kann - am Einbinden der Festplatte und an der Samba-Konfiguration kann's ja nicht liegen...

    Vielen Dank!

  • Wlan um das 2- bis 3-fache schneller bei Dateiübertragung?? Schau mal ob du hier fündig wirst!

  • ... dem RPi4 ... zeigte mir GoodSync Transfergeschwindigkeiten ...


    Könnt Ihr's erklären?

    Wie sind auf deinem PI4, die Ausgaben (in code-block) von:

    Code
    ethtool eth0
    ip a
    ip r

    ?

    Ist dein PI4 evtl. _gleichzeitig_ per LAN und per WLAN mit der FritzBox verbunden?

    Mach mal mit aktiviertem iperf(3?) auf deiner FritzBox, einen Übertragungstest zwischen FritzBox und PI4, wenn a) dein PI4 _nur_ per LAN mit der FritzBox verbunden ist und b) wenn dein PI4 _nur_ per WLAN mit der FritzBox verbunden ist.

    EDIT:

    BTW: 100 MB/s sind 800Mbit/s

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (13. Februar 2023 um 09:34)

  • Erstens solltest du nicht Megabyte und Megabit verwechseln/mischen. Oder zumindest richtig kennzeichnen. Zweitens zeigt deine Fritzbox vermutlich Murks an, da wohl noch immer folgendes gilt: RE: Wie schnell sollte W-Lan beim PI 4 sein?

    bitte, ich hab doch klar gesagt „Goodsync zeigt mir …. MB/s an“, die FRITZ!Box sagt über die WLAN Verbindung „…MBit/s“ - das sind doch klar formulierte Zuordnungen und alles Werte, die einschätzen lassen, ob die angezeigte Qualität der WLAN Verbindung der FRITZ!Box solche Datenraten der Datei-Übertragung überhaupt zulässt. War also richtig gekennzeichnet, sogar mit dem Zusatz „… ob ich diesen Werten traue …, es geht um den relativen Unterschied“.

    Betonung auf relativ - hätte ich nur geschrieben „Goodsync zeigt mir eine dreimal schnellere Übertragung per WLAN an“ hättet ihr nach den absoluten Werten gefragt, die Goodsync mir anzeigt.

    2 Mal editiert, zuletzt von dvdr (13. Februar 2023 um 21:03)

  • Wie sind auf deinem PI4, die Ausgaben (in code-block) von:

    Code
    ethtool eth0
    ip a
    ip r

    rpi444 ich hoffe, das passt so. Danke für Deine Hilfe!

    ip Adresse …40 ist LAN , …44 ist WLAN

    Code
    ip r
    default via 192.168.178.1 dev eth0 proto dhcp src 192.168.178.40 metric 202 mtu 1500 
    default via 192.168.178.1 dev wlan0 proto dhcp src 192.168.178.44 metric 303 mtu 1500 
    192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.40 metric 202 mtu 1500 
    192.168.178.0/24 dev wlan0 proto dhcp scope link src 192.168.178.44 metric 303 mtu 1500
  • ip Adresse …40 ist LAN , …44 ist WLAN

    Code
    ip r
    default via 192.168.178.1 dev eth0 proto dhcp src 192.168.178.40 metric 202 mtu 1500 
    default via 192.168.178.1 dev wlan0 proto dhcp src 192.168.178.44 metric 303 mtu 1500 
    192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.40 metric 202 mtu 1500 
    192.168.178.0/24 dev wlan0 proto dhcp scope link src 192.168.178.44 metric 303 mtu 1500

    Die metric (202) via Lan ist besser als die metric (303) via Wlan, d. h. der Traffic ist immer via Lan. Hast Du zum testen, die Lan-Verbindung bzw. die Wlan-Verbindung deaktiviert gehabt?

    Teste mal mit dem iperf3-Server der FritzBox. Oder hat die FB7590 (mit FW 7.50) schon den iperf4-Server?

    EDIT:

    Teste mal auch mit:

    Code
    wget -4 -c -O /dev/null http://129.143.4.238/1G
    wget -4 -c -O /dev/null http://download.thinkbroadband.com/1GB.zip

    Wenn Du natives IPv6 hastm dann mit:

    Code
    wget -6 -c -O /dev/null http://ipv6.download.thinkbroadband.com/1GB.zip

    BTW: Kann es evtl. sein, dass GoodSync auch als "download accelerator" fungieren kann?

    MB sind immer MegaBytes:

    Code
    /dev/null                      100%[==================================================>]   1.00G  6.22MB/s    in 2m 47s  
    
    2023-02-14 12:21:20 (6.12 MB/s) - '/dev/null' saved [1073741824/1073741824]

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (14. Februar 2023 um 12:32)

  • Laut Raspberry Pi Fondation schafft der RPi 4 bei 5GHz WLAN ca. 114 MBit/sec. (siehe Link oben). Also maximal 10-12 Megabyte / Sekunde. Deine Werte weichen davon erheblich ab. Irgend etwas stimmt also nicht. Vermutlich hast du LAN (Gigabit) gemessen. Daher auch mein Hinweis/Vermutung auf Megabyte und Megabit nicht verwechseln: Die Megabyte Werte könnten nämlich eher Megabit Werte sein.

  • mein alter Pi3 hatte 5m vom Router nur 58Mbit geschafft, mit externen USB wlan Stick 178 Mbit, war aber trotzdem nicht möglich ruckelfrei einen Film vom NAS zu schauen am LAN mit 100 Mbit kein Problem.

    Ich hatte mal den Fall das am PC wlan schneller war als LAN aber da war mein dLink Router kaputt.

    zwischen 100 und 120 MB/s

    gewöhne dir bitte an Bit und Byte auszuschreiben, sollen wir etwa raten was du mit B meinst? :conf:

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Das wäre etwas doof, wenn GoodSync nicht zwischen Megabyte, Mebibyte und Megabit unterscheiden kann.

    Ich würde zuerst iperf3 auf einem System starten, dass an dem Router mit 1GBit/s angebunden ist.

    Code
    iperf3 -s

    Auf dem Client lässt du dann den iperf3 client laufen:

    Code
    iperf3 -c IP-SERVER

    Am besten einmal nur mit LAN und dann einmal nur mit WLAN, um Konfusion zu vermeiden.

  • Ich würde zuerst iperf3 auf einem System starten, dass an dem Router mit 1GBit/s angebunden ist.

    BTW: Die FritzBox ist für diesen Test, nicht geeignet. Die Lan-Ports der FritzBox sind für Giga-bit konfiguriert. Z. B.:

    Spoiler anzeigen
    Code
    :~# iperf -s
    ------------------------------------------------------------
    Server listening on TCP port 5001
    TCP window size: 12.0 MByte (default)
    ------------------------------------------------------------
    [  4] local 192.168.178.13 port 5001 connected with 192.168.178.40 port 57590
    [ ID] Interval       Transfer     Bandwidth
    [  4] 0.0000-10.0113 sec   135 MBytes   113 Mbits/sec

    bei:

    Code
    :~# ethtool eth0 | grep -iE 'speed|duplex'
        Speed: 1000Mb/s
        Duplex: Full
    Code
    :~ # iperf -c 192.168.178.13
    ------------------------------------------------------------
    Client connecting to 192.168.178.13, TCP port 5001
    TCP window size: 64.0 KByte (default)
    ------------------------------------------------------------
    [  1] local 192.168.178.40 port 57590 connected with 192.168.178.13 port 5001
    [ ID] Interval       Transfer     Bandwidth
    [  1] 0.00-10.01 sec   135 MBytes   113 Mbits/sec

    bei:

    Code
    inet 192.168.178.40 netmask 0xffffff00 broadcast 192.168.178.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

    Wenn, dann sollte man die beiden Geräte, direkt per Lan-Kabel untereinander verbinden und testen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hallo
    nochmal kurz zu Euren Anmerkungen von Bit und Byte - mir ist schon klar, dass das relevant ist. In dem Fall bitte ich um Verständnis: ich kann leider nur das zitieren, was mir die jeweilige "Kiste" oder Software anzeigt. Leider ist GoodSync halt so programmiert, dass da Mb/s steht. Ist also keine böse Absicht - auch wenn's Euch dann natürlich nervt. In meiner Analyse vergleiche ich dann einfach zwei (falsch benamste) Messwerte - einmal per LAN, einmal per WLAN - und sehe den relativen Unterschied und frage mich, was da passiert.
    Auf jeden Fall danke für Euer Feedback und die Vorschläge, wie man dem Phänome auf die Schliche kommen kann - Ihr habt mir jetzt ja eine Strategie an die Hand gegeben, wie ich mögliche Messfehler umschiffen kann.

    Leider hat sich das mit dem Testen erstmal erledigt: das Geekworm-"Chassis" (Gemini Dual 2.5 V2) , in dem der RPi4 eingebaut ist, hat den Geist aufgegeben. Vermutlich der Raid-Controller-Chip, der beiden verbauten 2.5" Festplatten anspricht. Ersatz ist auf dem Weg.

    Eine letzte Frage: Ich bin kein Coder, aber könnt Ihr entziffern, was und wie das Skript das macht, mit dem sich der Geekworm per Power-Knopf ausschalten bzw. rebooten lässt? Kurz auf den Hardware Button drücken soll einen Reboot auslösen, 2-3 Sekunden einen Shutdown und 8 Sekunden einen harten Shutdown, also sozusagen Netzstecker ziehen.

    Als erstes wird die Installation des Skripts über diese Befehle vorgenommen

    und wenn ich mir das .sh aus der vorletzten Zeile ansehe, dann steht dort

    Passiert in den Skript irgendetwas, das eher einen forced shutdown auslöst, aka "Stromstecker zieht"?
    Wenn ich nämlich früher den Raspi per "sudo shutdown" heruntergefahren habe, dann brauchte der deutlich länger als 4 Sekunden, bis man dann auch bei der USB-Festplatte hörte, dass sie abschaltet. Jetzt kommt nach 4 Sekunden ein lautes, sattes "Klack" der im Geekworm verbauten Festplatten und weg ist der Strom.
    Das hört sich exakt so an, wie wenn ich den Power-Knopf 8 Sekunden drücke, also nach "Stromstecker ziehen". Und wenn ich dend Reboot über dieses Skript auslöse, dauert das Herunterfahren auch deutlich länger, bevor ich höre, dass die Festplatten kurz abschalten und dann der Raspi wieder bootet.
    Klingt also irgendwie gar nicht gesund für den Raspi.

  • In dem Fall bitte ich um Verständnis: ich kann leider nur das zitieren, was mir die jeweilige "Kiste" oder Software anzeigt.

    dann notiere die Uhrzeit und kopiere nach power on eine 1-4 GB Datei von/nach Netzwerk, NAS oder anderer Computer, jeweils immer nach power on.

    Dann rechne halt wie lange das dauert dann weisst du das, bei der Größe GB sollte es offensichtlich werden ob Byte oder Bit pro Sekunde gemeint ist.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!