WL-HDD Alternative

[marobo]

Durch einen Hinweis im Tuxbox-Forum konnte ich verifizieren, dass der von mir auf dem MGB100 installierte nfs-kernel-server offenbar nur 8k-Blöcke unterstützt. Darauf hatte ich bisher noch gar nicht geachtet. Trotz anderslautender Konfiguration (rsize=32768,wsize=32768) wird das Verzeichnis bei mir nur mit rsize=8192,wsize=8192 gemountet, wie der mount-Befehl auf der dBox 2 offenbart.

Dadurch erklären sich zum größten Teil wohl die schlechteren Werte gegenüber einem Notebook mit installiertem NFS-Server, der 32k-Blöcke unterstützt. Wenn ich für den Mount auf das Notebook die Blockgröße von 32k auf 8k ändere, dauert der Schreib-Geschwindigkeitstest etwa 72 Sekunden statt 62 Sekunden. Das MGB100 benötigt ebenfalls 72 Sekunden. Beim Lesen ändert sich der Wert fürs Notebook von 58 Sekunden auf 64-65 Sekunden. Hier ist das MGB100 zwar noch etwas langsamer, aber nicht mehr viel: 68 Sekunden.

Umgekehrt würde es MGB100 mit 32k Blöcken vermutlich in etwa die Geschwindigkeit des Notebooks erreichen und nicht 10 Sekunden langsamer als dieses sein. Aber: Gibt es denn eine Möglichkeit, die Übertragung mit 32k beim nfs-kernel-server zu aktivieren oder gibt es einen anderen NFS-V3-Server, den man auf dem MGB100 installieren könnte, der dieses Feature unterstützt?

[marobo]

Ich habe jetzt beim nochmaligen Lesen der letzten Seiten dieses Threads gesehen, dass Du etwas weiter oben schon geschrieben hattest:

also in der 2.4.35 unterstützt der nfs-kernel-server auch 32k Blöcke. In 2.4.28 war die Blockgröße auch für V3 auf 8k limitiert sofern nicht vom Ersteller gepatched (paganoV4???).

Also ist es wohl an der Zeit, sich endlich mal Deines Images anzunehmen

Die aktuellste Fassung ist wohl diese hier, oder? Das Image flashe ich ganz normal über die OpenWrt-Weboberfläche (System -> Upgrade)?

Kann ich ansonsten weiterhin mein bisheriges autobootfs verwenden? Es ist das "Openwrt Kamikaze x86 for WHD (OpenWrt filesystem image for V4 upgrade)" von der macsat-Seite, wo ich inzwischen natürlich meine individuellen Einstellungen und Anpassungen drin hab. Wenn ich es richtig verstanden habe, hast Du den 2.4.35er nfs-kernel-server in Dein Image integriert. Muss ich also erst den nfs-kernel-server und die nfs-kernel-server-utils (via ipkg) deinstallieren oder wie funktioniert es?

Du hattest geschrieben, dass man die /lib/modules/2.4.35 aus Deinem Image ins autobootfs übernehmen müsse, damit WLAN funktioniert. Das wäre für mich absolut essentiell, weil das MGB100 bei mir zukünftig primär als Accesspoint für mein WLAN dienen soll. Wo sind denn die Dateien zu finden, nachdem ich Dein Image geflasht habe und kann ich sie dann einfach nach /lib/modules/2.4.35 kopieren?

Was muss ich sonst noch beachten? Ich habe gerade (endlich) ein funktionierendes System auf der MGB100 und bin deswegen etwas zögerlich, wieder etwas Grundlegendes zu ändern Aber da ich mit dem Ist-Zustand letztlich nicht wirklich zufrieden bin, bleibt mir wohl nichts anderes übrig. Es wäre nett, wenn Du ein wenig weiterhelfen könntest.

[Tes]

Die aktuellste Fassung ist wohl diese hier, oder? Das Image flashe ich ganz normal über die OpenWrt-Weboberfläche (System -> Upgrade)?

Nein, das Upgrade musst du über den Code im Flash machen, also das autobootfs umbenennen und rebooten damit er das Linux im Flash bootet. Dann dort einloggen und das Firmware-Upgrade durchführen. Falls du dort den Default gelassen hast ist das Passwort 'admin' und die IP 192.168.123.254 (oder die, die ein DHCP-Server auf Anfrage vergeben hat).

Vergiss das Webinterface im autobootfs, wirklich sinnvoll ist es nicht. Schalte den Webserver ab, spart RAM. Er taugt leider nicht einmal als Ersatz fuer FTP da er, im Gegensatz zu Apache, keine Indexes on the fly erzeugen kann (nix mit Directory-Listings).

