WL-HDD Alternative

[schufti]

Hi,

rebrand_MGB100.zip

muß mittels tftp (recoveryloader) eingespielt werden, danach die gewünschte orig. FW

Kannst ja schauen, ob die Kiste dann stabiler läuft ....

schufti

@Tes: hast du ein ethtool für nen 2.4er oder 2.6er Kernel versucht?

[Tes]

Hi,


@Tes: hast du ein ethtool für nen 2.4er oder 2.6er Kernel versucht?

Nur das was ich ueber ipkg bekommen konnte. War u.U. fuer 2.6 gedacht. Falls du eines fuer 2.4.x hast bin ich bereit es auszuprobieren.

Tes

[marobo]

So langsam sollte man in Richtung Garantiefall denken. Jetzt fehlt nur noch eine Moeglichkeit mit der man das Original-PEARL-Image wieder aufspielen kann.

An einen Garantiefall habe ich auch schon gedacht. Die Frage ist, ob die Box beim Original-Pearl-Image auch abschmiert. Bisher scheint es mir so, als ob er möglicherweise nur unter der Pagano-V4-Update-Firmware mit autobootfs abschmiert. Außerdem wäre es nun schon extremes Pech, wenn ich zufällig ein "Montagsgerät" erwischt hätte, nachdem das bisher keinem anderen hier passiert ist.

Ich habe es übrigens eben nochmal probiert: MGB100 einfach nur gestartet, ohne LAN-Kabel anzuschließen und ohne jegliche WLAN-Zugriffe. Ergebnis: Auch wieder Absturz. Irgendwas läuft da offenbar ganz und gar nicht so wie es soll.

Ich werde jetzt nochmal alles neu herunterladen, aufspielen und schauen, ob das Problem bleibt.

Noch eine Frage wegen des NFS-Servers: Ist es richtig, dass der nfs-kernel-server im Gegensatz zum nfs-server auch NFSv3 (und damit Dateien >2 GB) unterstützt? Unterstützt der nfs-kernel-server auch rsize/wsize=32768? Letzteres wohl schon, denn grundsätzlich lief eine Aufnahme mit diesen Parametern von der dBox2 vorhin ja schon mal eine gewisse Zeit - jedenfalls bis zum nächsten Absturz...

Thermische Probleme hat das Teil IMHO keine. Die Kiste wird nicht besonders warm und laeuft auch bei mehr als 25Grad Raumtemperatur noch problemlos.

Hätte ich mir eigentlich auch nicht vorstellen können. Die Platte erzeugt zwar durchaus eine gewisse Wärme, aber so warm wird es nun auch nicht.

Tja, wenn sonst noch jemand Ideen hat, nur her damit...

[schufti]

Hi marobo,

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

Ich nehme an, du mountest in der dBox eh mit udp, oder?

Ein möglicher Fehler wäre auch ein instabiles Netzteil. Gerade bei den billigen Stecker-Schaltnetzteilen kann es Probleme geben. Kannst du mal ein anderes testen, irgendwas mit 5V/1A reicht.

ich nehme an, dass es auch mit der Pearl FW keine Änderung gibt.

schufti

[marobo]

Ich habe jetzt alles neu installiert, aber um es kurz zu machen: Das Ergebnis ist weiterhin das gleiche. Ich hatte eben mal den Verdacht, dass der nfs-kernel-server bei seiner Installation vielleicht Unheil anrichtet. Aber daraufhin habe ich nochmal neu installiert und als einziges Package den pure-ftpd via ipkg installiert. Ansonsten habe ich nur einige Konfigdateien minimal angepasst (IP-Adresse geändert, SSID geändert etc.). Aber die Box stürzt nach wie vor in gleicher Weise unreproduzierbar ab.

Das mit dem Netzteil klingt plausibel, aber ich verwende natürlich das Original-Netzteil von Pearl. Packen die so einen Mist bei, dass die Box dadurch evtl. nicht zuverlässig läuft? Klingt für mich fast ein wenig unwahrscheinlich. Ich glaube nicht, dass ich hier so ein Netzteil rumfliegen habe, aber ich muss mal schauen. Dann kann ich den Test vielleicht auch noch machen.

