[Sammelthread] Der 20€ Server [Part 2]

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Für die Pogoplugs wird gerade an einem neuen uBoot und Kernel (<WarheadsSE> then kernel to 3.2/3.4 maybe) gearbeitet ;)
 
Hab hier einen schwarzen E02 und einen schwarzen PRO erhalten. Der Pro hat schon seine Vorteile -> SATA und WiFi ...

Hat einer ne Idee wie man vom DualCore denn überhaupt sinnvollen Gebrauch machen kann?! Wäre ja gut zu wissen wie man die Processing Power Sinvoll optimieren könnte beim PRO (Debian oder Arch)!
 
Lässt sich nicht ganz so pauschalisieren...

Ich hab jetzt mal bissl mit Webserver rumgespielt, da sieht man im htop schon, dass es was bringt.

NFS bringts schon minimal was....SMB/CIFS eher gar nicht. Multimedia-Sachen hab ich mir noch nicht angeschaut (upnp,...)

Das übertakten hat bei mir schon was gebracht, aber eher weniger durch die CPU, eher durch den schnelleren Bus...
 
Ich hatte ja mal die Idee beim Pro mit Mini-PCIe eine der Crystal-HD Karten von Broadcom zu testen. Damit könnte man das Teil eventuell tatsächlich als Mediaplayer benutzen. :d
Aus Mangel eines Pros hab ich mich aber ned weiter damit beschäftigt. Theoretisch sollte's aber gehen. XBMC sollte die Unterstützung haben. Müsste man halt auf Wlan verzichten, aber man hätte ja weiterhin Gigabit und könnte von ner SATA-Platte booten. SInd schon ganz nett die Dinger.
Ich kämpfe grade noch ein bissl mit Emdebian für den Flash. Das will noch ned so ganz wie ich will. :)
 
Wäre interessant...aber ein Raspberry kostet weniger und macht da einen guten Job...
 
habe heute mein pogoplug bekommen. geliefert wurde ein weißer pogoplug pro.

dazu habe ich drei fragen:

1. hat jemand schon den plug geöffnet? ich würde mir gerne mal die stromstecker-verbindung etwas anschauen, weil die kommt mir sehr schwach vor.
2. kann man das wlan irgendwie abstellen?
3. ist es möglich, normal aus windows heraus zu drucken - also ohne email zu schicken oder das file erst hochzuladen?
 
celemine1Gig schrieb:
Ich hatte ja mal die Idee beim Pro mit Mini-PCIe eine der Crystal-HD Karten von Broadcom zu testen. Damit könnte man das Teil eventuell tatsächlich als Mediaplayer benutzen. :d
Aus Mangel eines Pros hab ich mich aber ned weiter damit beschäftigt. Theoretisch sollte's aber gehen. XBMC sollte die Unterstützung haben. Müsste man halt auf Wlan verzichten, aber man hätte ja weiterhin Gigabit und könnte von ner SATA-Platte booten. SInd schon ganz nett die Dinger.
Ich kämpfe grade noch ein bissl mit Emdebian für den Flash. Das will noch ned so ganz wie ich will. :)
Zum Vergrößern anklicken....

Also Problem ist doch dann der Video Output der ja nicht vorhanden ist. Sonst könnte man doch die Crystal-HD Karte zum transcoden on the Fly benutzen. Also den Pro mit CrystalHD und ner HDD wo dann halt die Videos drauf sind und dann je nach bedarf des clients direkt transkodieren! Kann man sonst noch die Crystal HD Karte für irgendetwas anderes verwenden?


Aber so ne mini pci-e Grafikkarte wär ja eigentlich genial!
 
Zuletzt bearbeitet:
Ehrlichgesagt hab ich das gar nicht im Detail bedacht. ;) Sollte die Ausgabe per USB Grafikkarte nicht auch gehen? Die Beschleunigung mit der Crystal-HD, also sprich die Dekodierung, sollte ja von der Grafikausgabe relativ entkoppelt sein.
Vom Sinn (oder Unsinn) des Ganzen mal ganz abgesehen. :)
 
Zuletzt bearbeitet:
Wen Debian (bzw. Emdebian) auf der/dem Pogoplug V3 interessiert, für den hab ich hier ein kleines Projekt gestartet:
https://github.com/ingmar-k/Pogoplug_V3_Emdebian