Kann ich ansonsten weiterhin mein bisheriges autobootfs verwenden?

Ja, mache ich hier auch nicht anders. Hin und wieder sollte ein Backup davon machen.

Wenn ich es richtig verstanden habe, hast Du den 2.4.35er nfs-kernel-server in Dein Image integriert. Muss ich also erst den nfs-kernel-server und die nfs-kernel-server-utils (via ipkg) deinstallieren oder wie funktioniert es?

Nein, es reicht wenn du einfach die Module nicht mehr laedst, da sie bereits im Kernel integriert sind (Also 'modprobe' oder 'insmod' im Startskript auskommentieren). Die Utilities brauchst du allerdings weiterhin.

Du hattest geschrieben, dass man die /lib/modules/2.4.35 aus Deinem Image ins autobootfs übernehmen müsse, damit WLAN funktioniert. Das wäre für mich absolut essentiell, weil das MGB100 bei mir zukünftig primär als Accesspoint für mein WLAN dienen soll. Wo sind denn die Dateien zu finden, nachdem ich Dein Image geflasht habe und kann ich sie dann einfach nach /lib/modules/2.4.35 kopieren?

Es gibt 2 Möglichkeiten. Du kannst 1) Einfach in /lib/modules einen Symlink mit dem Namen '2.4.35' nach '2.4.28' zeigen lassen (ln -s 2.4.28 2.4.35) oder 2) du kommentierst die Freigabe der RAM-Disk in /etc/init.d/rcS aus, rebootest, kopierst das Directory aus der RAM-Disk nach /lib/modules (mit 'cp -a'), dann gibst du die Freigabe der RAM-Disk wieder frei und rebootest nochmal. Letzteres habe ich gemacht.

Tes

[Tes]

Umgekehrt würde es MGB100 mit 32k Blöcken vermutlich in etwa die Geschwindigkeit des Notebooks erreichen und nicht 10 Sekunden langsamer als dieses sein. Aber: Gibt es denn eine Möglichkeit, die Übertragung mit 32k beim nfs-kernel-server zu aktivieren oder gibt es einen anderen NFS-V3-Server, den man auf dem MGB100 installieren könnte, der dieses Feature unterstützt?

Bei meinen Tests mit dem neuen Image lag der maximale Durchsatz bei 32K unter dem mit 8K und 16K erreichbaren. Mach dir also nicht allzugrosse Hoffnungen. Interessanterweise war der Durchsatz bei 8K und 16K identisch. Ja, laut 'mount' auf dem Client sind die Werte korrekt gesetzt worden.

BTW: Die dbox2 kann wirklich nur 10HDX? Es gibt durchaus NICs die auch bei 10MBit Vollduplex koennen was helfen wuerde. Die Frage ist wie das bei der dbox2 aussieht und wenn ja, wie man das aktiviert. Was für einen NIC hat die dbox2? (Eine URL mit einem hochauflösenden Bild der Platine würde reichen)

Tes

[schufti]

Hi!

Da ihr (marobo, Tes) die essentiellen Dinge ja inzwischen korrekt abgeklärt habt, bleibt mir nurmehr, alles zustimmend aus dem fernen Bukarest abzunicken. (nur mit den Modulen geht es einfacher, die habe ich mal irgenwo bei einem posting angehängt....)

Was die fullduplex Geschichte der dBox betrifft, so gab es da mal einen thread im tuxbox forum aber ich kann mich an kein befriedigendes Ende erinnern; einfach mal die boardsuche probieren.

schufti

edit:

