Netzwerkprobleme mit Managed Switch 2.5G mit SFP+

[Datanette]

Hallo zusammen,
benötige wieder mal Unterstützung von Netzwerk-Verstehern.

Seit geraumer Zeit habe ich sporadisch Netzwerkprobleme.
Das äussert sich in gedrosselten Maximalgeschwindigkeiten bis hin zu totalem Stillstand einzelner Verbindungen im Heimnetz. Wenn ich dann die betroffenen Geräte neu starte oder den ersten managed-switch reboote, funktioniert es wieder für eine Weile, aber trotzdem mit Problemen (stetig etwas gedrosselte Geschwindigkeit und packet-drops). Manchmal gehts nach einer Pause von selber wieder.

Nach einer ausgiebigen Suche habe ich die beiden managed-switches als Übeltäter identifizieren können. Beobachten kann ich dies durch den Netzwerkmonitor am NAS (unraid), dort beobachte ich jede Sekunde einen drop beim receive-counter. Wenn ich die beiden Switches durch andere (unmanaged) austausche, fallen die drops und die Maximalgeschwindigkeit wird wieder erreicht. Es gibt dann zwar noch drops, aber nicht mehr sekündlich.

Die Switches sind per LWL am 10G-SFP+port verbunden und überbrücken eine Distanz von 50m zwischen zwei Gebäuden.
Es handel sich um zwei Billigdinger von ali welche es von verschiedenen Brands gibt. (mit RTL8373/8224)

AMPCOM 2.5GbE Managed Switch 8 Port 2.5GBASE-T Network Switcher 10G SF

Buy 9 Port 2.5G Web Smart Managed Ethernet Switch with 10Gbps SFP Uplink,Compatible with 100/1000/2500Mbps Network, 2.5Gbps Management Switch Easy for 2.5Gb NAS,PC,WiFi6 Router,Wireless AP. with fast shipping and top-rated customer service. AMPCOM Management Switch Selection.

www.ampcom.com

Ich hatte mir die managed-switches mal zugelegt mit dem Hintergedanken, ein V-Lan für IOT zu erstellen, was ich aber noch nicht gemacht habe. Zudem fehlt mir etliches an Basis-Wissen, was Netzwerk an geht um dieses Problem selber zu lösen.

Kann sich das mal jemand anschauen, bitte. Vielleicht fällt dem Profi sofort auf, wo es hakt. Ich hoffe noch immer, dass es durch Einstellungen behoben werden kann.
FW ist aktuell. Settings alles auf standard. Ist das LWL-Signal noch stark genug, was da ankommt? Im Moment ist nur einer der managed-switches installiert, der andere ist ein unmanaged-switch, die Fehler sind aber die gleichen.

Die SFP+ Module und der LWL sind zwar auch Billigkram von ali, aber ich kann diese nicht wirklich als Verursacher identifizieren, denn selbst wenn nur ein managed-switch ohne LWL genutzt wird, bestehen diese Probleme.

 

[Eye-Q]

So wie Du das erklärst ist leider noch einiges unklar, weil Du nur die beiden Switches beschrieben hast. Kannst Du mal bitte versuchen, alle physischen Netzwerkverbindungen aufzuzeichnen? Was für andere Switches und Geräte sind im Netzwerk vorhanden? Wie hast Du das ohne LWL getestest, wenn die beiden Switches in unterschiedlichen Gebäuden sind?

 

[radicale]

Vor 4 Wochen hatte ich auch solche Switches im Einsatz, 8x 2,5 Gbit und 2x SFP+. Findet man auch bei dem großen Fluss im Angebot teilweise sogar noch billiger.

Zum Anfang hin haben die Teile (2 Stück mittels SFP+ 10Gbit) problemlos in Betrieb gehabt. Probleme gab es dann, als so langsam Last auf die Verbindungen gegeben wurde. Sobald ich 2 Port's 2,5 GBit mit 50 % Dauerlast ausgelastet habe, haben die Probleme angefangen. Anfänglich mit Drops bis hin zu Verbindungsabbrüchen. Stellenweise wurden die Verbindungen heruntergehandelt auf 1 Gbit. Sobald die Teile wieder weniger Last hatte, war das Problem auch wieder beseitigt. Entweder die Chips sind der letzte Dreck oder die Kühlung der Kisten ist ein Alptraum.

Qualität kostet doch eben etwas mehr.

 

[Datanette]

Vor 4 Wochen hatte ich auch solche Switches im Einsatz, 8x 2,5 Gbit und 2x SFP+. Findet man auch bei dem großen Fluss im Angebot teilweise sogar noch billiger.