Ansonsten werde ich wohl gleich mal versuchen auf die Pearl-Firmware zurück zu gehen, um zu schauen, ob das Problem da genauso auftritt.

Vielen Dank schon mal Euch beiden - tes und schufti - für Eure Unterstützung. Ich hoffe es bringt am Ende was. Wer sonst noch Ideen hat, immer her damit...

[marobo]

Tja, auch ein anderes Netzteil hat leider keine Änderung gebracht...

Ich habe eben mal versucht, die Pearl-Back-Firmware im Recovery-Modus einzuspielen. Die Datei wurde jeweils in 3-4 Sekunden übertragen, aber sie wurde offenbar nicht von der Box angenommen. Jedenfalls habe ich jetzt noch immer die Pagano-V4-Firmware drauf. Über's Webinterface (ohne autobootfs) müsste ich doch zumindest die CHD2WLANU_R400b7unlock.BIN einspielen können, oder? Das funktioniert leider auch nicht.

Inzwischen bin ich bzgl. der Box ziemlich ratlos und würde einen Defekt nicht für so ganz unwahrscheinlich halten. Zum Reklamieren müsste ich natürlich erst wieder die Pearl-Firmware auf die Box bekommen. Dabei könnte ich dann auch testen, ob der Fehler hier weiterhin auftritt.

Hat jemand Erfahrungen mit der Reklamationsbearbeitung von Pearl? Die schnellsten sind sie vermutlich nicht, oder? Aber wenn ich mir jetzt die Box neu bestelle, dauert es auch locker 7-10 Tage bis sie hier ist *grr*

[Tes]

Noch eine Frage wegen des NFS-Servers: Ist es richtig, dass der nfs-kernel-server im Gegensatz zum nfs-server auch NFSv3 (und damit Dateien >2 GB) unterstützt?

Ja, funktioniert. Abgesehen davon ist er auch deutlich fixer.

Unterstützt der nfs-kernel-server auch rsize/wsize=32768?

Ja, ist aber von Nachteil. Ich hab gestern mal ein paar Messungen gemacht und die besten Ergebnisse bekam ich bei rsize/wsize=16384 bzw 8192 (identische Werte), bei 4096 und 32768 war es jeweils langsamer. Der Default scheint 8192 zu sein da ich auch komplett ohne Angabe die besten Werte bekam.

Tes

[Tes]

Hi marobo,

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

Sicher? Ich habe hier noch einen anderen NFS-Server der mit 2.4.26 laeuft und dort benutze ich rsize/wsize=16384. Zu 8192 ist ein deutlicher Unterschied messbar, gepatched habe ich nichts.

Ein möglicher Fehler wäre auch ein instabiles Netzteil. Gerade bei den billigen Stecker-Schaltnetzteilen kann es Probleme geben. Kannst du mal ein anderes testen, irgendwas mit 5V/1A reicht.

Besonders gut scheint das Netzteil nicht zu sein, vor allem beim Anlauf macht meines gerne Aerger. Das MGB100 laeuft hier nur dann sicher an wenn ich zuerst das Netzteil einstecke und dann mit der Box verbinde.

Sicher das 5V 1A reichen? Nachgemessen habe ich noch nicht, aber HD, WLAN , CPU usw. sollten eigentlich ueber 1A ergeben. Die 3A sind incl. Reserven IMHO so geplant: 1A fuer die Platine, 1A fuer die HD und 2 x 500mA fuer USB-devices.

Tes

[marobo]

Ja, funktioniert. Abgesehen davon ist er auch deutlich fixer.

Und der NFS-Server, der standardmäßig im autobootfs ist, kann nur NFSv2?

Zumindest im Zusammenspiel mit der dBox2 dürfte es wohl keinen Geschwindigkeitsunterschied geben. Aber die dBox2 nutzt mit ihrem 10-MBit/s-LAN die mögliche Geschwindigkeit eines NFS-Servers auch nicht aus. Wenn mich die Box lässt, werde ich den NFS-Kernel-Server gleich auch nochmal etwas testen.

