Frage zu routerinterner Geschwindigkeit

cabriofahrer

Well-Known Member
Habe einen CBN-Router und an diesem meinen Haupt-PC und ein Notebook jeweils mit Kabel angeschlossen. Ich kann dann z.B. das Notebook als NFS-Server und den Hauptrechner als NFS-Client benutzen, um Daten zu transferieren. Dabei zeigt gkrellm auf dem PC Werte zwischen ca. 5.5 und 7.1 M an. Ich nehme an, das ist das Maximale, was der Router an interner Geschwindigkeit hergibt. Ist das ein guter, bzw. normaler Wert? Ist da vielleicht noch mehr zu erreichen?
 
Das scheint mir nicht FreeBSD-spezifisch zu sein. Ich hab es mal ins allgemein Netzwerk-Forum verschoben.
 
Hi,

der Router sollte ja reintheoretisch garnicht zwischen den Geräten Routen, da sich ja beide im Heimnetz befinden. Somit fungiert das Gerät eher als "Switch" - 5,5 bis 7,1 kommen mir aber selbst wenns nur ein Fast-Ethernet Gerät ist (100 Mbit Maximal / Port) sehr wenig vor.

Es gibt natürlich viele Möglichkeiten an denen es scheitert, dabei muss der Rouuter nicht die einzige sein. Du könntest zum Test beide Geräte direkt miteinander verbinden, ohne den Router dazwischen, oder aber zwischen die beiden Geräte einen (Gigabit) Switch stekcken der ein 3. Beinchen am Router denn hat.
 
Da kann vermutlich niemand wirklich antworten. Die Bremse stellt oft eine langsame Platte und seltener das Netz.
Die Anzeigen, egal welche auch immer, können mitunter nicht so wirklich ernst genommen werden. Besser ist es, große Dateien zu verschicken und die Zeit zu stoppen, um einen Wert für die Geschwindigkeit zu erhalten.
net-mgmt/iftop hat eine ziemlich gute Anzeige, man sollte aber zuvor die man-page lesen, um sie richtig zu deuten und die Optionen passend zu wählen.

NFS bietet selbst einige Möglichkeiten der Optimierung. das alles hier in Kürze wiedergeben, kann ich gar nicht. Allermeist werden auch automatisch gute Werte gefunden, das Optimieren ist ein Probierspiel und es gibt selten Werte, die magisch direkt etwas verbessern.
Meine "best-practice" mount-optionen von einem schwachen busybox/Linux-Rechner sind etwa: rw,v3,rsize=16384,wsize=16384,hard,udp,lock,
 
Ansonsten mal mittels iperf den LAN Durchsatz durchmessen. Der sollte, wenn keine Probleme vorliegen, sehr nah an dem sein was der Router kann. Vermutlich bei dir 100MBit/s.
 
Die Bremse stellt oft eine langsame Platte und seltener das Netz.

Damit hast Du echt was gesagt, vielleicht ist das ja das Problem, zumal es sich beim Notebook um ein älteres Modell handelt. Dann würde ich gerne erst mal Lese- und Schreibgeschwindigkeit der betroffenen Festplatten testen. Wie kann ich das machen?

Du könntest zum Test beide Geräte direkt miteinander verbinden, ohne den Router dazwischen,

Geht das überhaupt mit einem normalen Netzwerkkabel, oder braucht man da nicht ein spezielles? Und wie funktioniert das dann überhaupt, da schließlich der Router den beiden PC's jeweils eine IP zuteilt (im vorliegenden Fall 192.168.1.64 und 192.168.1.202) von denen dann die eine im Client-Rechner im Befehl

# mount server:/home /mnt

verwendet wird?
 
Geht das überhaupt mit einem normalen Netzwerkkabel, oder braucht man da nicht ein spezielles? Und wie funktioniert das dann überhaupt, da schließlich der Router den beiden PC's jeweils eine IP zuteilt (im vorliegenden Fall 192.168.1.64 und 192.168.1.202) von denen dann die eine im Client-Rechner im Befehl

# mount server:/home /mnt

verwendet wird?

Eigentlich sollten alle "modernen" Netzwerkkarten insbesondere wenn die auch GigaBit können kein "Spezielles" Kabel benötigen, es sollte nur mindestens den Cat 5e Standard unterstützen. Die Handeln die Kabelbelegung dann selbst aus. https://de.wikipedia.org/wiki/Medium_Dependent_Interface#Auto_MDI-X

Die IP-Addressen müsstest du von Hand "fest" vergeben für die dauer des Testes. Du könntest Problemlos die 192.168.1.64 und 192.168.1.202 dafür verwenden. (Während des Testes funktioniert natürlich das Internet dann nicht)
 