Zum Anfang hin haben die Teile (2 Stück mittels SFP+ 10Gbit) problemlos in Betrieb gehabt. Probleme gab es dann, als so langsam Last auf die Verbindungen gegeben wurde. Sobald ich 2 Port's 2,5 GBit mit 50 % Dauerlast ausgelastet habe, haben die Probleme angefangen. Anfänglich mit Drops bis hin zu Verbindungsabbrüchen. Stellenweise wurden die Verbindungen heruntergehandelt auf 1 Gbit. Sobald die Teile wieder weniger Last hatte, war das Problem auch wieder beseitigt. Entweder die Chips sind der letzte Dreck oder die Kühlung der Kisten ist ein Alptraum.

Qualität kostet doch eben etwas mehr.

Bei mir gibt es selbst ohne Last, also +/- im Idle Betrieb schon drops. Ich bilde mir ein, dass das nicht seit Anfang schon so war.
Also meinst du, das liegt an der nicht vorhandenen Qualität der Dinger? Waren das bei dir die selben Chipsätze?

@Eye-Q So wie ich inzwischen herausgefunden habe, hat der Netzwerkaufbau in dem Sinne keine wirkliche Relevanz, da die Fehler schon auftreten, wenn über den ersten Switch irgende etwas an Daten läuft, unabhängig davon, ob der LWL angeschlossen ist oder nicht. Die drop-Fehler sind konstant bei min. 1x pro Sekunde, egal ob belastet oder nicht. Es scheint fast so als würden die Fehler im Switch produziert und hätten nicht mal was mit dem traffic zu tun.

Beitrag automatisch zusammengeführt: 11.02.2026

Falls dem wirklich so ist, stellt sich mir die Frage, gibt es solche einfachen managed-switches mit 8x2.5G und 1-2SFP+ ports schon für kleines Geld die auch einen Taug haben?

Beitrag automatisch zusammengeführt: 11.02.2026

edit:
Die Hizeentwicklung allein kann es nicht sein, denn die drops starten, sobal das Ding an ist. Auch die Verbindungen wurden nie heruntergehandelt, selbst bei den total Unterbrüchen.

 

[74181]

"Receive drops" sind etwas anderes als "recieve errors". Erstere können beispielsweise entstehen, wenn die TTL der eingehenden Pakete 1 oder 0 ist. Oder wenn das Protokoll nicht unterstützt wird. Letztere würde ich bei Übertragungsproblemen erwarten.

Bei den Screenshots Deines Switches sehe ich keine receive drops oder errors? Bei dem Interface eth0 schon. Von welchem Gerät ist das? Dein PC? Du könntest dort mal Wireshark starten. Es würde mich nicht wundern, wenn es Netzwerk-Management-Pakete sind - zumal Du ja als Häufigkeit auch ungefähr 1/s erwähnst.

Du könntest testweise möglichst viele Management-Funktionen Deiner Switches abschalten (insbesondere IGMP) und schauen, ob es besser wird.

 

[Datanette]

@74181 Danke für deine Tipps, wie du siehst, habe ich absolut keinen Plan.
Diese receive drops sehe ich auf meinen NAS und den beiden Backup-Servern, alles unraid. Ich bin davon ausgegangen, dass meine Netzwerkprobleme damit zusammenhängen. Der maximalspeed ist durchgehend etwas gedämpft und manchmal (bei größerer Last) bricht der traffic auf 1MB/s ein, das bleibt dann eine Weile so oder ich reboote den Switch oder den Server.
IGMP ist deaktiviert. Eigentlich ist standardmässig alles deaktiviert an dem managed-switch.

Mit Wireshark kenne ich mich nicht aus, würde es damit gerne mal versuchen. Woran erkenne ich denn Netzwerk-Management-Packete?

Beitrag automatisch zusammengeführt: 11.02.2026

edit:
Habe wireshark nun mal als container installiert und versuche morgen, wenns ruhiger ist, was rauszufinden.

 

[74181]

Na ja, Wireshark zeigt alle Pakete an, die an einem Interface gesendet oder empfangen werden. In der Spalte "Protocol" steht TCP, UDP, ICMP, HTTP, TLS, QUIC, Wireguard, usw. für Datenverkehr und IGMP, CDP, STP, RSTP, EIGRP, BGP usw. für Netz-Management Verkehr.

Das Problem ist häufig, dass sehr viele Pakete ein- und ausgehen. Dadurch sieht man den Wald vor lauter Bäumen... ähh Paketen nicht mehr. Man kann entweder Filter in Wireshark setzen. Oder man sorgt dafür, dass man eine freie Leitung hat und nur die gewünschten Pakete über die Leitung gehen. Manchmal muss man ein bisschen experimentieren, bis man das Ergebnis hat.

In Deinem Fall könntest Du gleichzeitig den Receive Drop Zähler und die eingehenden Netzpakete betrachten - und schauen, ob Du eine Übereinstimmung findest. Vorher könntest Du alle PCs und Server aus dem LAN entfernen, damit diese nicht störenden Datenverkehr auf das Interface schicken, das Du gerade belauschst.