Man installiert zuerst ArchLinux nach Anleitung dort (Pogoplug Pro/Video/v3 | Arch Linux ARM) und kann dann mit Hilfe meiner Skripte schnell und relativ einfach einen bootfähigen USB-Stick erstellen lassen, der ein Emdebian mit den gewünschten Paketen enthält. In Sachen NAND bin ich noch am Probieren, bzw. ich hatte noch keine Zeit das auszutesten. War mit den Skripten beschäftigt.
Muss noch ein Paar Kleinigkeiten einbauen, wie z.B. automatische Neuerstellung der SSH-Keys beim ersten Boot, aber ansonsten läuft's schon.

Edit: Wenn's dann noch klappt das Ganze automatisch in den NAND (komprimiertes UBIfs) schreiben zu lassen, wäre's TOP.
 
Zuletzt bearbeitet:
Langsam gefällt mir der Output meiner Skripte. Hab inzwischen auch nen eigenen Kernel gebaut, der mit RAMZSWAP (COMPCACHE/ZRAM) daherkommt. Das sollte bei Betrieb mit Rootfs im NAND sehr interessant sein.
Zu finden hier: http://www.hs-augsburg.de/~ingmar_k....31.14-pp_v3_nonpro-1.0-cc_1357213849.tar.bz2

Wenn ich das Emdebian im NAND laufen habe, schreibe ich eventuell noch kurz ne Anleitung. ;)

Edit: Link zum Kernel entfernt, weil noch was nicht passte. Bin grade auf Fehlersuche. Wenn ich's habe gibt's nen neuen Link.

Edit2: Link wieder eingefügt, weil dieser Kernel funktionieren sollte.
EDit3: Das war der Link für die Non-Pro Pogoplugs.
 
Zuletzt bearbeitet:
Sehr gut...bin gespannt. Ich werde demnächst erst mal Netzwerk Boot herum spielen...da rootfs per NFS mounten.
 
Eins kann ich schonmal sagen: Vergesst das Mounten des rootfs per nfs, oder anders gesagt nfsroot!
Durch die benötigte Firmware und das Treibermodul für Ethernet klappt das nicht. Zu dem Zeitpunkt, wo das Rootfs per Ethernet geladen werden sollten, ist schlichtweg noch kein Treiber geladen um genau das zu tun. Geht also nicht.
Eventuell könnte man das Ganze einkompilieren, hab aber keine Lust zu testen.
Und mit USB spinnt meine Testplug Classic seit kurzem auch total rum. Ergo, große ... . Ihr wisst schon was. :d

Ach und mein 2. Paket aus der späteren Bestellung war übrigens am Ende eine schwarz/weiße Pro Biz. :)

EDIT:
So, anders überlegt, und Kernel mit gmac und Firmware integriert gebaut. Geht wunderbar. TFTP/NFS-Boot here I come. :d
Wäre ja gelacht.
EDIT2: Kernel wieder entfernt, denn nach GPL darf ich das so nicht anbieten. :(
Kann aber jeder selbst "nachkompilieren".
 
Zuletzt bearbeitet:
Aus dem IRC ... Die Quellen hat er schon in seinem git repos...Stand der Dinge ist mir unbekannt...
 
Naja, nachdem sein Kernel 3.1 Versuch ja ncht so extrem erfolgreich war, wollen wir mal hoffen, dass es diesmal besser klappt. ;)
 
Da mir scheint das ihr ziemlich viel Ahnung von der Materie habt und (so wie ich beim Überfliegen den Eindruck hatte) selber schon so etwas in die Richtung laufen habt, fände ich es nett wenn ihr mir bei meiner Suche hier im Thread nach einem "Mini-Server" helfen könntet.
Wäre echt klasse :)
 
Zum Kernel für die Pogoplugs an dem Warehead arbeiten soll habe ich eine Frage:

"Beim Pogo E02 kann ich ja direkt über den mainline den kernel per upgrade ja einfach installieren lassen. Ich frage mich halt wo jetzt der Vorteil diesbezüglich bei einem "neuen" von Warehead kreierten Kernel sein sollte. Für die Oxnas geräte wäre es ja noch erklärbar..
Wäre ja auch genial wenn da irgendwie eventuell nutzbares hf integriert werden könnte... Bzw. vielleicht tut er dies ja auch?!

Oder hab ich da irgendwas falsch verstanden.?


