WL-HDD Alternative

Printable View

Show 40 post(s) from this thread on one page

19-08-2007, 10:57
schufti

1 Attachment(s)

Hi,

@Tes: schön, dass ein paar Dinge in meinem Image Anklang finden.
Leider ist es mir noch nicht gelungen, das mii-/ethertool zur Zusammenarbeit mit dem Treiber zu bekommen. Aber ich habe im neuen Treiber das NAPI aktiviert, das einen besseren Rx Durchsatz haben soll. Ein neues Image gibts weiter hinten.

Falls es im Forum noch echte Desperados gibt, habe ich im Anhang ein update-file, das einen RedBoot ins Flash schreibt. Dieser liegt ab 0xFFFE0000 im ROM, überschreibt also das original BIOS und den Recovery-Loader. Wer nicht weiß, was er da tut, sollte die Finger davon lassen, die Anderen sollten sich davor auf alle Fälle über

Code:

cat /dev/mtd0 > myImage.bin

eine Sicherung ihres ROM auf den USB machen. Trotzdem könnt ihr euch damit ganz einfach die Box zerschießen!!!! Dann hilft nurmehr JTAG

!!!Serielle Konsole absolut notwendig !!!

Code:

RAM: 0x00000000-0x000f0000, 0x00072390-0x000a0000 available MGB100-RB by Schufti 07/08/07 <press Ctrl+C to enter prompt mode> RedBoot> ^C RedBoot> RedBoot> ip_address -l 192.168.22.108 IP: 192.168.22.108, Default server: 0.0.0.0 RedBoot> load -r -v -m tftp -h 192.168.22.55 -b 0x400000 orig_bl.bin | Raw file loaded 0x00400000-0x0040ffff, assumed entry at 0x00400000 RedBoot> fl -s 0x400000 -d 0xffff0000 -l 0x10000 NOR Flash ID = 22a7 [First Sector=3fh,Last Sector=46h] Erase sector........ Programming...

Ich habe im Beispiel nur den Bereich des orig. BL überschrieben (nein, eigentlich auch den des GUI), den Kernel habe ich nicht angetastet. Daher genügt es, den Bereich 0xfffe0000-0xffffffff zurückzuschreiben um den Recoveryloader wieder verwenden zu können. Wie gesagt, in dem Bereich liegt auch eure MAC, also verwendet EURE Sicherung.

schufti
19-08-2007, 13:27
Tes

Quote:

Originally Posted by schufti

Hi,

@Tes: schön, dass ein paar Dinge in meinem Image Anklang finden.
Leider ist es mir noch nicht gelungen, das mii-/ethertool zur Zusammenarbeit mit dem Treiber zu bekommen.

Es gibt auch keine Möglichkeit dem Treiber zumindest mal debug Output beizubringen? Also das er ins dmesg schreibt wenn er den Link verliert bzw. meldet wenn er einen Link bekommt und was fuer einen. Mit nur einer LED für Lnk/Act ist das ganze etwas sparsam bestückt wenn es mal Probleme gibt.

Quote:

Aber ich habe im neuen Treiber das NAPI aktiviert, das einen besseren Rx Durchsatz haben soll. Ein neues Image gibts hier.

Werde ich mir mal ansehen, aber ich kann nicht versprechen, dass ich das in den nächten Tagen gleich reinflashe. Mehr Tx Durchsatz wäre mir lieber. :)

Tes
21-08-2007, 18:24
schufti

Hi!

Ich habe mich mal sehr zusammengerissen und - entgegen meiner Gewohnheit - alle Erkenntnisse geordnet in einem WiKi-Beitrag zusammengefasst.

schufti
22-08-2007, 06:18
wengi

DAS IST EINEN APPLAUS WERT :cool:
Danke schön.
Ich bin in diesem Thread zwar nicht sehr aktiv, verfolge das Ganze aber mit großem Interesse. Immerhin liegt hier auch noch eine Perle, die bearbeitet werden will :D

wengi
22-08-2007, 19:23
marobo

Quote:

Originally Posted by schufti

Hi,