PS: Falls Du Wireshark nicht auf dem NAS laufen lassen kannst, gibt es als leichtgewichtige Form das Programm "tcpdump". Dieses kann Pakete auf einer Konsole anzeigen. Oder es kann den Datenverkehr in eine Dump-Datei schreiben. Diese kann man auf einem anderen Rechner kopieren, in Wireshark öffnen und dort analysieren. Siehe: Capturing with “tcpdump” for viewing with Wireshark

PPS: Manche Switche und Router können ein- und ausgehende Daten auch direkt in eine Dump-Datei schreiben. Auch diese kann man auf einem anderen Rechner kopieren, in Wireshark öffnen und dort analysieren.

 

[Datanette]

Danke vielmals, das werde ich morgen mal versuchen und berichten.

 

[Datanette]

Inzwischen habe ich soweit nachgeforscht, wie ich konnte/wusste mit folgendem Ergebnis.
Diese RX-drops konnte ich auch auf dem PC beobachten, da läuft Wireshark auch besser als im Docker auf dem NAS.

auch hier auf dem PC mindestens jede 2. Sekunde ein RX-drop: (Auf dem NAS sind es häuffigere drops, jede Sekunde einer.)

user@user:~$ ifconfig
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.11  netmask 255.255.255.0  broadcast 192.168.1.255
        ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 3415373  bytes 4570469355 (4.5 GB)
        RX errors 0  dropped 3540  overruns 0  frame 0
        TX packets 511606  bytes 2604055380 (2.6 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Lokale Schleife)
        RX packets 1182  bytes 127108 (127.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1182  bytes 127108 (127.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Habe dann nochmals auf dem NAS aufgezeichnet und am PC ausgewertet. Anhand Wireshark ist es folgendes und nach deaktivieren im Switch sind die RX-drops praktisch alle weg.

89357    33.043802366    HongRuiOptic_24:16:f5    Broadcast    RLDP    60    Network Loop Detection

Das timeinterval ist hier zwar auf 2sec. gesetzt, aber das dürften beide switches simultan gemacht haben.

Somit wäre das erste Rätsel soweit gelöst. Super, danke vielmals an die Helfer!
Es fragt sich, ist das dann ganz normal, wenn loop-detection eingeschaltet ist?

Ich werde das jedenfalls mal aus lassen, denn in meinem kleinen Netzwerk ist die Gefahr recht klein, dass loop-detection zum Tragen kommt.
Ob ich das mal eingeschaltet habe oder standard ist, wer weiß?

Auch das zweite Problem ist damit schon behoben. Traffic speed ist wieder so schnell wie gewohnt.
Es fragt sich nur noch, was diese sporadischen Totalstillstände mit Drosselung auf 1MB/s auslöst oder ausgelöst hat. Ich bin gespannt, ob die nun auch weg sind.

----

Eine andere Frage noch. Da der Switch mit der neuen FW das SFP-modul auslesen kann, kann man die Temperaturen dessen beobachten.
Kann jemand sagen, wo diese Temperatur gemessen wird und ab wann das kritisch wird?
Und wie kann man die Output power (dBm) Werte einordnen.

 

[74181]

Somit wäre das erste Rätsel soweit gelöst. Super, danke vielmals an die Helfer!
Es fragt sich, ist das dann ganz normal, wenn loop-detection eingeschaltet ist?

Erst mal toll, dass Du den Netzwerkverkehr ausgewertet hast und den Grund für die "receive drops" gefunden hast!

Wenn man mehrere Switches hat, kann es recht schnell passieren, dass man eine Loop schaltet. Man bekommt das auch mit einem einzigen Switch hin: Kabel zu sich selbst. Wenn man solche Loops hat, können Broadcast-Stürme entstehen: ein Rechner schickt ein Broadcast-Paket (ein Paket an alle anderen Netzteilnehmer). Das fließt dann im Kreis und wird immer und immer wieder an alle Teilnehmer verschickt. So lange, bis die TTL bei 0 ist. Bei großen Netzen und wenn viele Teilnehmer Broadcast-Pakete schicken, kann man damit mühelos das ganze Netz lahmlegen.

Deshalb gibt es Loop Detection Protokolle wie STP oder auch RLDP. Sie versuchen, solche Loops zu entdecken. Wenn sie eine Loop feststellen, werden die entsprechenden Ports gesperrt.

Das ist keine Boshaftigkeit, sondern ein wichtiges Feature. Ohne das könnte man keine größeren LANs aufbauen.

Wenn man ein kleines LAN hat, kann man Loop Detection ausschalten. Wenn man doch eine Loop haben sollte, muss man mit dem Ärger leben.

Ein weiterer Nachteil der Loop Detection und anderer Selbstschutz-Protokolle ist, dass man häufig nicht sofort eine Verbindung bekommt, wenn man einen Rechner neu an einen Switch anschließt, sondern dass es ein paar Sekunden bis zu einer halben Minute dauern kann. Profi-Switches reagieren manchmal auch sehr unwirsch, wenn man den Port wechselt. Das sollte man im Hinterkopf behalten, wenn man mit solchen Switches arbeitet.

Auch das zweite Problem ist damit schon behoben. Traffic speed ist wieder so schnell wie gewohnt.
Es fragt sich nur noch, was diese sporadischen Totalstillstände mit Drosselung auf 1MB/s auslöst oder ausgelöst hat. Ich bin gespannt, ob die nun auch weg sind.

Das ist merkwürdig. Loop Detection sollte nicht zu diesem Verhalten führen...

 

[Datanette]

@74181 Ich danke dir nochmals herzlich für deine Hilfe. Konnte ich doch wieder etwas lernen, was mein nicht so sehr gemochtes Thema "Netzwerk" betrifft.

Diese Billiglösungen sind wohl nicht das gelbe vom Ei, kosten halt gerade mal einen viertel eines Brand-Produktes.
Für mich ist es ausreichend und ich bin froh darüber, nicht nochmals kaufen zu müssen. Vielleicht gibt es mal noch einen Fix per FW dafür.

Da hat kürzlich etwas am Chipsatz geändert und die Teile haben andere FW als gehabt, obwohl die Modellnummern gleich geblieben sind. Falls jemand auf diesen Thread stoßen sollte und einen ähnlichen Switch mit RTL8373/8224 und einer FW HRRF_V200.x.x gekauft haben sollte, dem kann ich sagen, dass das Ampcom WAMJHJ-8125MNG baugleich mit dem Sodola SL902-SWTGW218AS ist und die FW identisch ist. Da gibt es bestimmt noch ein paar andere von KeepLink, Horaco etc.
Dies ist vielleicht auch noch interessant: https://github.com/logicog/RTLPlayground


Hat vielleich jemand noch eine Idee dazu?

Eine andere Frage noch. Da der Switch mit der neuen FW das SFP-modul auslesen kann, kann man die Temperaturen dessen beobachten.
Kann jemand sagen, wo diese Temperatur gemessen wird und ab wann das kritisch wird?
Und wie kann man die Output power (dBm) Werte einordnen.

 

[74181]

@Datanette: wie schon gesagt: ich glaube nicht, dass Loop Detection zu den von Dir beschriebenen Leistungseinbrüchen führt. Es könnte sich natürlich um einen Bug auf dem Switch handeln - aber das halte ich für unwahrscheinlich.

Wahrscheinlicher ist, dass es doch ein Problem auf Deinem Link oder in Deinem Netz gibt. Vielleicht tritt es nur manchmal oder nur selten auf? Wenn Du nur ab und zu Daten übers Netz schickst, klappt es vielleicht und Du siehst den vollen Durchsatz? Wenn regelmäßig kleine Pakete übers Netz geschickt werden (Loop Detection), ist vielleicht eines davon betroffen? Der Switch merkt es und schaltet (temporär) in einen anderen Übertragungsmodus? Oder es gibt Probleme mit den Mac Adressen - und die Switches haben zeitweise falsche Weiterleitungs-Tabellen?

Ich würde das weiter untersuchen. Beispielsweise könnte man Loop Detection ausgeschaltet lassen, aber zwei Rechner Pings durch das Netz hin- und herschicken lassen. Das wären dann auch 2 Pakete pro Sekunde. Treten die Leistungseinbrüche dann auch auf?

Es gibt auch Tools, die Latenzen und/oder Durchsatz jede Minuten messen und das schön als Diagramm über ein oder zwei Tage darstellen. Wenn man solche Diagramme mit Loop Detection, ohne Loop Detection und mit Pings zwischen zwei Rechnern erstellt, kann man i.d.R. eine Menge erkennen. Insbesondere sieht man, wann und wie häufig die Probleme auftreten.

Gibt es Log-Einträge auf den Switches? Oder zeigen die dortigen TX oder RX error counter etwas an?

Ich kann Dir von hier aus nicht wirklich helfen. Aber ich kann versuchen, Dich in die richtige Richtung zu schubsen: testen und monitoren, bis Du den tatsächlichen Grund gefunden hast. Scheinlösungen "ich schalte Loop Detection aus und dann geht es" fallen einem früher oder später auf die Füße. Und zwar insbesondere dann, wenn man es überhaupt nicht gebrauchen kann.

 

[Datanette]

Okay, da hast du ziemlich sicher Recht. Für mich, als Laie sieht es auf den ersten Blick so aus, als wäre Loop Detection an allem Schuld gewesen.
Jedenfalls sind die Switches eines der entscheidenden Element. Als ich auf Fehlersuche war und die Switches durch unmanaged-Switches ausgetauscht hatte, war der Speed wieder schneller. Es ist nicht allzu viel, aber so ca 20-40%. Ich hatte öfters den Eindruck, dass vielleicht der Speed auf 1Gb/s herunter gehandelt wurde, weil meist so um die 100-110MB/s angelegen haben. Dem war aber nicht so.

Deswegen kann ist ein Fallback zu langsameren Verbindungsprotokollen ausschliessen, das habe ich öfters mal gecheckt, als es mir wieder mal aufgefallen ist, dass etwas nicht stimmt.
Dies sind leider alle Monitoring-Daten, welche der Switch ausgibt: (es gibt sonst keine anderen Logs)

-----

Während ich dies schreibe erinnere ich mich an eine weitere Sache die mir aufgefallen ist, als ich, vor ca einem halben Jahr, von Win10 auf Linux gewechselt bin.

Zu meinem usecase: Ich mache Backups auf zwei unraid Server, welche überwiegend dafür sind und auch nur währenddessen an sind. Sonst sind die immer aus und werden bei Bedarf per WOL geweckt. Dazu habe ich noch ein NAS mit unraid für div. Docker Container, kleinere VM's, Live-Backups, Samba Shares und als Download-Server, welches immer an ist.
Zwischen diesen Servern werden auch die Daten herumgeschoben und da fällt die Übertragungsgeschwindigkeit auf. Dies geschieht manuell oder automatisiert per FreeFileSync, aber immer vom PC aus.

Also, zu meiner Erinnerung. die Übertragungsgeschwindigkeit von Samba war unter Win schneller. Hatte mich da immer gewundert, was unter Linux wohl anders konfiguriert ist, mich aber nie damit beschäftigt. Da ich Win10 noch immer auf einer anderen SSD im System hängen habe, kann ich dies einfach rekonstruieren. Seither sind alle Komponenten im Netzwerk die selben, und am Switch habe ich bis auf FW-Updates nie etwas verändert.

Es ist also sehr wohl möglich, dass das wirkliche Problem noch im Verborgenen liegt.

 

[Datanette]

Es schaut wirklich so aus, als hätte ich zu sehr gehofft, das Problem gefunden zu haben.

Soeben habe ich mal Win10 mit Linux Mint verglichen und unter Samba-shares große Dateien mit FreeFileSync rumkopiert. Per PC von einem Backup-Server zum anderen Backup-Server.
Unter Win10 wird der Cache des unraid-Servers mit maxmaler HDD Lesegeschwindigkeit von bis zu 160MB/s gefüllt. Danach wird mit maximaler HDD Schreibgeschwindigkeit von ca. 120MB/s weiter kopiert.
Unter Linux konstant mit maximaler Geschwindigkeit von 60-80MB/s mit FreeFileSync vom PC aus.
Und konstant mit ca. 110-120MB/s mit Nemo vom PC aus. Ich weiß leider nicht, welches Programm Nemo zum Kopieren zwischen Samba shares nutzt.

Wenn ich nun Loop Detection aktiviere bleiben die Übertragungsraten gleich! ...gut... bin ich wieder wo ich schon mal war und es fragt sich, ob ich wirklich ein Netzwerproblem habe.

Ich möchte hier nun mal abbrechen, denn mein Geschreibe nützt wahrscheinlich nur noch mir, um meine Gedanken zu ordnen.

 

[74181]

Mach mal Folgendes: erstelle eine 10 GB große Datei unter Windows und miss die Zeit, die es dauert, um sie mit Windows Shell und "copy" auf Dein NAS zu kopieren. Miss auch die Zeit in der anderen Richtung.

Dann mache das gleiche unter Linux ("cp"). Bei der Zeitmessung solltest Du sicherstellen, dass die gesamte Zeit gemessen wird - und nicht nur die Zeit, bis die Daten in einen Cache kopiert sind. Es sollte also auch ein "sync" dabei sein.

FreeFileSync ist vermutlich kein guter Test, weil möglicherweise auch andere Dinge wie Latenzen oder Caches eine Rolle spielen.

Hast Du auch NFS aktiv? Dann miss auch unter NFS. Falls Du weißt, wie man mit scp ohne langsame Verschlüsselung kopiert, versuche auch das. Falls FTP aktiv ist, probiere auch das.

 

[74181]

Hier ein paar Testergebnisse von mir.

Mein Setup: ein kleiner, unmanaged 2.5 GBit/s Ethernet Switch mit 5 Ports (Trendnet TEG-S350). An dem Switch hängen u.a. ein Dateiserver (192.168.2.2) und ein PC (192.168.2.3) über Cat. 7 Ethernet-Kabel.

Auf dem PC (192.168.2.3):

1) Testdatei erstellen (Zufallszahlen, damit nicht komprimiert werden kann)

$ cd /tmp
$ dd if=/dev/random of=testdatei bs=1M count=10000

10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9,8 GiB) copied, 20,7418 s, 506 MB/s