Und bzgl des Mountens des rootfs über NFS wär ja zu diskutieren ob das so nicht irgendwie bzgl der Latenzen sehr zum Nachteil stehen könnte.
WÄre mal über einen Erfahrungsbericht sehr Dankbar.


@celemine1Gig

Könntest du evtl eine Anleitung zum kompilieren incl integrieren der Firmwares/treiber posten. Wäre dir sehr verbunden. Könnte sicher sehr viel daraus lernen.


Dank dir... :)


Nette Grüße.. Ich freue mich endlich mal auf meine freie Zeit in 2 Wochen. Dann wird endlich weitergebastelt an den Pogos,Dockstars,RPis und GoFlex' . ^^
Herrlich was man alles mit den Dingern machen kann.
 
lochman schrieb:
Zum Kernel für die Pogoplugs an dem Warehead arbeiten soll habe ich eine Frage:

"Beim Pogo E02 kann ich ja direkt über den mainline den kernel per upgrade ja einfach installieren lassen. Ich frage mich halt wo jetzt der Vorteil diesbezüglich bei einem "neuen" von Warehead kreierten Kernel sein sollte. Für die Oxnas geräte wäre es ja noch erklärbar..
Wäre ja auch genial wenn da irgendwie eventuell nutzbares hf integriert werden könnte... Bzw. vielleicht tut er dies ja auch?!

Oder hab ich da irgendwas falsch verstanden.?
Zum Vergrößern anklicken....
Wenn du mit "hf" "hardfloat" meinst, dann ist das fast nur vom Compiler abhängig. Im Kernel selbst kannst du sonst nämlich nur die "Floating point emulation", also sprich die Softwareemulation wählen. Man nutzt einfach einen passenden Compiler, wie den "arm-linux-gnueabihf-" aus den Ubuntu oder Emdebian Repos und schon kann man selbst hardfloat Kernel bauen, mit den entsprechenden CFLAGS..


lochman schrieb:
Und bzgl des Mountens des rootfs über NFS wär ja zu diskutieren ob das so nicht irgendwie bzgl der Latenzen sehr zum Nachteil stehen könnte.
WÄre mal über einen Erfahrungsbericht sehr Dankbar.


@celemine1Gig

Könntest du evtl eine Anleitung zum kompilieren incl integrieren der Firmwares/treiber posten. Wäre dir sehr verbunden. Könnte sicher sehr viel daraus lernen.


Dank dir... :)


Nette Grüße.. Ich freue mich endlich mal auf meine freie Zeit in 2 Wochen. Dann wird endlich weitergebastelt an den Pogos,Dockstars,RPis und GoFlex' . ^^
Herrlich was man alles mit den Dingern machen kann.
Zum Vergrößern anklicken....

Nun, Rootfs über Netzwerk ist selbstverständlich langsamer als ein lokales FS. Ich persönlich benutze das aber nur zu Entwicklungszwecken. So hab ich den Kernel (tftp) und das Rootfs (NFS) aufm Entwicklungsrechner und kann direkt dort was ändern, ohne ständig die Testdaten vom Entwicklungs- auf den Zielrechner kopieren zu müssen.
Zur Leistung selbst kann ich wenig sagen, weil mich diese auch nicht sonderlich interessiert. Mein Ziel ist ja ein System im NAND. Vielleicht kann dir das jemand anderes noch im Detail beantworten. Hat sicher auch andere Einsatzzwecke, wie z.B. ein über NFS "geteiltes" /home-Verzeichnis auf mehreren Rechnern oder vergleichbare Ideen.

Zur Frage OXNAS-Kernel mit NFS:
Nach GPL darf ich keine Kernel veröffentlichen, die eine binäre, nicht freie Firmware (z.B. gmac_copro_firmware) integriert haben. Für NFS geht's aber nur so, oder es ginge per Initramfs.

Anleitung zum Einkomilieren von Firmware-Daten in den Kernel:
Das gewünschte Treibermodul* fest in den Kernel integrieren (also KEIN <M>, sondern ein <*>). Dann wechseln in "Device Drivers"-->"Generic Driver Options" und dort den Punkt "External firmware blobs to build into the kernel binary" markieren und per Enter dessen Eingabefeld starten. Hier trägt man nun den Namen der Firmwaredatei ein*² .
Danach die Datei noch in den "firmware" Unterordner des Ordners kopieren, in dem man die Kernel Sourcen liegen hat, und schon kann's losgehen. Die Firmware wird fest ins Kernel-Binary eingebaut und muss somit nicht mehr nachgeladen werden.