@ Tes: ja, es gibt die Sourcen für den R6040. Und ich habe gerade gesehen, dass eine neuere Version im RDC-Devkit ist. Werde die mal in mein image kompilieren...

@ marobo: habe das Konzept des x-upgrade verlassen und stelle Files zum "Rebranden" der Box bereit. So kann sich jeder aussuchen, was seine Box sein soll... Anleitung liegt bei.

schufti

Ich konnte mich jetzt mal wieder mit der Box beschäftigen und habe versucht, die Pearl.bin aus Deinem Archiv im Recovery-Modus zu flashen.

Also:
- Recovery-Modus bei der Box gestartet
- Per TFTP die Pearl.bin hochgeladen (tftp -i 192.168.123.254 PUT Pearl.bin)
- Ca. eine Minute gewartet
- Dann Strom gezogen, um neu zu booten

Jetzt ist die Box allerdings leider gar nicht mehr zu erreichen - weder über die 192.168.123.254, noch über die 192.168.2.1. Ein Ping geht nicht und ein Zugriff auf das Webinterface schon gar nicht, um die Firmware zu flashen.

Was kann ich nun machen? Wenn ich die Box versuche nochmal im Recovery-Modus zu starten, kommt zwar noch das schnelle Blinken der linken LEDs. Aber auch dann ist die Box nicht mehr unter der 192.168.123.254 erreichbar. Habe ich meine Box nun endgültig geschrottet? :(
22-08-2007, 20:11
marobo

(Teilweise) Entwarnung. Dass die Box auch im Recovery-Modus nicht mehr erreichbar war, hatte wohl nur einmal mehr damit zu tun, dass meine Box einfach nach einigen Minuten Betrieb immer mehr rumspinnt. Lässt man sie 15 Min. ausgeschaltet liegen, normalisiert sich das ganze wieder. (Thermisches Problem?!?)

Also: Im Recovery-Modus kann ich die Box weiterhin über die 192.168.123.254 anpingen und Files per TFTP übertragen.

Aber: Starte ich die Box normal, habe ich weiterhin keinen Zugriff auf die Box, weder unter der 192.168.123.254, noch unter der 192.168.2.1. Ich habe im Recovery-Modus verschiedene Firmwaredateien ausprobiert zu flashen. Nach der Pearl.bin aus dem Rebranding-Package ganz am Anfang (die ja wohl nur auf "Pearl" zurückbrandet, damit die Pearl-Firmware-Dateien wieder akzeptiert werden) habe ich die Original-Pearl V4.00b7 versucht, wie auch die Pearl_back.BIN. Wie gesagt: Ich bekomme beim normalen Start jetzt einfach keine Verbindung mehr zur Box. Anscheinend ist nach der Flasherei momentan keine funktionierende Firmware in der Box.

Mein Ziel ist es, die Box wieder zurück auf eine Pearl-Firmware zu bekommen. Ich will die Box in den nächsten Tagen an Pearl zurückschicken und da sollte natürlich nicht irgendeine ominöse Firmware drauf sein ;) Vielleicht könnte mir dabei nochmal jemand helfen, insbesondere Du, schufti.

In Kürze wird wohl auch meine neue Pearl-Box hier eintreffen. Ich bin schon sehr, sehr gespannt, ob diese auch dieses - offenbar völlig merkwürdige und untypische - Verhalten zeigt. Ich vermute ja inzwischen sehr stark, dass meine derzeitige Box irgendeinen Defekt hat. Demnach gehe ich davon aus, dass die neue Box endlich so funktioniert, wie sie es soll und wie sie es bei Euch auch tut.
22-08-2007, 21:03
schufti

Hi!

Leider hatte das letzte napi Image einen Fehler (Box kommt nicht mehr hoch, nur mehr recovery möglich). Da ich mittlerweile aber schon wieder weiter gefrickelt habe, gibts hier jetzt was neueres.

@marobo: wie lange dauert denn so ein original FW upload per recovery loader? Eine Minute warten nützt nix, wenn die Übertragung schon nach wenigen Sekunden fertig ist (abbricht). Ev. wird die SW ja bloß nicht akzeptiert??? Ich kann mir sonst nicht vorstellen, was da nicht in Ordnung ist. Wenn man in der recovery loader kommt, dann ist das BIOS in Ordnung, weil es ja den Kernel startet. Und selbst das würde beim Flashen einer orig. FW neu beschrieben (außer bei Pearl natürlich ....)