$ ls -la
...
-rw-rw-r--  1  root  root  10485760000  Feb 12 19:59  testdatei
...

2) Test mit NFS Server

# mount -t nfs4 -o rw,nosuid 192.168.2.2:/export/scratch /mnt

$ sync; time ( cp testdatei /mnt; sync )

real    0m37,128s
user    0m0,005s
sys     0m3,722s
 
umount /mnt

Das sind 269 MB/s. Ganz ordentlich für eine 2.5 GBit/s Verbindung

3) Test mit Samba Server

# mount -t cifs -o user=XXXXX -o rw //192.168.2.2/scratch /mnt

$ sync; time ( cp testdatei /mnt; sync )

real    0m36.866s
user    0m0.001s
sys     0m3.537s

umount /mnt

Das sind 271 MB/s - also genauso schnell wie NFS.

 

[sch4kal]

Deshalb gibt es Loop Detection Protokolle wie STP oder auch RLDP. Sie versuchen, solche Loops zu entdecken. Wenn sie eine Loop feststellen, werden die entsprechenden Ports gesperrt.

Vorsicht, Loop Detection hat in diesem Fall nichts mit Spanningtree zu tun. Das ist eine proprietäre Implementierung des Herstellers und rein lokal auf den Switch begrenzt.

 

[Datanette]