*(bei Pogo V3 "Device Drivers"-->"Network Device Support"-->"Ethernet 1000 MBit"-->"Synopsys Gigabit MAC")
*²(bei Pogo V3 ist das gewöhnlich die "gmac_copro_firmware")
 
Zuletzt bearbeitet:
Port Multiplier ist da....fluppt...Raten sehen gut aus...hab grad mal 3 Testdisks dran...dd aus /dev/zero jeweils die üblichen ~40MB/s. Bei gleichzeitigem Zugriff (also 3 x dd) pendeln die drives sich bei je ~20 MB/s ein. Weitere Tests folgen...Werde mal ein Raid 5 draufwerfen ;)
 
@ morph027

Nutzt du den Multiplier an nem PogoPlug Pro oder an nem GoFlex Net?
 
Goflex Net...am PogoPlug kann und werde ich den aber auch mal testen. Meine aber, gelesen zu haben, dass der SATA-Code dort keinen Muliplier unterstützt. Raid5 baut sich gerade mit 3 Platten auf...wenn das durch ist, kann ich weitere Werte liefern ;)

[ähdit]
Der Recovery-Speed liegt laut /proc/mdstat bei ~20MB/s ... deckt sich ja mit den Werten für gleichzeitigen Zugriff (s.o.)
 
Zuletzt bearbeitet:
So....das Raid 5 ohne großa Magie (Chunk/Stride/Stripe/...Mathe *g*) schafft schreibend 30MB/s, lesend ~110MB/s (nach /dev/null ;) )

Initialisierung hat interessanterweise mit 3 Platten an dem Ding nicht geklappt...hab dann 2 angesteckt und eine direkt an die Goflex.
 
Bessere Werte als ich vermutet hätte. Sehr interessant! Für viele wäre jetzt wahrscheinlich noch interessant, ob das Hardware-Crypto Device des Marvell Kirkwood sauber funktionieren würde in dem Szenario und wie die Performance eines verschlüsselten Raids wäre. Mir persönlich zwar wurscht, aber hab das nun schon oft genug gelesen. :)
 
Nunja...da wirds dann auf jeden Fall interessant....werde mal rumspielen.

Zwar andere CPU, aber beim Pogo soll der Code funktionieren und das Zeug an die Crypto-Device offloaden. CPU macht dann nichts mehr, aber es is langsamer als von CPU.

[ähdit]

Hm.....crypto-dev läuft, aber das mv_cesa für luks ist seit 3er Kernel wohl kaputt...also nix da ;)
 
Zuletzt bearbeitet:
Hm...ok...nochmal getestet....mv_cesa läuft schon, aber genauso schnell wie ohne. Lediglich 4-5 MB/s. Geladen ist es, mach ich das ganze mit, frisst "mv_cesa" statt "kworker" die ganze CPU-Zeit..aber es sieht nicht so aus, als ob das die CPU wirklich entlastet...

Klar, für kritische Daten kein Ding, aber trotzdem doof ^^
 
Ich vermute ja mal, dass da bei der Implementierung in deinem aktuellen Kernel was nicht stimmt. Es gibt auch einige Kernel-Patches zu dem Thema. Aber egal. Brauchst ja ned deine ganze Zeit dafür verprassen.
Wenn ich Lust habe teste ich heute noch ein bisschen mit den Pogoplugs.
 
So...dem Pogoplug Pro hab ich jetzt mal die alte WebCam aus der Kramkiste verpasst, dort den IR-Sperrfilter entfernt, bei Reichelt einen einfachen IR-Scheinwerfer geholt, motion und mutt mit msmtp aufgesetzt und fertig ist die einfache Überwachungsstation ;)

Dem normalen Pogoplug hab ich ne alte abgelegte SSD via SATA am Start, die direkt vom USB mit Strom versorgt wird....fetzt ;)

Ich muss mal schauen, ob ich das mit dem pivot_root hinbekomme..dann bin ich beim Start nicht auf Netzwerk angewiesen (einfach von nem einfachen USB-Stick) und könnte dann, falls Verbindung besteht, das rootfs wechseln. Aber bis jetzt hängen immer noch irgendwelche Locks auf dem alten System, die das pivot_root nicht rübergeschubst bekommt...
 
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