also ich persönlich finde das Ergebnis (aus'm tuxbox forum) eigentlich ganz in Ordnung:

Results for write throughput:
8.947 Mbit/s with udp,async,wsize=8192
8.947 Mbit/s with udp,async,wsize=32768
8.659 Mbit/s with udp,async,wsize=16384

denn grundsätzlich ist ja beim Streamen nur die Schreibrate und die auch nur für manche ö/r relevant.

[Tes]

Hi!

also ich persönlich finde das Ergebnis (aus'm tuxbox forum) eigentlich ganz in Ordnung:

Results for write throughput:
8.947 Mbit/s with udp,async,wsize=8192
8.947 Mbit/s with udp,async,wsize=32768
8.659 Mbit/s with udp,async,wsize=16384

denn grundsätzlich ist ja beim Streamen nur die Schreibrate und die auch nur für manche ö/r relevant.

U.U. könnte man es mit TCP statt UDP probieren, vielleicht bringt das noch ein paar Prozente.

Tes

[marobo]

BTW: Die dbox2 kann wirklich nur 10HDX? Es gibt durchaus NICs die auch bei 10MBit Vollduplex koennen was helfen wuerde. Die Frage ist wie das bei der dbox2 aussieht und wenn ja, wie man das aktiviert. Was für einen NIC hat die dbox2? (Eine URL mit einem hochauflösenden Bild der Platine würde reichen)

Tes

Ich denke die dBox 2 kann wirklich nur Halfduplex. Ich habe hier mal den Schaltplan für die dBox 2 von Nokia gefunden, wie ich sie habe: klick.

[Tes]

Ich denke die dBox 2 kann wirklich nur Halfduplex. Ich habe hier mal den Schaltplan für die dBox 2 von Nokia gefunden, wie ich sie habe: klick.

Mal reinschauen... Anscheinend ist da was hackbar, aber der Aufwand ist ziemlich gross: http://tuxbox-forum.dreambox-fan.de/...ic.php?t=18485 Also wohl eher nicht, leider. Versuch mal beim mount explizit TCP anzugeben.

Tes

[marobo]

Da ihr (marobo, Tes) die essentiellen Dinge ja inzwischen korrekt abgeklärt habt, bleibt mir nurmehr, alles zustimmend aus dem fernen Bukarest abzunicken. (nur mit den Modulen geht es einfacher, die habe ich mal irgenwo bei einem posting angehängt....)

OK, ich werde mal danach schauen. Vielleicht komme ich nachher noch dazu, den Test mit Deinem Image zu wagen

also ich persönlich finde das Ergebnis (aus'm tuxbox forum) eigentlich ganz in Ordnung:

Results for write throughput:
8.947 Mbit/s with udp,async,wsize=8192
8.947 Mbit/s with udp,async,wsize=32768
8.659 Mbit/s with udp,async,wsize=16384

denn grundsätzlich ist ja beim Streamen nur die Schreibrate und die auch nur für manche ö/r relevant.

Die Werte wären natürlich total in Ordnung und es kommt mir in der Tat nur auf die Schreibwerte an. Diese sind allerdings durchaus nicht nur für manche ÖR-Sender interessant. Ich habe immer wieder - selbst bei der schnelleren Notebook-Lösung - Abbrüche beim Aufnehmen von Premiere, weil die Daten nicht schnell genug geschrieben werden konnten. OK, ich nehme dabei alle drei Tonspuren auf, aber grundsätzlich ist da ja kein Problem. Nur braucht man eben durchaus auch auf anderen Sendern die Schreibperformance.

Jetzt wäre vor allem zu klären, ob die mit verschiedenen Testverfahren ermittelten Werte vergleichbar sind, ob also das MGB100 bei musicus aus dem Tuxbox-Forum wirklich viel schneller läuft als bei mir. Rund 9000 kBit/s und 7000 kBit/s sind ja ein gewaltiger Unterschied. Selbst mit dem Notebook komme ich nur auf 8000 kBit/s. Ich könnte mir zwar nicht recht erklären, warum das MGB100 in meiner Konfiguration so extrem ausgebremst wird, aber wenn es so wäre, wüssten wir zumindest, dass das MGB100 nicht Schuld ist und seinerseits eine wirklich super Performance hinlegt.

[marobo]

Versuch mal beim mount explizit TCP anzugeben.

Den Test werde ich auch gerne nochmal machen. Auf dem Notebook waren die Schreibwerte bei TCP deutlich schlechter als bei UDP. Aber es kann natürlich beim MGB100 anders sein. Meine oben angegebenen Werte bezogen sich auf UDP.

Ich kann es nur leider frühestens nachher ausprobieren, da ich gerne noch einen Film aufnehme und von daher nicht zuviel parallel rumspielen will.

[marobo]

Ich habe es jetzt auch mit TCP probiert. Die Werte sind hier - wie auch bei meinen früheren Tests mit dem Notebook - noch um einiges schlechter als bei UDP. Beim Schreiben komme ich auf 84-85 Sekunden (= ca. 5900 kBit/s), beim Lesen auf 75-77 Sekunden (= ca. 6500 kBit/s).

Bzgl. der Geschwindkeit allgemein sieht es so aus, als ob der Switch möglicherweise einmal mehr die entscheidende Rolle spielt. Offenbar kann das MGB100 auch bei 8k Blockgröße sehr gute Werte beim Schreiben erzielen, wenn der Switch mitspielt (siehe Testdaten aus dem Tuxbox Forum). Ich muss jetzt mal schauen, ob ich hier noch einen anderen Switch rumfliegen habe, den ich testweise einsetzen könnte. Bisher nutze ich einen alten 8-Port-Switch von Longshine (LCS883R-SW800), der offenbar bei 8k Blockgröße nur eine ziemlich schlechte Schreibrate ermöglicht, während sie bei 32k recht ordentlich ist (was das MGB100 aber bei mir momentan nicht unterstützt). Ein D-LINK DES-1005D liefert beim User musicus vom Tuxbox-Forum dagegen auch bei 8k Blockgröße absolut super Schreibwerte, die besser als 8k und 32k bei mir sind, bringt dafür aber beim Lesen nur sehr schwache Werte.

Das MGB100 bringt demnach entgegen meiner ersten Vermutung eine erstklassige Leistung und würde sich sehr gut zum Aufnehmen von der dBox 2 eignen.

[schufti]

Hi,

das tcp schlechtere Werte gibt, ist klar. Hier geht mehr overhead für die Paketverwaltung verloren (in sequence ordering, Ack, etc). Die waren übrigens auch im tuxbox-forum angegeben, aber ich habe sie mangels Relevanz nicht kopiert.

Was die "Zwischenstation" anbelangt, da gibt es viel zu beachten. Ich habe die beste Erfahrung mit WLAN-Routern gemacht, wo man einzelne Ports entsprechen konfigurieren kann. Generell danke ich, kommt es hier auf die Intelligenz der "Switch" Funktion an. Also reine Hubs sind hier wohl nicht zu gebrauchen, auch keine uralt Switches, die intern oft arge Bandbreitenprobleme und oft kein Buffering (hdx-fdx) haben.

schufti

[Tes]

Hi,

Was die "Zwischenstation" anbelangt, da gibt es viel zu beachten. Ich habe die beste Erfahrung mit WLAN-Routern gemacht, wo man einzelne Ports entsprechen konfigurieren kann. Generell danke ich, kommt es hier auf die Intelligenz der "Switch" Funktion an. Also reine Hubs sind hier wohl nicht zu gebrauchen, auch keine uralt Switches, die intern oft arge Bandbreitenprobleme und oft kein Buffering (hdx-fdx) haben.

Verwechselst du das nicht mit den alten Dual-Speed-Hubs? Ich hab noch ein paar ältere Switches (u.a. von 1999) rumliegen und die haben teilweise deutlich mehr Buffer als die aktuellen SoHo-Switches (1MB fuer 5port). Interne Bandbreitenprobleme gibts bei einigen GBit-Switches leider noch welche (neuere Versionen des SMC 8508T z.B.) , aber selbst die alten 10/100Mbit-Teile hatten damit keine Probleme (fuer 8 Ports braucht man 800MBit interne Bandbreite, ist nicht wirklich schwer). Einen anderen Switch zu probieren kann aber von Vorteil sein, es ist selten aber kommt vor, dass sich Geräte einfach nicht mögen.

Tes

[schufti]

Hi Tes,
also ich meinte damit so Teile, die sich damals " 10/100 switching Hub" nannten und mit Werten wie "8kB Arp Table" warben.

Ich kann mich nur daran erinneren, dass viele schon bei 2 100Mb fullduplex Connections Bandbreitenprobleme bekamen.

schufti

[Tes]

Hallo zusammen,

heute habe ich nochmal ein paar Tests gemacht um einen Verdacht auszuräumen.

Wenn ich von der kleinen (500MB), relativ leeren Bootpartition eines der Backups des autobootfs per FTP ziehe bekomme ich ca. 5.5MB/sec. Mache ich dasselbe von der grossen, ziemlich vollen Datenpartition sind es nur noch knapp unter 4MB/sec. Bei NFS sah es ähnlich aus.

Kann es sein, dass sich hier das begrenzte RAM und CPU-Leistung bemerkbar machen? Nicht das das stoert, ist immer noch schnell genug... Zumindest sieht es aber so aus, als wenn das neue Image doch nicht langsamer ist als das Original.

Hier noch ein Bug im 2.4.35-Image: Es macht keinen sauberen Unmount beim 'halt' oder 'reboot'. Wenn man das vor dem Reboot nicht von Hand macht freut man freut man sich beim nächsten Boot über die Warnung im 'dmesg' und wenn die Datenplatte recht gross ist (80GB und mehr) kann der 'e2fsck' im Bereich von 1 Stunde dauern und funktioniert ohne aktives swap gar nicht.

Falls hier jemand die fehlenden LEDs fuer das Ethernet nachrüsten will (im Moment gibts ja nur LINK/ACT), hier gibts das Datenblatt zum verbauten PHY: http://www.icplus.com.tw/Data/Datash...1-20070829.pdf damit könnte man LEDs für 10, 100 und COL/FDX einbauen. Ebenso könnte man das Interface per Schalter fest auf z.B. 10HDX einstellen. Details siehe S.24/25 des Datenblattes.

Viel Spass...

Tes