@74181
Bitte nicht böse sein, aber ich habe den von dir vorgeschlagenen Speedtest noch nicht so absolviert, aber trotzdem eine Testdatei erstellt und mit diversen Programmen rumkopiert. Deinen Vorschlag bekomme ich auf die schnelle nicht ganz so einfach hin, wie jemand der das öfters mal macht.

Trotzdem ist auffällig, dass unter Windows alles viel schneller verschoben wird und dies teilweise bis hin zur maximalen 2.5Gb/s Auslastung. Meine Shares sind allesamt Samba.

Unter Linux Mint läuft bis auf ganz seltene Ausnahmen mal max 160MB/s, ansonsten alles mit 70MB/s bis maximal um die 1Gb/s, mal etwas mehr mal weniger, egal mit welchem Programm ich Dateien verschiebe. Wenn ich direkt von Backup-Server1 auf Backup-Server2 kopiere, wirds komischerweise auch nicht schneller.
Nun hatte ich soeben noch einen Geistesblitz. Macht mir da vielleicht die Verschlüsselung einen Strich durch die Rechnung, trotz recht potenter Hardware?
PC und Server sind alle mit Luks verschlüsselt und Win mit Bitlocker.

edit:
Wäre es auch möglich, dass es einen Unterschied macht, dass ich die Shares mit Gigolo mounte?

