NFS-Durchsatz: Lesen vs. Schreiben

Hallo,

ich habe heute mal eine veraenderte Version des NFS-Scripts von essu ins Forum gestellt.

Natuerlich habe ich das Script selber bis zum Abwinken genutzt - zuletzt mit Dateigroessen von 128 MByte.

Dabei kam folgendes raus:

Code: Alles auswählen

Results for writing throughput:
8.659 Mbit/s with udp, async, 32768
8.323 Mbit/s with udp, async, 16384
7.561 Mbit/s with udp, async, 8192
6.170 Mbit/s with udp, sync, 16384
6.135 Mbit/s with udp, sync, 8192
6.100 Mbit/s with tcp, async, 32768
5.932 Mbit/s with udp, sync, 32768
5.932 Mbit/s with tcp, async, 16384
5.899 Mbit/s with tcp, sync, 8192
5.867 Mbit/s with tcp, sync, 16384
5.804 Mbit/s with tcp, async, 8192
5.651 Mbit/s with tcp, sync, 32768

Results for reading throughput:
8.196 Mbit/s with tcp, sync, 32768
8.134 Mbit/s with tcp, async, 32768
8.012 Mbit/s with tcp, sync, 16384
7.837 Mbit/s with tcp, sync, 8192
7.837 Mbit/s with tcp, async, 8192
7.837 Mbit/s with tcp, async, 16384
.950 Mbit/s with udp, sync, 8192
.940 Mbit/s with udp, async, 8192
Failure with udp, sync, 32768
Failure with udp, sync, 16384
Failure with udp, async, 32768
Failure with udp, async, 16384

Nun moechte man meinen, dass der Lesedurchsatz mit tcp, sync, 32768 am schnellsten ist. Aber irgendwas scheint anders zu sein, wenn die dbox ts-Streams vom NFS-Server liest. Die Ergebnisse aus dem Script sind also nicht ueberzubewerten. Tatsaechlich funktioniert das Lesen mit dem zweiten Wert am besten. Seit einer Stunde habe ich einen Actionfilm mit hoher Datenrate in zwei Sprachen + Dolby Digital ohne Unterbrechungen oder Störungen laufen.

Da die Einstellungen für Schreiben und Lesen total unterschiedlich sind, habe ich nun zwei Mountpoints auf der dbox eingerichtet: /mnt/read mit den Einstellungen zum Lesen und /mnt/write mit den Einstellungen zum Schreiben. Natuerlich greifen beide Mountpoints auf das gleiche Verzeichnis auf dem NFS-Server zu.

Nun kann ich endlich auch die Filme sehen, die ich irgendwann mal aufgenommen habe. Und das, ohne mir eine DVD brennen zu muessen

chicken

Beitrag von **chicken** » Samstag 31. Dezember 2005, 03:03

Die Testergebnisse waren uebrigens mit einem Switch gemacht. Leider haben sich bei der Wiedergabe dann doch noch wieder einige Stoerungen gezeigt.

Nun habe ich mir doch mal ein Crossover-Kabel besorgt. Das Ergebnis ist sehr interessant. Folgende Werte habe ich fuer einen Transfer mit 128 MByte bekommen:

Code: Alles auswählen

Results for write throughput:
7.669 Mbit/s with tcp,async,wsize=32768
7.405 Mbit/s with tcp,async,wsize=16384
7.110 Mbit/s with udp,async,wsize=8192
7.110 Mbit/s with tcp,async,wsize=8192
6.839 Mbit/s with udp,async,wsize=16384
6.628 Mbit/s with udp,async,wsize=32768
6.587 Mbit/s with tcp,async,wsize=4096
6.507 Mbit/s with udp,async,wsize=4096

Results for read throughput:
9.418 Mbit/s with udp,async,rsize=4096
9.336 Mbit/s with udp,async,rsize=16384
9.256 Mbit/s with udp,async,rsize=8192
8.947 Mbit/s with udp,async,rsize=32768
8.388 Mbit/s with tcp,async,rsize=32768
8.323 Mbit/s with tcp,async,rsize=4096
8.259 Mbit/s with tcp,async,rsize=8192
8.134 Mbit/s with tcp,async,rsize=16384

Dabei fallen fuenf Dinge auf:

Die Schreibgeschwindigkeit jetzt mit TCP hoeher als mit UDP
Die Schreibgeschwindigkeit ist um fast 1 Mbit/sec gesunken
Die Lesegeschwindigkeit ist jetzt mit UDP hoeher als mit TCP
Die Lesegeschwindigkeit ist um etwa 1 Mbit/sec gestiegen
Kleinere Pakete erhoehen die Lesegeschwindigkeit

Man muss sich wohl entscheiden, ob man aufnehmen oder abspielen will, und daraufhin entweder mit Crossover oder mit einem Switch verbinden

Einen Test mit "sync" habe ich nicht mehr gemacht. Es liegt schiesslich in der Natur der Sache, dass das langsamer sein muss.

Die Box ist uebrigens ueber ein 5m langes Kabel mit dem Server (Gentoo-Linux) verbunden. Der Switch ist ein einfaches Teil von D-Link (DES-1005D).