Was macht denn z.B. die WLAN LED, oder die USB wenn du was ansteckst?

schufti
22-08-2007, 21:13
marobo

Anscheinend brauchte die Box mal wieder Streicheleinheiten und 15 Minuten Pause. Jedenfalls klappte es eben dann ohne weitere Flash-Versuche auf einmal doch.

Ich denke die geschilderten Probleme beim Zurückflashen der Pearl-Firmware liegen wohl gänzlich in der defekten Box begründet. Jedenfalls habe ich jetzt offenbar wieder eine laufende Box mit der Pearl-FW 4.00b7 in Default-Settings. Ich werde diese besser nicht mehr anrühren. Hoffentlich kommt morgen die Pearl-Lieferung mit der neuen Box.

Auf jeden Fall Dir, schufti, vielen Dank für Deine Unterstützung!
22-08-2007, 21:37
schufti

Hi marobo,

na dann hoffen wir noch auf ein

"Ende gut, alles gut"

lg,
schufti

P.S.: jetzt könnt ihr Euch mal denken, wie es mir beim FW frickeln geht, wenn nach jeder 2. Änderung das System nichtmehr initialisiert (kernelpanic: attempted to kill init) oder der kernel gar nicht bootet. Da wird mächtig Zeit versch..... für jeden Fehler: FW jedesmal mit orig FW flashen, upgrade flashen, Einstellungen flashen oder JTAG full Image -> ca. 15min pro Durchgang
22-08-2007, 22:55
marobo

Das kann ich mir gut vorstellen... :cool:
23-08-2007, 12:32
marobo

So, gute Nachrichten! Die neue Box von Pearl ist tatsächlich vorhin gekommen und sie LÄUFT :) Jedenfalls hab ich schon wunderbar die Paganos V4 Firmware mit autobootfs auf der Box und da alles mögliche konfiguriert. Bis dahin hatte die alte Box schon zig mal rumgezickt und absolut nicht das getan, was sie eigentlich hätte tun sollen. Es sieht also sehr gut aus.

Man beginnt ja schon ein wenig zu verzweifeln, wenn man genau die Schritte macht, die andere auch gemacht haben, aber es einfach nicht richtig klappen will und die Box auf einmal ständig neu startet. Ich hatte ja vorher noch kein anderes Exemplar des MGB100 in Händen, um auf den ersten Blick beurteilen zu können, ob das Verhalten eventuell doch normal ist, ob ich irgendeinen Fehler gemacht habe etc. Aber wenn natürlich ein Defekt die Ursache ist, kann man lange rumprobieren :rolleyes:

Ich werde nachher nochmal den Geschwindigkeitstest in Bezug auf NFS im Zusammenspiel mit der dBox 2 versuchen, wobei ich nicht davon ausgehe, dass sich an den bisherigen Werten was ändert; auf diese dürfte der Defekt eigentlich keine Auswirkungen gehabt haben. Wenn es so bleibt wie bisher, wäre das MGB100 beim NFS mit der dBox 2 vergleichsweise langsam und daher für das Zusammenspiel mit der dBox 2 nur bedingt geeignet. Eigentlich kann es nicht an der Rechenpower der Box an sich liegen, dass die Box deutlich langsamer beim Lesen und Schreiben als ein Notebook mit Allegro oder HaneWin NFS-Server ist. Die dBox 2 hat ja nur 10 MBit Ethernet und diese Datenmenge sollte das MGB100 mit der HDD sicher problemlos handlen können. Die sonstige Konstellation (Verbindung zur dBox 2 über Switch) ist ja gegenüber der Notebooklösung unverändert, wenn man das gleiche LAN-Kabel wechselseitig im Notebook und MGB100 nutzt. Also müsste der Flaschenhals doch irgendwo im Bereich des MGB100 zu suchen sein und sich möglicherweise mit irgendwelchen Änderungen in der Konfiguration etc. beheben lassen.