edit2:
Desweiteren kann ich den Netzwerkadapter und dessen Treiber ausschliessen. Habe den mit zwei anderen verglichen, mit exakt gleichem Resultat.

Testdatei von PC auf NAS kopiert per Nemo -->120MB/s
......................NAS auf PC..............................-->160MB/s

 

[74181]

Wenn ich es richtig verstehe, geht es hier darum herauszufinden, ob es Netzprobleme gibt - und warum Du unter Linux einen geringeren Durchsatz misst.

Bei Geschwindigkeitstests ist es wichtig, alle Störfaktoren auszuschalten. Sonst misst man nicht das, was man messen will.

Deswegen empfehle ich Basis-Kopier-Befehle wie copy und cp, die einfach nur kopieren. Andere Programme machen möglicherweise viel mehr - sie komprimieren, cachen, verbrauchen CPU-Zeit für Animationen, telefonieren noch mal nach Hause, um herauszufinden, ob sie überhaupt kopieren dürfen, diskutieren mit dem Virenscanner...

Virenscanner können eine Rolle spielen. Vorher ausschalten.

Festplattenverschlüsselung kann eine Rolle spielen. Man kann es daran erkennen, dass die CPU Last recht hoch ist. Deshalb auf dem Start- und Zielrechner immer top oder den Systemmonitor mitlaufen lassen. Den Test zum Messen des Netzwerk-Durchsatzes sollte man, wenn der Durchsatz zu niedrig ist, mit unverschlüsselten Volumes wiederholen. Bei meinem obigen Test habe ich /tmp verwendet. /tmp ist eine Ramdisk. Es gibt keine Verschlüsselung und keine Disk I/O Latenzen, die stören könnten.

Wichtig ist, dass man für den Durchsatz-Test zunächst eine (!) sehr große (!) Datei wählt, deren Übertragung mindestens 20 Sekunden dauert. Das minimiert den Einfluss vieler Störungen. Iin meinem Test war das eine Datei mit 10GB.

 

[Datanette]

Klar, das macht Sinn. Nur bekomme ich das als Noob nicht so einfach hin.
Ich versuche gerade mal nach deiner Anleitung per cifs mount die Datei zu kopieren. Soweit funktioniert das, aber leider scheitere ich beim Kopiervorgang mit "keine Berechtigung".
Lesen geht, aber nicht schreiben, obwohl dieser user mit welchem ich den mount verifiziere rw Rechte auf dem NAS hat.

 

[74181]

Na, dann probier doch erst einmal zu lesen. Packe eine sehr große Datei 'testdatei' auf Dein NAS. Und dann:

sync; time ( cp /mnt/testdatei /dev/null; sync )

Durch Angabe von /dev/null kopierst Du direkt in den Mülleimer. Damit vermeidest Du Verzögerungen durch Festplatten-Verschlüsselung auf dem Arbeitsrechner.

 