Ja, ist aber von Nachteil. Ich hab gestern mal ein paar Messungen gemacht und die besten Ergebnisse bekam ich bei rsize/wsize=16384 bzw 8192 (identische Werte), bei 4096 und 32768 war es jeweils langsamer. Der Default scheint 8192 zu sein da ich auch komplett ohne Angabe die besten Werte bekam.

Ich habe jetzt auch mal ein paar Messungen gemacht. Zumindest im Zusammenspiel mit der dBox scheint es keine Unterschiede zu machen, welche Blockgröße man verwendet. Hier die Zeiten für eine ca. 62 MB große Datei (jeweils 3 Messungen, Zeiten in Sekunden)

schreiben 32k: 73,85 / 72,57 / 72,45
lesen 32k: 70,11 / 69,49 / 67,21

schreiben 16k: 72,56 / 73,75 / 73,01
lesen 16k: 67,52 / 68,92 / 67,87

schreiben 8k: 73,34 / 71,87 / 72,71
lesen 8k: 68,13 / 68,46 / 68,13

Erst bei 4k fällt die Transferrate dann merklich ab:

schreiben 4k: 92,43 / 91,64 / 92,56
lesen 4k: 72,99 / 73,38 / 73,20

Wie gesagt: Die dBox2 reizt sicher die maximalen Möglichkeiten des MGB100 nicht aus. Trotzdem oder gerade deswegen würde mich interessieren, warum das MGB100 soviel langsamer ist als ein Notebook mit dem Allegro-NFS-Server, das ich alternativ am gleichen Kabel und am gleichen Switch mit der dBox2 verbinde. Zum Vergleich hier mal die Testwerte:

schreiben 32k: 62,75 / 62,96 / 62,26
lesen 32k: 58,98 / 58,37 / 57,50

Hat jemand noch eine Idee, warum das MGB100 soviel langsamer ist und was man zur Geschwindigkeitssteigerung noch probieren könnte? So wäre das MGB100 als NAS für die dBox2 quasi nicht zu gebrauchen.

Übrigens habe ich inzwischen doch die Vermutung, dass es irgendein thermisches Problem sein könnte. Nachdem die Box die Nacht über einige Stunden lang aus war, konnte ich vorhin rund 15 Minuten am Stück testen - ohne Absturz. Danach war dann meistens schon nach 1-3 Minuten Schluss. Grundsätzlich kann es natürlich auch Zufall sein. Außerdem scheint es mir so, als wenn die Box mit offenem Gehäuse minimal stabiler läuft als mit geschlossenem Gehäuse, wo sich die Abwärme der HD natürlich eher im Gehäuse sammeln kann.

Das ganze muss ja auch nicht unbedingt ein thermisches Problem der Box allgemein zu sein. Vielleicht gibt es in meiner Box eine kalte Lötstelle o. ä. Mir wird wohl nichts anderes übrig bleiben, als ein weiteres MGB100 bei Pearl zu bestellen, um zu sehen, ob die Probleme da nicht auftauchen.

[schufti]

Hi,

die 5V/1A waren auch nur für Testzwecke ohne weitere Peripherie gedacht, da marobo die Ausfälle ja auch mit nur USB hatte.

Könnt ihr mal schauen, was z.B. die Transferraten im MGB100 sind (cat x.y >/dev/null o.ä.) und mit hdparm mal schauen ob der Kontroller mit DMA läuft? Die Platte die ich zu Testzwecken verwende (40MB) unterstützt das nämlich noch gar nicht

marobo: kannst du mal ein cat /dev/mtd0 > fw.bin machen, dann mit einem HexEditor den Bereich 0x3F8000 - 0x3F803F (enthält 'Li', deine MAC und 2x Herstellerkennung) extrahieren und mir per PM zukommen lassen. Ich werde dann versuchen, das nachzuvollziehen und dir eine entspr. Version zu erstellen.

Ich glaube, ich sollte mal eine ordentliches unlock/back Paar zusammenstellen und hochladen...

edit:
zu den Speedtests: sind die wirklich so falsch? oder sollte man mal die FW testen? Wenn die Zeiten von marobo stimmen, wären das < 1MByte/sec ???

schufti

[marobo]

Speedtests: sind die wirklich so falsch? oder sollte man mal die FW testen? Wenn die Zeiten von marobo stimmen, wären das < 1MByte/sec ???

Halt! Ich habe den Transfer von der dBox2 zum MGB100 getestet. Die dBox2 hat nur ein 10-MBit-Ethernet! Insofern liegt der theoretisch bestmögliche Wert bei etwa 50 Sekunden. In der Praxis erreiche ich mit dem Notebook beim Lesen zumindest 57-58 Sekunden.

Ich habe jetzt übrigens die Box bei Pearl neu bestellt. Mal schauen, ob ich neue Erkenntnisse bekomme, wenn die Lieferung hier ist. Beim ersten Mal dauerte es allerdings rund 10 Tage, bis das Paket da war.

[Tes]

Hi,


Könnt ihr mal schauen, was z.B. die Transferraten im MGB100 sind (cat x.y >/dev/null o.ä.) und mit hdparm mal schauen ob der Kontroller mit DMA läuft? Die Platte die ich zu Testzwecken verwende (40MB) unterstützt das nämlich noch gar nicht

40MB? Wo hast du denn diese Antiquitaet her?

#> hdparm -tT /dev/hda1

/dev/hda1:
 Timing cached reads:   156 MB in  2.03 seconds =  76.85 MB/sec
 Timing buffered disk reads:   44 MB in  3.07 seconds =  14.33 MB/sec
#> hdparm -d /dev/hda

/dev/hda:
 using_dma    =  1 (on)

Der Test mit cat nach /dev/null ergab bei einer Datei mit 166MB 14sec, also knapp unter 12MB/sec.

edit:
zu den Speedtests: sind die wirklich so falsch? oder sollte man mal die FW testen? Wenn die Zeiten von marobo stimmen, wären das < 1MByte/sec ???

Mit der dbox2 als Gegenstelle. Die kann nur 10Mbit HDX. Also maximal 1MB/sec. Wenn ich das mit einer Gegenstelle mache die 100Mbit oder GBit kann sind schreibend 3.7Mb/sec machbar und lesend 5 MB/sec, jedenfalls im Moment wo die interne HD ziemlich voll ist.

Marobo sollte es mal ueber Samba probieren, vielleicht kommt das besser mit 10Mbit zurecht? Oder gibts keinen 'smbmount' fuer die dbox2?

Tes

[Tes]

Und der NFS-Server, der standardmäßig im autobootfs ist, kann nur NFSv2?

Hab ich nie getestet. Aber er kann keine Dateien mit mehr als 2GB und laeuft komplett im Userspace was die Sache zusaetzlich verlangsamt. Kernel-NFS ist ein Muss wenn man es ernsthaft benutzen will.

Tes

[schufti]

Hi,

na das sind doch eh recht schöne Werte. Wenn wir nun auch die dBox zur reibungslosen Zusammenarbeit überreden können ....

probiert mal das ethtool im Anhang aus. Ist für den Kernel in meinem Image kompiliert (allerdings im Büro und auf die Schnelle). Nicht vergessen zu entzippen und chmod 777 !

schufti

[Tes]

Hi,


probiert mal das ethtool im Anhang aus. Ist für den Kernel in meinem Image kompiliert (allerdings im Büro und auf die Schnelle). Nicht vergessen zu entzippen und chmod 777 !

#> ./ethtool eth1
Settings for eth1:
No data available

#> ./ethtool -k eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device tx csum settings: Operation not supported
Cannot get device scatter-gather settings: Operation not supported
Cannot get device tcp segmentation offload settings: Operation not supported
Cannot get device udp large send offload settings: Operation not supported
Cannot get device generic segmentation offload settings: Operation not supported
no offload info available

Erinnert mich irgendwie an meine letzten Versuche.

Tes