Deshalb die Frage: Hat jemand eine Idee, wie man die NFS-Geschwindigkeit im Zusammenspiel mit der dBox 2 noch erhöhen könnte?
23-08-2007, 16:53
marobo

Noch kurz zur Ergänzung: Die NFS-Geschwindigkeitstests mit der dBox 2 ergeben leider immer noch die gleichen (relativ schlechten) Werte. Und nach einigen Härtetests kann ich nun sagen, dass die alte Box definitiv einen Defekt gehabt haben muss. Mit der neuen läuft (endlich) alles wunderbar.
23-08-2007, 18:04
Tes

Quote:

Originally Posted by marobo

Noch kurz zur Ergänzung: Die NFS-Geschwindigkeitstests mit der dBox 2 ergeben leider immer noch die gleichen (relativ schlechten) Werte. Und nach einigen Härtetests kann ich nun sagen, dass die alte Box definitiv einen Defekt gehabt haben muss. Mit der neuen läuft (endlich) alles wunderbar.

Welchen NFS-Server benutzt du? Der beim autobootfs vorinstallierte ist der Userspace NFSd, der ist relativ langsam. Du solltest deine Versuche mit dem Kernel-NFSd machen, der ist deutlich schneller. Wie man den installiert hatte ich hier beschrieben (einige Seiten vorher).

Tes
23-08-2007, 18:19
Tes

Quote:

Originally Posted by schufti

Hi!

Leider hatte das letzte napi Image einen Fehler (Box kommt nicht mehr hoch, nur mehr recovery möglich). Da ich mittlerweile aber schon wieder weiter gefrickelt habe, gibts hier jetzt was neueres.

Ups... Wie gut, dass ich noch keine Zeit hatte das auszuprobieren. Gibts (abgesehen vom funktionierenden Netz :)) sonst neue Features in der 400S2?

Hat schon jemand eine Idee was man mit den beiden Knöpfen an der Seite anstellen könnte bzw. wie man sie abfragt? Zumindest ein sauberer Shutdown darüber wäre nett.

Tes
23-08-2007, 18:31
marobo

Quote:

Originally Posted by Tes

Welchen NFS-Server benutzt du? Der beim autobootfs vorinstallierte ist der Userspace NFSd, der ist relativ langsam. Du solltest deine Versuche mit dem Kernel-NFSd machen, der ist deutlich schneller. Wie man den installiert hatte ich hier beschrieben (einige Seiten vorher).

Tes

Ich benutze den kernel-nfsd genau wie von Dir beschrieben installiert, also schon den schnelleren. Wobei der Userspace-nfsd glaube ich bei früheren Tests auch nicht langsamer war. Das 10-MBit-Ethernet von der dBox 2 reizt also anscheinend auch den Userspace-nfsd nicht aus.
23-08-2007, 20:54
schufti

Hi,

also im s02 image ist eigentlich nix neues für feature freaks. Ich habe nur die Initialisierung aufgeräumt (und auf autobootfs Kompatibilität mit dem KK geachtet). Das einzig andere ist der NAPI Netzwerktreiber. Leider gibt es nichts neues auf der mii-tool Front. Habe den neuen Treiber mal dem maintainer des KK-RDC Zweigs geschickt. Er wird ihn sich mal ansehen, ist ja ev. auch für die KK interessant, um die Parameter ändern zu können.

Da die nfs Leistung der Box mit "normalen" Clients doch recht gut ist, würde ich die Schuldfrage mal zu Ungunsten der dBox enscheiden; zumal das Teil an allen anderen Netzwerkgeräten zickt wenn man dort nicht auf 10Mb/hd fixt. Allerdings hat bei mir ein Switch/Router mit 10er Port Richtung dBox immer zur Problemlösung gereicht (dzt. gehe ich von der dBox über 10m stillgelegte Telefonleitung auf meinen SE505 mit DD-WRT - Port auf 10Mb/hd gesetzt - dann auf den PC mit udrec). Falls es ev. doch an den nfs Parametern liegt, auf dem KK sollte Mono und udrec ja auch laufen....

Dzt. bin ich am 2.6er Kernel testen. Generell läuft er schon ordentlich hoch, hat aber scheinbar Probleme mit der unorthodoxen Verwendung von initrd; auch bin ich nicht sicher ob alle AMIT Binaries laufen. Aber der recovery-loader ist schon mal aus dem Kernel zu erreichen und - wenn ich nicht aus Platzgründen auf USB im Kernel verzichtet hätte - würde vermutlich auch das autobootfs (somit KK) laufen. Womit das KK endlich den vorgesehenen Unterbau hätte.

Was die Taster angeht: Da dürft ihr selbst mal experimentieren. Eins der AMIT Binaries muß ja wohl die Taster überwachen. Und vermutlich werden dann die Skripts backup_usb und halt_system aufgerufen. Gleichzeitig könnte man dann ja auch das led Binary verwenden, um Rückmeldungen zu implementieren.

schufti
24-08-2007, 22:05
marobo

Quote:

Originally Posted by schufti

Da die nfs Leistung der Box mit "normalen" Clients doch recht gut ist, würde ich die Schuldfrage mal zu Ungunsten der dBox enscheiden; zumal das Teil an allen anderen Netzwerkgeräten zickt wenn man dort nicht auf 10Mb/hd fixt. Allerdings hat bei mir ein Switch/Router mit 10er Port Richtung dBox immer zur Problemlösung gereicht (dzt. gehe ich von der dBox über 10m stillgelegte Telefonleitung auf meinen SE505 mit DD-WRT - Port auf 10Mb/hd gesetzt - dann auf den PC mit udrec). Falls es ev. doch an den nfs Parametern liegt, auf dem KK sollte Mono und udrec ja auch laufen....

Könntest Du zum Vergleich auch mal die Geschwindigkeitstests in Deiner Umgebung machen und posten? Dazu müsstest Du per Telnet auf die dBox 2 gehen und die beiden folgenden Befehle eingeben (am besten mehrmals wiederholen wg. leichten Schwankungen der Werte):

time cat /proc/kcore > /mnt/filme/test
time cat /mnt/filme/test > /dev/null

wobei /mnt/filme das gemountete Verzeichnis auf dem MGB100 wäre.

Mit dem Notebook erreiche ich Werte von etwa 62/58 Sekunden (schreiben/lesen), mit dem MGB100 sind sie jeweils etwa 10 Sekunden langsamer.
25-08-2007, 09:31
schufti

Hi marobo,

würde ich gerne machen, aber auf meine 2,5" Platte passen nur 40MB. Und die sind schon großteils mit dem KK Image befüllt (zu Testzwecken).

Bei mir läuft das Streamen auf dem PC recht gut, somit ist das Ganze kein 'Must Have' und eher Spaß an der Freud. Aber ich kann mal versuchen ob das auch mit meiner Archiv-Platte am USB läuft....

schufti
25-08-2007, 21:51
marobo

Stimmt, Du schriebst ja mal, dass Du mit einer 40-MB-Platte arbeitest. Beim ersten Lesen dachte ich, Du hättest Dich verschrieben und meintest in Wirklichkeit 40 GB ;-)

Theoretisch könntest Du ja zumindest mal die Autobootfs-Datei auf die dBox (ins Nulldevice) kopieren und dabei die Zeit messen - falls Du die Datei auf der Platte liegen hast. Dann hätten wir zumindest mal einen Vergleich der Lesewerte, wenn man diese auf die 62 MB Datei aus meinem Test hochrechnet.

Der Aufruf gilt natürlich auch an andere: Wer ein MGB100 und eine dBox 2 hat, könnte man seine Vergleichswerte posten, damit man beurteilen kann, ob meine Werte schon am Limit für das MGB100 sind oder ob einfach irgendwelche unbekannten Faktoren die Sache bei mir ausbremsen (was allerdings durch die Umstände, dass ich bei den Tests nur das Notebook durch das MGB100 ersetzt habe, etwas schwer vorstellbar ist). Der theoretisch bestmögliche Wert sollte bei etwa 50 Sekunden liegen, wobei in der Praxis Werte von 55-60 Sekunden wohl schon nahe am Optimum sind. Dass sich das MGB100 allerdings um die 70 Sekunden Zeit lässt, ist für mich zunächst erstmal nicht ganz nachvollziehbar.
26-08-2007, 07:27
GFR

MGB111 - Torrent Leacher - AirLive WMU-6500FS

Hi,

da hier auch das MGB111 bzw. der Torrent Leecher von Pearl behandelt wird, dazu hier eine Info:

Das Teil habe ich als AirLive WMU-6500FS gefunden (http://www.airlive.com/WMU-6500FS.htm).
Sieht man von ein paar Abweichungen bei den Voreinstellungen ab, scheint es sich um dasselbe Gerät zu handeln.

Dort findet man deutlich ausführlichere Infos zu dem Teil als bei Pearl, verschiedene
Handbücher zum Download, einige technische Infos, Firmware-Updates im Support-Bereich und einen Q&A-Bereich.

Insbesondere findet man da auch Firmware zum Download.

Bei meinem Teil lautet die Firmware-Kennung (Lieferzustand) r4.00a8.

Auf der Website findet man eine Firmware-Version R400a8 und momentan eine neuere R400A814 (WMU-6500FS Firmware Version R400A814, Fix download limited 2GB, and Forgot UPnP issue. 2007/08/14).

Bei der älteren Firmware-Version a7v3 ist ein Firmware-Upgrade-Utility (für Windows) dabei, das den Torrent Leecher von Pearl (beim zweiten Anlauf) automatisch als Upgrade-Kandidaten findet.

Probiert habe ich das Upgrade bisher nicht.
27-08-2007, 10:38
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?
27-08-2007, 14:16
marobo

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

Quote:

Originally Posted by schufti

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 :rolleyes: 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.
27-08-2007, 17:18
Tes

Quote:

Originally Posted by marobo

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).

Quote:

Kann ich ansonsten weiterhin mein bisheriges autobootfs verwenden?

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

Quote:

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.

Quote:

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
27-08-2007, 17:24
Tes

Quote:

Originally Posted by marobo

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
27-08-2007, 19:28
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.
27-08-2007, 19:45
Tes

Quote:

Originally Posted by schufti

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
27-08-2007, 19:55
marobo

Quote:

Originally Posted by Tes

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.
27-08-2007, 20:06
Tes

Quote:

Originally Posted by marobo

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
27-08-2007, 20:17
marobo

Quote:

Originally Posted by schufti

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 :)

Quote:

Originally Posted by schufti

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.
27-08-2007, 20:19
marobo

Quote:

Originally Posted by Tes

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.
28-08-2007, 07:59
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.
28-08-2007, 08:42
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
28-08-2007, 12:39
Tes

Quote:

Originally Posted by schufti

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
28-08-2007, 20:35
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
31-08-2007, 19:29
Tes

Diverses

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
31-08-2007, 20:38
schufti

Hi Tes,

ich denke nicht, dass sich mein v400s02 image da anders verhält, als das Original. Wenn man nicht über die vorgesehene Tastenkombination runterfährt wird m.E. kein vernünftiges sync oder umount gemacht.

Daher habe ich im s02er Image ja auch ein vernünftiges Init/Shutdown vorgesehen, nur im angelegten Shutdownskript fehl(t)en die Befehle. Aber für Verwender des KK-Image sollte das eigentlich egal sein, die müßen dass eh in den eigenen Skripts machen.

schufti
01-09-2007, 14:45
normancz

Hi,
hat schon mal jemand ein ipkg upgrade gemacht?

Beim Update der base-files dachte ich mehr an die basis-Binaries, aber irgendwie wurden wohl die ganzen Konfigurationsdateien übergebügelt. WLAN geht nicht, und die alte IP ist auch weg.

Leider geht auch 192.168.2.1 nicht und nun stehe ich da. Hat jemand eine Idee?
01-09-2007, 20:10
Tes

Quote:

Originally Posted by normancz

Hi,
hat schon mal jemand ein ipkg upgrade gemacht?

Nein, ich trau dem nicht, vor allem weil vieles schliesslich für 2.6 gedacht ist aber unsere Box noch mit 2.4 läuft. Zumindest würde ich es nicht tun ohne vorher ein aktuelles Backup des Autobootfs gemacht zu haben.

