[Sammelthread] Der 20€ Server [Part 2]

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Schön zu hören. Ist für Leute wie dich wahrscheinlich auch die weit bessere, weil einfachere Methode. Ist halt einsteigerfreundlicher das Ganze.
Es ist sowieso nicht grade ratsam seine Linux-Erfahrungen mit einem Embedded-Device wie ner Pogoplug zu starten. Dafür gibt es Desktop-Systeme und Notebooks.
 
Ich bin kein Linuxeinsteiger und beschäftige mich hauptberuflich mit eingebetteten Systemen.
Ich habe jedoch keine Lust mit jemanden zu kommunizieren, der so eine passiv-aggressive Art an den Tag legt.
 
Ich krieg mich bald nicht mehr. Sorry! :d Aber sich hauptberuflich mit "eingebetteten Systemen" beschäftigen, aber die einfachsten Debugging-Methoden nicht anwenden. Ja nee, is klar. Lass einfach stecken deine Weisheiten und bitte versuch nicht nochmal meine Skripte zu benutzen. Die sind offensichtlich für dich nicht geeignet. Grandiose Unterhaltung.

Ein Tip noch für die Zukunft, für Profis wie dich:
Wenn man Hilfe will, dann sollte man sich 1.) an die Beschreibung zur Nutzung halten, 2.) sinnvolle und möglichst detaillierte Fehlerbeschreibungen liefern und 3.) nicht eine solch absurde Erwartungshaltung wie du an den Tag legen. Dann bekommt man für gewöhnlich auch Hilfe. ;)

Edit:
Willkommen auf der Ignore-List. :)
 
Zuletzt bearbeitet:
Jevermeister schrieb:
Ich bin kein Linuxeinsteiger und beschäftige mich hauptberuflich mit eingebetteten Systemen.
Zum Vergrößern anklicken....
Und dann ist systemd frickelig? Der war gut, systemd ist gerade der letzte Schrei weil es diese hässlichen distributionsspezifischen init Scripte endlich ablöst. Systemd kann zudem wesentlich mehr, ich seh da nur Vorteile und man kann wesentlich schneller und flexibler Automatisierungen realisieren. Das sollte man wissen wenn man hauptberuflich für embedded Systeme entwickelt. Zudem sagt die Entwicklung für embedded Systeme erst mal rein gar nichts aus, denn ich brauch nicht zwingend einen Linux Kernel (oder z.B. Windows embedded) auf einem Cortex M4 System, da kann ich auch so direkt mit C oder gar ASM arbeiten. Da muss ich keinerlei Kenntnisse von Linux haben...
 
Ich arbeite überwiegend mit C und ASM auf Steuergeräten, weswegen ich mit Linux eher im privaten Bereich seit mehr als 10 Jahren zu tun habe. Systemd ist per se überhaupt nicht frickelig, aber mit dem aktuellen OXNAS-Kernel unter Arch schon, siehe Pogoplug Pro/Video/v3 | Arch Linux ARM

Trotzdem macht der Ton mir hier zu schaffen. Ich habe weder irgendetwas gefordert noch die Arbeit von jemanden kritisiert und trotzdem werde ich sobald ich Feedback äußere wie ein Querulant behandelt und das schmeckt mir nicht.
 
celemine1Gig schrieb:
Alles vorbereitet! Meiner Pogo V3 Pro hab ich mal nen eSATA Anschluss verpasst und meinen 3.1er Kernel auf V1.6 gebracht, mit Unterstützung für alles nötige für SATA Raid5. Emdebian im NAND, mit LVM2 und MDADM. Jetzt muss nur noch das mini PCIe JMB362 Modul aus den USA kommen. Wenn's dann noch geht... :d
Zum Vergrößern anklicken....

Laut WarheadsSE gibt es Performance Probleme mit SATA und USB bei Verwendung des 3.1er Kernels. Hast Du keine Einbußen mit dem Kernel bei der Nutzung der vorhandenen USB/SATA Anschlüsse?
 
Ich hatte schlichtweg keine Zeit mehr zu testen. Das heißt es ist alles vorbereitet (PM362 fehlt leider noch), aber Performancetests mit SATA/USB stehen noch aus.
Das letzte was ich mit der Pogo Pro gemacht habe waren Stabilitätstests bei voller CPU und Speicherlast.
Aber ja, von den potenziellen Problemen hatte ich auch gelesen. Bin mal gespannt, wie schlimm sie ausfallen, sofern ich auch drauf stoße. Von Letzterem ist ja leider auszugehen.
 