gerne erst mal Lese- und Schreibgeschwindigkeit der betroffenen Festplatten testen
benchmarks/bonnie
ist ein solches Tool, das Festplattengeschwindigkeiten testen kann. Es ist weithin anerkannt, man sollte auchhier die Dokumentation lesen und nicht einfach nur loslegen. Es gibt durchaus die Möglichkeit, falsche Daten zu erhalten, wenn man einiges nicht bedenkt (etwa die Dateigröße im Verhältnis zum Speicher).
Das oben erwähnte iperf kann so etwas auch und außerdem die Netzwerkgeschwindigkeit testen, hat aber für mich den Nachteil, dass es einen Server-Client Betrieb will und damit für die meisten Aufgabenstellungen für mich zu kompliziert zu sein scheint.
Gute Ergebnisse für die Geschwindigkeiten von Platten erhält man auch bei Tests mit großen Dateien. bonnie macht im Grunde nichts anderes. Solche großen Dateien kann man auf der Festplatte von einem Ort zum anderen kopieren und dann die Zeit messen und vergleichen. Einfacher ist das mit Tools, die bereits selbst die Zeit messen und Datenraten anzeigen. Da benutze ich sehr gerne rsync.
Bei diesen Tests wird von Festplatte gelesen, im Speicher gepuffert und wieder auf die Festplatte geschrieben. Wenn Quelle und Ziel auf unterschiedlichen Rechnern im Netzwerk liegen, hat man gleichzeitig auch das Netz mit-getestet.
Nimmt man nun Werte "aus dem Speicher" und beschreibt damit eine große Datei, so wird nicht zuerst von der Festplatte gelesen. So etwas bekommt man zum Beispiel hin, wenn man mit dd eine Anzahl von Nullen oder Zufallszahlen schreibt. Mal ein kleines Beispiel:
Code:
pit@senyo ~:- > dd if=/dev/zero of=zero.test bs=1k count=1000
1000+0 records in
1000+0 records out
1024000 bytes transferred in 0.031963 secs (32037440 bytes/sec)
pit@senyo ~:- > dd if=/dev/random of=zero.test bs=1k count=1000
1000+0 records in
1000+0 records out
1024000 bytes transferred in 0.049223 secs (20803182 bytes/sec)
pit@senyo ~:- > dd if=/dev/zero of=zero.test bs=1k count=1000
1000+0 records in
1000+0 records out
1024000 bytes transferred in 0.030530 secs (33540833 bytes/sec)
pit@senyo ~:- > rm zero.test
In diesem Test ist die Größe für die Datei viel zu klein gewählt, er zeigt aber, dass dd ebenfalls Werte für Zeit und Übertragungsrate liefert und dass die Ergebnisse zwischen zero und random durchaus unterschiedlich liegen, was die Wichtigkeit der Qualität einer Quelle unterstreicht.

mount server:/home /mnt
CommanderZed hat zu dem Prozedere schon was gesagt. Ich finde es vielleicht etwas verständlicher, wenn man von dem Gerät "router" nicht als Genzes spricht, sondern die darin eingebauten Teile auch nach ihrer Funktion benennt. Die IP-Adressen bekommst du vom dort realisierten DHCP-Server, wenn deine PCs so eingestellt sind, dass sie diesen Dienst nutzen. Die Verbindung der beiden Rechner untereinander übernimmt der eingebaute SWITCH und dir Verbindung zu einem anderen Netz (dem Internet zB), die erledigt der ROUTER. Zwar wissen wir alle, dass diese Komponenten in dem einen Gerät zusammengefasst sind und ich will hier keinen auf Oberlehrer machen, aber es dient dem Verständnis in den Funktionsgruppen zu denken, denn du kannst schließlich jede dieser Gruppen auch mit anderen Geräten oder SW ersetzen. Doch darauf will ich hier nur soweit eingehen, dass gelegentlich schon mal ein SWITCH oder auch nur ein einziger Port eines solchen kaputt geht und manchmal äußert sich das in schlechten, sprich langsamen Verbindungen.
Der mount-Befehl für NFS-Freigaben kennt auch Optionen und davon habe ich oben mal eine Auswahl vorgestellt. Diese Optionen können durchaus auch Geschwindigkeit bedeuten, manchmal auch darüber, dass sie zuverlässiger verbinden. Das ist ein weitläufiges Thema und ich habe damit schon einige Stunden verbracht, Grundlagen zu lesen und dann zu testen. Bei einigermaßen aktueller HW wird zwar oft und ganz besonders bei nur zwei beteiligten Rechnern (einem Client) eine gute Einstellung automatisch gefunden, doch wenn du schon sagst, dass einer der PCs betagt ist, dann könnte durchaus eine manuelle Korrektur was bringen. Die oben vorgestellten Einstellungen auf einem digitalen Sat.-Empfänger mit busybox/Linux machen diesen erst zu einem zuverlässigen Clienten auf meinem NFS-Server. Andere Einstellungen versagten zum Teil verheerend. Schlimm ist, dass man das mitunter erst nach Tagen im festen Betrieb bemerkte und auf Anhieb auch mit weniger brauchbaren Einstellungen alles wunderbar ausgesehen hat. Die Optimierungsarbeit kann hier also durchaus schon mal eine Zeit lang dauern.
 
Zurück
Oben