Quote:

Beim Update der base-files dachte ich mehr an die basis-Binaries, aber irgendwie wurden wohl die ganzen Konfigurationsdateien übergebügelt. WLAN geht nicht, und die alte IP ist auch weg.

Leider geht auch 192.168.2.1 nicht und nun stehe ich da. Hat jemand eine Idee?

Ausser ein Backup einzuspielen (ich mache nach jeder grösseren Änderung eine Kopie des Autobootfs) fällt mir nur folgendes ein... Hast du die serielle Schnittstelle rausgeführt? Wenn ja, könntest du darüber zumindest rausfinden welche IP die Kiste jetzt hat (falls das Netz noch startet) oder zumindest diesen Teil reparieren. Wo der Anschluss zu finden ist und was sonst noch fehlt wurde in diesem Thread schon beschrieben.

Alternativ kannst du das Originale 'autobootfs' nach 'autoboot' umbenennen, auf einen USB-Stick kopieren und von dem booten (der Code im Flash sucht zuerst auf USB und dann auf der internen HD). Dann das autobootfs der internen HD ueber loopback mounten und nachsehen was alles im Eimer ist.

Ich hatte allerdings auch schon Probleme mit einer neueren busybox, mit der funktionierte das 'insmod' nicht mehr und damit auch kein WLAN. Updates kritischer Programme sollte man also nur mit aktuellem Backup machen!

Tes
01-09-2007, 20:24
Tes

Quote:

Originally Posted by schufti

Hi Tes,

ich denke nicht, dass sich mein v400s02 image da anders verhält, als das Original. Wenn man nicht über die vorgesehene Tastenkombination runterfährt wird m.E. kein vernünftiges sync oder umount gemacht.

Daher habe ich im s02er Image ja auch ein vernünftiges Init/Shutdown vorgesehen, nur im angelegten Shutdownskript fehl(t)en die Befehle. Aber für Verwender des KK-Image sollte das eigentlich egal sein, die müßen dass eh in den eigenen Skripts machen.

schufti

Hin und wieder benenne ich das autobootfs um und boote den Code im Flash. Das hat 2 Gründe:

1) Bisher schaffe ich immer noch keinen sauberen umount des FS auf dem das autobootfs liegt. Also ist das FS immer unsauber. Hin und wieder mal ein e2fsck ist anzuraten. Alle anderen FS incl. autobootfs werden sauber auf read-only gesetzt oder schaffen den umount. Die dafür nötigen Einträge hatte ich hier schon gepostet.

2) Nach jeder grösseren Änderung und deren Tests mache ich ein Backup des autobootfs. Das geht nur sauber wenn es nicht gerade in Benutzung ist.

Es wäre also schon gut, wenn das Image im Flash einen sauberen umount aller Filesysteme bei 'halt' oder 'reboot' machen würde. Oder kann die eingebaute busybox keine entsprechenden Einträge in der inittab?

Natürlich könnte ich 1) und 2) auch über einen USB-Stick mit einem autobootfs erschlagen, aber das macht mehr Arbeit. Da müsste ich doch glatt zur Kiste hinlaufen und einen USB-Stick einstecken und nachher wieder abziehen... ;)

Tes
02-09-2007, 17:09
schufti

Hi Tes,

natürlich kann die neue BB das (die könnte sogar echte runlevels) und ist (wie ich schon schrieb) auch im s02 Image vorgesehen; schau mal in /etc/init.d/shutdown.rc. Über eine autoexec auf der C Platte kannst du die shutdown.rc ja durch eine angepaßte ersetzen.

das ganze läuft jetzt so ab:

der Kernel startet nach dem Boot /sbin/init wo auf Vorhandensein einer autobootfs oder autoinit getestet wird. Ist nichts davon da, wird BB als echtes Init über linucrc gestartet. Dadurch wird die inittab gelesen und das darin eingetragene Startskript gestartet (standardkonform rcS), weiters restart.rc / shutdown.rc

schufti

Show 40 post(s) from this thread on one page

All times are GMT +1. The time now is 17:48.