[Datanette]

Alles klar, danke. das bekam ich auch hin:

user@user:/tmp$ sync; time ( cp /mnt/datashare/testdatei /dev/null; sync )

real    0m41,333s
user    0m0,005s
sys    0m0,793s

...kopieren der generierten 10GB Testdatei...

 

[74181]

10 GB in 41 Sekunden... Das sind 10.000 MB / 41 Sekunden = 243 MB/s. Das ist doch ein ordentlicher Wert für ein 2.5 GBit/s Netzwerk! Viel mehr, als was Du oben geschrieben hast!

Man kann das vielleicht noch weiter optimieren... Aber bitte miss erst einmal, welche Datenrate Du mit dem cp-Befehl beim Schreiben vom Arbeitsrechner auf Dein NAS erhältst.

 

[Datanette]

Danke für deine Geduld und den guten Willen.

endlich:

sync; time ( sudo cp testdatei /mnt/datashare; sync )

real    1m6,435s
user    0m0,002s
sys    0m0,004s

Einiges langsamer als der Download, aber das dürfte an der Verschlüsselung liegen. Habe auch im Hinterkopf, dass dies in der Vergangenheit +/- das Maximum war. Da läuft doch noch einiges neben her auf dem NAS und die Verschlüsselung ist schon merkbar.
Wenn ich dies nun richtig interpretiere, gibts prinzipiell keine Probleme mit dem Netzwerk. Fragt sich was denn die Kopiervorgänge so langsam macht mit FreeFileSync unter Linux und auch das Kopieren in Nemo einiges langsamer ist als das Kopieren per Win-Dateiexplorer.

Als Vergleich sollte ich wohl nochmals den Kopiervorgang von PC auf die Backup-Server messen, welche potenter sind.
(Ich weiß, das ist so noch nicht ganz richtig, weil nicht im tmp Verzeichnis, habe mein Problem mit den Rechten auf die schnelle nicht anders lösen können.)

copy PC zu Backup-Server1 nur über den 1. Switch:

sync; time ( cp /mnt/datashare/testdatei /home/user/downloads; sync )

real    0m36,783s
user    0m0,004s
sys    0m3,616s

sync; time ( sudo cp testdatei /mnt/datashare; sync )

real    0m46,645s
user    0m0,002s
sys    0m0,042s

copy PC zu Backup-Server2 über die 2 Switches:

sync; time ( cp /mnt/datashare/testdatei /home/user/downloads; sync )

real    0m36,495s
user    0m0,003s
sys    0m3,680s

sync; time ( sudo cp testdatei /mnt/datashare; sync )

real    0m47,638s
user    0m0,001s
sys    0m0,004s

Nun weiß ich doch schon einiges mehr.

 

[74181]

Vielleicht kannst Du auf Deinem NAS ein Share erstellen und freigeben, das nicht verschlüsselt ist? Damit solltest Du die volle Geschwindigkeit hinbekommen. Im Vergleich zwischen unverschlüsseltem und verschlüsseltem Share kannst Du messen, wie viel Performance die Verschlüsselung kostet.

Auf meinem Fileserver gibt es ein paar verschlüsselte Volumes für meine Daten. Es gibt aber auch das Scratch-Volume, das nicht verschlüsselt ist. Ich verwende es für Datenaustausch - oder um mal schnell einen Film oder ein großes VM Image dorthin kopieren zu können. Dafür brauche ich keine Verschlüsselung. Ich will maximale Geschwindigkeit. Ich kann das Scratch-Volume natürlich auch gut für Durchsatz-Tests nehmen, wie in den Beispielen oben.

Wenn ich dies nun richtig interpretiere, gibts prinzipiell keine Probleme mit dem Netzwerk.

Das würde ich auch so interpretieren.

Fragt sich was denn die Kopiervorgänge so langsam macht mit FreeFileSync unter Linux und auch das Kopieren in Nemo einiges langsamer ist als das Kopieren per Win-Dateiexplorer.

Es gibt zwei unterschiedliche Arten von Kommunikation über das Netz.

1. Bei der ersten sendet die eine Seite Daten mit voller Geschwinfdigkeit an die andere Seite. Damit erreicht man relativ einfach den vollen Durchsatz.
   
   
2. Bei der zweiten unterhalten sich die beiden Rechner. Der erste Rechner sendet eine Anfrage an den anderen - und wartet auf die Antwort. Danach sendet er wieder eine Anfrage und wartet wieder auf die Antwort. Usw. Bei dieser Art der Kommunikation ist die Bandbreite nicht so wichtig. Es kommt auf die Reaktionsgeschwindigkeit des Kommunikationspartners an.