Die Performance der Datenübertragung auf eine USB oder SATA Festplatte mit Deinem 2.6.31.14 Kernel ist, wie ich bereits geschrieben habe, 10-20% schlechter, als mit WarheadsSEs 2.6.31.6 Kernel. Inzwischen habe ich einen neuen Kernel mit der Konfiguration des Patcharchivs statt Deiner gebaut. Damit ist die Performance etwa auf gleicher Geschwindigkeit, wie mit WarheadsSEs Kernel. Die Frage ist, welche Option den Performance Unterschied verursacht.
Damit ist natürlich interessant, welche Performance der 3.1er Kernel hat. Wenn Du ein Gerät mit 3.1er Kernel hast, könntest Du dies einfach probieren:
Code: 
dd if=/dev/zero of=/media/usb0/test.tmp bs=500K count=1024
dd if=/media/usb0/test.tmp of=/dev/zero bs=500K count=1024
Mich interessiert natürlich die Performance des internen SATA Anschlusses.
 
Ich schau mal ob ich heute noch dazu komme ein bissl zu testen. Wollte eine meiner 4 Pogos eh noch mal unter die Lupe nehmen.
Meld mich sobald ich was neues habe. ;)
 
So, schnell mal getestet (14er Werte mit telzey's Kernel-Konfiguration):

SATA Festplatte:
2.6.31.6/14: Schreiben: 67-70 MB/s Lesen: 80-82 MB/s
3.1.10-v16: Schreiben: 38,5 MB/s Lesen: 78-79 MB/s

USB Festplatte:
2.6.31.6/14: Schreiben: 21 MB/s Lesen: 33 MB/s
3.1.10-v16: Schreiben: 18,5 MB/s Lesen: 26 MB/s

Den geringsten Einbruch gibt es beim SATA lesen, den größten beim SATA schreiben. Wenn ich mich recht entsinne, entspricht die USB Performance etwa der Performance Deiner 2.6.31.14 Kernelkonfiguration.
 
Zuletzt bearbeitet:
Vermute mal, dass es doch nur an ner Konfiguration des Kernels liegt. Kannst ja mal, falls du Zeit hast deine 2.6.14er mit meiner vergleichen. ;) Denke da könnte sich was finden. Vor allem, weil ja meine 3.1.10er Config anscheinend auch wieder langsamer ist.
 
Die Konfiguration ist von telzey: Link. Der Vergleich ist für mich wie die Suche nach der Stecknadel im Heuhaufen. Das habe ich schon probiert.

Die SATA Schreibperformance lag mit Deinem 2.6.31.14er Kernel bei ca. 56 MB/s und die Leseperformance bei 76 MB/s.
 
Zuletzt bearbeitet:
Ich schau's mir eventuell mal an heute. Das sollte gleich passiert sein. Die Entwicklungs-VM läuft nach wie vor. :)

Edit:
So auf Anhieb fällt mir nur der andere IO-Scheduler auf. Das war bei Telzey und im 2.6.31.6er der "Anticipatory", während ich in meinem 2.6.31.14 und meinem 3.1.10er den "CFQ" als Standard gewählt habe. In Sachen SATA-Konfiguration seh ich keinen Unterschied.
Ob das den Unterschied ausmacht, ich bezweifle's irgendwie. Beim 3.1.10er Kernel gibt's den alten Anticipatory eh nicht mehr.
Edit2:
Lade grade ein Paar neue 2.6.31.14er Kernel hoch. Wer Lust hat, der kann ja ein wenig damit testen. Falls einer davon wieder schneller sein sollte, bitte melden. Link ist der alte bzw. befinden sich weiterhin im gleichen Verzeichnis auf dem Server.
 
Zuletzt bearbeitet:
V15 ist aus meiner Sicht in Ordnung.

SATA Schreiben: bis zu 69 MB/s Lesen: bis zu 80 MB/s
USB Schreiben: bis zu 22 MB/s Lesen: bis zu 32 MB/s
 
Zuletzt bearbeitet:
Wieso geht ihr eigentlich nicht gleich auf Kernel 3.8? Kernel 3.1 ist dann doch schon etwas älter...
 
Ich hatte erhebliche Probleme mit USB Festplatten beim Wechsel zwischen den Kernelversionen 1.3, 1.4 und 1.5! Nach dem Wechsel ist die Performance zeitweise auf unter 1 MB/s eingebrochen. Infolge musste ich die Platte checken und die Testdatei nochmal schreiben. Es könnte sein, dass der Effekt mit dem Wechsel von Kerneloptionen verbunden ist und deshalb insbesondere beim Wechsel 1.3 -> 1.4/1.5 und umgekehrt auftrat. Das Problem tritt ebenso beim Wechsel von 1.5 auf telzeys Kernel auf. Mit der SATA Bootfestplatte hatte ich keine dieser Probleme.

Ich verwende ext4 Dateisysteme mit folgenden Mountoptionen: type ext4 (rw,noatime,errors=remount-ro,nouser_xattr,commit=100,barrier=0,nobh,data=writeback)

Insofern kann ich keine vergleichende Betrachtung machen, da der Wechsel der Kernelversion mit erheblichem Aufwand verbunden ist!

@joph: Weil OX820 nicht von Mainstream-Kernelversionen unterstützt wird. Du bist aber herzlich eingeladen uns die erforderlichen Patches für die neueren Kernelversionen zur Verfügung zu stellen.
 