Vielleicht sind diese Ergebnisse ja fuer den einen oder anderen hilfreich.

Als naechstes werde ich mal mit einer dieser verrufenen RealTek-Karten testen. Momentan laeuft das alles ueber eine D-Link-Karte.

chicken

Hi,

ich habe Dein Skript mal an meinem "Produktivsystem" durchlaufen lassen.

Sagem 2xi Sat --> 30 m Cat 5 --> ATI 10 mbit Hub --> 3com 3c905 tx@Epia-CL 6000E@Eisfair

Ich habe seit vielen Monaten keinen Abbruch/Ruckler beim Streamen oder Abspielen gehabt.
Bei uns werden täglich im Durchschnitt 3 Sendungen aufgenommen.

Einstellungen dabei sind UDP, 8192 und async

Da ich das Yadi-Release 2.1 vom 16.03.05 einsetze, steht mir leider kein sed bzw. sort zur Verfügung.

Speziell bei den Einzelwerten udp, async bei den jeweiligen Paketgrössen sieht man schon recht hohe Werte

Das Testergebnis:

Measuring NFS throughput...
Mount options: udp, sync, 4096
umount: /mnt: Invalid argument
writing 64 MBytes...
Success after 87 seconds
reading 64 MBytes...
Success after 77 seconds

Mount options: udp, async, 4096
writing 64 MBytes...
Success after 86 seconds
reading 64 MBytes...
Success after 78 seconds

Mount options: tcp, sync, 4096
writing 64 MBytes...
Success after 91 seconds
reading 64 MBytes...
Success after 84 seconds

Mount options: tcp, async, 4096
writing 64 MBytes...
Success after 99 seconds
reading 64 MBytes...
Success after 84 seconds

Mount options: udp, sync, 8192
writing 64 MBytes...
Success after 86 seconds
reading 64 MBytes...
Success after 70 seconds

Mount options: udp, async, 8192
writing 64 MBytes...
Success after 69 seconds --> 0,928 mb/s
reading 64 MBytes...
Success after 71 seconds --> 0,901 mb/s

Mount options: tcp, sync, 8192
writing 64 MBytes...
Success after 99 seconds
reading 64 MBytes...
Success after 81 seconds

Mount options: tcp, async, 8192
writing 64 MBytes...
Success after 93 seconds
reading 64 MBytes...
Success after 82 seconds

Mount options: udp, sync, 16384
writing 64 MBytes...
Success after 86 seconds
reading 64 MBytes...
Success after 70 seconds

Mount options: udp, async, 16384
writing 64 MBytes...
Success after 70 seconds --> 0,914 mb/s
reading 64 MBytes...
Success after 70 seconds --> 0,914 mb/s

Mount options: tcp, sync, 16384
writing 64 MBytes...
Success after 91 seconds
reading 64 MBytes...
Success after 82 seconds

Mount options: tcp, async, 16384
writing 64 MBytes...
Success after 94 seconds
reading 64 MBytes...
Success after 82 seconds

Mount options: udp, sync, 32768
writing 64 MBytes...
Success after 86 seconds
reading 64 MBytes...
Success after 69 seconds

Mount options: udp, async, 32768
writing 64 MBytes...
Success after 70 seconds --> 0,914 mb/s
reading 64 MBytes...
Success after 69 seconds --> 0,928 mb/s

Mount options: tcp, sync, 32768
writing 64 MBytes...
Success after 92 seconds
reading 64 MBytes...
Success after 81 seconds

Mount options: tcp, async, 32768
writing 64 MBytes...
Success after 94 seconds
reading 64 MBytes...
Success after 81 seconds

Gruß
Frockert

Beitrag von **chicken** » Samstag 31. Dezember 2005, 11:51

Hallo!

Frockert hat geschrieben:Da ich das Yadi-Release 2.1 vom 16.03.05 einsetze, steht mir leider kein sed bzw. sort zur Verfügung.

Mist, daran habe ich garnicht gedacht

Ohne die sortierten Ausgaben am Ende bietet das Script natuerlich nicht mehr allzuviele Vorteile.

Ich selber habe fast immer 'ne YADD laufen, die ich regelmaessig aus dem CVS aktualisiere. sed und sort sind Bestandteile von busybox und sollten eigentlich nur wenig Speicher benoetigen.

chicken

Beitrag von **mogway** » Samstag 31. Dezember 2005, 13:52

Ab Yadi Snapshot 2.1.0.6 - Tuxbox CVS Stand vom 08.09.2005 ist sed im yadi enthalten.

Gruß
mogway

Hallo zusammen,

ich bin noch ein ziemlicher Linux-Newbie, konnte aber auf meiner Box bisher alles so zum Laufen kriegen, wie ich's haben wollte. Allerdings bekomme ich leider die sortierte Ausgabe am Ende von chickens Speed Test nicht hin -- auf meiner Box (Yadi 2.1.0.8) ist kein sort drauf.

Kann ich das mit meinen "Bordmitteln" draufkriegen, oder ist das ein größerer Act (kompilieren und so kann ich net â€¦)?

Vielen lieben Dank für Eure Hilfe ...
Benjamin.

FaselMan · Beitrag von **FaselMan** » Samstag 21. Januar 2006, 07:41

Beitrag von **ziggy** » Mittwoch 25. Januar 2006, 09:31

Hallo chicken,

kannst Du bitte noch posten, welchen NFS-Server Du verwendest? Der ist sicher auch performancerelevant. Habe selbst mit SFU nie was ruckelfrei hinbekommen, würde es aber mit Deinen Einstellungen ggf. nochmal versuchen...

Gruß
Z

Beitrag von **2faraway** » Mittwoch 25. Januar 2006, 14:01

Na wenn ich das richtig verstanden habe, den NFS-Server des Gentoo-Linux ..

Beitrag von **2faraway** » Mittwoch 25. Januar 2006, 14:06

Chickens Meßergebnisse kann ich übrigens bestätigen,
sowohl die Erkenntnisse über den Switch (DLink 1008) als auch die über eine Crossoververbindung ...

Gemessen mit SFU unter W2K und WXP (nat. keine 32K-Mount möglich) und 3Com-100MBit-PCI-Karte.
Die Realteks waren bei meinen Tests 200 - 300 Kbits langsamer.

@ziggy:
mit welchem NFS Server hast Du denn die besten Erfahrungen gemacht? Da ich auch bisher nur SFU genutzt habe würde ich durchaus mal was anderes testen. Der suckt bei mir nämlich auch manchmal.

Thx
Torsten

Hi,
Ich habe mal vor Spass eine zusätzliche 3Com 3C905 auf meinem MSI RS480 eingesetzt. MMit den gleichen Mounts, ging es leider nicht besser, soll heißen, dass meine Testaufnahmen mit Bitraten von max. 8000kBit stärker ruckeln als bei der Onboardkarte.
Das habe ich nicht erwaretet.

Dann wolte ich mit dem Script von Chicken hier das mal genauer testen, habe es nur irgendwie nicht zum Laufen bekommen.

1. Das Script angepasst
2. nach Tmp kopiert und ausführbar gemacht
3. Im telnet ./speedtest.sh eingegeben und bekommen nur Fehler nicht gefunden, selbst wenn ich im selben Verzeichniss bin.

Wenn ich nach Tuxbox/Config kopiere und die cfg dazu erstelle sehe ich zwar das script in Neutrino, beim auswählen passiert aber auch nix.

Was mache ich falsch? Zugegebenermaßen kenne ich wenig von Scripten...

Danke

Beitrag von **petgun** » Donnerstag 26. Januar 2006, 14:15

Torsten73 hat geschrieben:1. Das Script angepasst

..und auch im Unix-Format (LF only) abgespeichert?

Habs mit Ultraedit32 bearbeitet und nicht ins Dos konvertiert. Das sollte doch ok sein, oder ? Arbeite z.Zt zum Testen mit Ultraedit32. D.h. ich habe vorher nur mit Notepad gearbeitet, was nicht komfortabel war, aber auch funktionierte. In Ultraedit werden allerdings keine CR es angezeigt.

Oder war es falsch per copy&paste das Script von hier zu kopieren? Vielleicht ist die Vorlage ja schon nicht Unix konform?

Beitrag von **petgun** » Donnerstag 26. Januar 2006, 14:31

..ultraedit kenne ich nicht. Nimm einfach crimson...sehr komfortabel und kostenlos...Du musst aber auch da das 'Fileformat' einstellen. Ich wette dass nach copy&paste von einer Webseite bei ultraedit DOS-Format (default) eingestellt ist...CR sieht man normalerweise nicht bei einem _Editor_.

FaselMan

Beitrag von **Torsten73** » Freitag 27. Januar 2006, 22:33

Hi,
Danke Petgun, des verflixte Unix wars. Habe den Ultraedit runtergeschmissen und den Crimson genommen und im Unix gespeichert und des wars.

Mal sehen was die Messungen ergeben, den leider hält die 3Com in den bisherigen Einstellungen nicht dem Vergleich der Onboard RS480 stand.

Bis nachher...

Beitrag von **Torsten73** » Freitag 27. Januar 2006, 22:57

Ohh,
im JTG ist ebenfalls kein SED & SORT enthalten ...

Beitrag von **jmittelst** » Freitag 27. Januar 2006, 23:03

Sed ist drin, nur Sort fehlt.

cu
Jens

Beitrag von **Torsten73** » Freitag 27. Januar 2006, 23:16

Vielleicht baut es Ryker ja mal mit ein?
Dann muß halt der Taschenrechner herhalten.

Beitrag von **Torsten73** » Samstag 28. Januar 2006, 00:01

Hi,
wie kann ich eigentlich die Ausgabe in der Konsole sehen? Von der Konsole aus bekomme ich das Script auch nicht gestartet, nur übers Script Menü. Allerdings kann ich mit der Anzeige der Ergebnisse am TV nur bedingt was anfangen, in der Konsole wäre mir das schon lieber.

Cu
Torsten

Tuxbox-Board

NFS-Durchsatz: Lesen vs. Schreiben

NFS-Durchsatz: Lesen vs. Schreiben

Crossover vs. Switch

sort