Wenn man mit "cp" eine große Datei überträgt, wird hauptsächlich die erste Variante verwendet. Wenn man mit einem Tool (FreeFileSync, Nemo) viele kleine Dateien zusammensuchen lässt und diese überträgt, wird hauptsächlich die zweite Variante verwendet. Dann braucht man sich nicht zu wundern, wenn der Datendurchsatz viel geringer ist als die Bandbreite. Weil das Tool einen großen Teil der Zeit keine Daten überträgt, sondern auf Antworten der anderen Seite wartet.

 

[Datanette]

Danke für die hilfreichen Infos.
Naja, das was mich eigentlich wundert ist, dass Win das etwas anders zu machen scheint und für den selben Kopiervorgang einiges schneller ist, egal ob viele kleine Dateien oder große komprimierte iso's, Container oder Archive.
Denkst du, macht es zusätzlich einen Unterschied wie die Shares gemounted werden, ob per cifs oder mittels gigolo? Leider weiß ich nicht, ob das zwei verschiedene Schuhe sind, oder gicolo nur ein GUI-Tool ist, welches cifs verwendet.

 

[74181]

Meiner Erfahrung nach ist Linux eher etwas schneller als Windows. Wenn Deine Tests unter Linux langsamer sind, ist entweder etwas noch nicht richtig konfiguriert bei Dir - oder die Tools, die Du verwendest, arbeiten für Deinen Testcase suboptimial. Ich persönlich würde weiter testen, bis ich herausgefunden hätte, was es ist.

Wie die Volumes gemountet sind, kannst Durch Eingabe des Befehl "mount" sehen. Schau, wie die Ausgabe ist, wenn Du von Hand mountest und wenn Du mit gigolo mountest.

Was passiert, wenn Du mit gigolo mountest und die 10GB Datei von Hand mit den obigen Befehlen überträgst? Ist es langsamer? Oder gleich schnell?

 

[Datanette]

Dann ist vielleicht etwas nicht richtig eingestellt, wobei ich diesbezüglich nichts verändert habe. Es ist alles seit anfang so und auf Standard-Einstellungen.
Es könnte natürlich an dem mount-verfahren liegen.

Mit "mount" sehe ich keine der Shares welche per gigolo gemountet wurden. Gigolo mountet per "gvfs", schein etwas anders zu funktionieren.
Das stellt mein nächstes Problem dar. Ich weiss nicht wie ich per "cp" auf "/run/user/1000/gvfs/smb-share:server=192.168.1.22,share=test" kopieren kann.

Das geht nicht wie gewünscht:

user@user:~/Downloads$ sync; time ( sudo cp testdatei /smb-share:server=192.168.1.22,share=test; sync )

real    0m5,793s
user    0m0,002s
sys    0m0,011s

 

[74181]

Bitte poste die Ausgabe vom

mount | grep "192.168.1.22"

Der richtige copy-Befehl ist vermutlich:

sync; time ( sudo cp testdatei /run/user/1000/gvfs/smb-share; sync )

oder vielleicht auch:

sync; time ( sudo cp testdatei /run/user/1000/gvfs/smb-share/datashare; sync )

Gehe mit Deinem Filemanager (oder auf der Shell) nach "/run/user/1000/gvfs/smb-share/" und hangle Dich von dort weiter, bis du das Verzeichnis auf dem NFS-Share siehst, in das Du kopieren willst. Welches Verzeichnis ist das? Dann gehst Du auf der Shell wieder in das /tmp-Verzeichnis und führst den cp-Befehl aus - mit dem Verzeichenis als Zielverzeichnis, das du herausgefunden hast.

Anmerkung: unter Windows werden Netzwerklaufwerke häufig mit eigenem Laufwerks-Buchstaben eingehängt. Unter Linux werden sie an einen beliebigen Otr im bestehenden Verzeichnisbaum eingehängt. Also z.B. nach /mnt oder auch nach /run/user/1000/gvfs/smb-share. Wenn man auf das Netzwerklaufwerk kopieren will, kopiert man einfach an die entsprechende Stelle im Verzeichnisbaum. Es gibt keine Laufwerksbuchstaben.

 

[Datanette]

Egal, habe nun einfach das Share per cifs gemountet und per Nemo kopiert. Das Ergebnis --> voller speed!

Beitrag automatisch zusammengeführt: 14.02.2026

mount | grep "192.168.1.22" gibt mit gigolo keine Ausgabe.

Beitrag automatisch zusammengeführt: 14.02.2026

cp Befehle funktionieren leider nicht mit den Pfaden.

Beitrag automatisch zusammengeführt: 14.02.2026

FreeFileSync benutzt folgenden Pfad, welcher mit cp aber nicht funktioniert.
/run/user/1000/gvfs/smb-share:server=192.168.1.21,share=test

meisten Abbruch mit "keine Berechtigung"

Beitrag automatisch zusammengeführt: 14.02.2026

Egal, das ist es wirklich. 280MB/s beim Kopieren unter Nemo. Das habe ich vorher noch nie gesehen.

Muss ich für cifs mounts alles händisch konfigurieren und scrips anlegen? Habe so einige shares und deswegen hatte ich auch gesucht und das gigolo-gui gefunden,