Zuletzt bearbeitet:
Ich habe momentan leider einfach selber kaum Zeit zum Testen, da ich in Sachen Arbeit und Master ziemlich beschäftigt bin.

Sonst würde ich liebend gerne selber ausgiebige Performancetests machen. ;)
Dass die Kernel von PLX noch ihre Probleme haben, hat WarheadsSE ja von Anfang an gemeint. Wenigstens gibt's mit Debian/Emdebian nicht die gleichen Probleme wie es sie bei Arch gibt.
 
Zuletzt bearbeitet:
So, grade mal die geplante Pogo kurz angeschlossen und ein bissl getestet. Der 3.1.10er Kernel ist definitiv recht mies was die USB-Übertragungsraten angeht. ca. 16-18MB schreiben und ca. 22-25MB lesen sind nicht grade das Gelbe vom Ei.
Da muss ich mal schauen, ob ich am WE oder eventuell gleich morgen noch ein bissl die Kernel Config unter die Lupe nehme. Da passt was nicht!

Test war übrigens in meinem Fall mit einem A-DATA USB3.0 Stick. Der war also weniger das Limit.

Edit:
Erster Versuch mit 3.1.10er Kernel brachte keine Besserung. Mir ist aber vor allem aufgefallen, dass teilweise RIESEN Schwankungen in den Übertragungsraten sind. Hatte teilweise nur 9.x MB/s und beim nächsten Run dann wieder 18.x MB/s, ohne dass nebenher groß was lief.
Das ist sicher so nicht wirklich schön. Mal sehen wann ich Zeit hab mir das näher und vor allem in Ruhe anzuschauen.

Edit2:
Ich bau grade mal den Default WarheadsSE 3.1.10er Kernel, um zu sehen wie der sich so direkt verhält, ohne große Änderungen an der Config etc.

Edit3:
Letztes Update für heute. Der so gut wie Standard konfigurierte 3.1.10er WarheadsSE Kernel hat die gleichen, relativ schlechten USB-Übertragungsraten, wie meine Configs. "So gut wie", da ich ein Paar Dinge zusätzlich aktivieren musste, um überhaupt testen zu können. Sollte aber keinen Einfluss auf USB haben.
 
Zuletzt bearbeitet:
@celemine1Gig:
Wie hast Du die Crosskompilierung gelöst? Ich kompiliere für ARMv6 derzeit immer auf dem Gerät selbst und würde gern den schnelleren PC zum Crosskompilieren nutzen.
 
Die Pogoplug Kernel hab ich ganz "normal" als armel kompiliert. Also ohne die hardfloat Anpassungen für ARMv6.

Hab mir aber mal zum Raspberry Pi was durchgelesen, wo jemand eine passende Toolchain, genau für ARMv6, zur Verfügung stellt.
Für meine Verwendungszwecke hab ich auch kaum einen Vorteil in speziellen v6 Anpassungen gesehen. Aber interessant wär's allemal.
 
Ich meinte eher, mit welcher Toolchain man auf dem PC z.B. mit Ubuntu den Kernel für ARMv6 kompilieren kann.
 
Achso! :d

Da gibt's z.B. die Mentor (ehemals CodeSourcery) Toolchain, aber man bekommt über Ubuntu auch direkt die benötigten Compiler. Einfach nach "arm-linux-gnueabi-" suchen, dann findet man alles Nötige. ;)
 
Ich verwende die Linardo Toolchain (apt-get install gcc-arm-linux-gnueabi). ARMv5 Kernel kann ich damit problemlos kompilieren. Probleme gibt es jedoch mit dem ARMv6 Kernel.
 
Ich weiß. Ist ja leider ein Zwischending zwischen dem was aus dem normalen gnueabi Compiler für ARMv5 purzelt, und dem was der gnueabihf für ARMv7 produziert. Sind halt anscheinend eher Nischenprodukte, diese ARMv6.
 
Hab für morgen was zu testen. :d
Mir ist grade die Idee gekommen doch einfach die vorhandene ARMv6 Raspbian Distri (is ja nix anderes als Debian für Raspberry Pi ARMv6) für das Pogoplug auszuprobieren. Also auf USB sollte es ja gehen. Wenn man dann noch alle Pakete mittels Emdebian-Skripten verkleinern, also quasi "emdebianisieren", würde, dann ginge es auch im Nand. Wenn dann noch der Kernel für ARMv6 kompiliert würde, dann könnte sich eventuell auch die Leistung verbessern. Mal sehen ob ich die Zeit finde.
 
Zuletzt bearbeitet:
Zwei Punkte aus dem Blog Lötzimmer finde ich interessant:
1. OpenWRT
2. DNLA Renderer - mit einem DMController auf einem Android Gerät (z.B. DK UPnP™/DLNA® Player) als Fernbedienung könnte man den Pogoplug mit einer USB Sound Karte als Abspielgerät verwenden und idealer Weise neben Musik vom lokalen DMServer auch Internet Radio damit abspielen
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh