Schlagwort-Archive: cpu

cubietruck

die ersten test mit dem cubieboard machen appetit auf mehr. 2 gb ram, dualcore-cpu, dual-gpu klingen nicht viel. okay, sd-card, netzwerkkabel und hdmi-kabel kommen oben drauf. doch zu weihnachten ist auf einmal dat cubietruck lieferbar.

ich muss mich schnell entscheiden, als ich die mail mit der verfügbarkeit erhalte, sind 2.5h später von 120 stk schon nur noch 76 da, ne 75. mist ich muss mich beeilen, also ritsch-ratsch … karte durch, ditt ding bestellt. durch die feiertage geht die bestellung diesmal nicht ganz so zackig, ist aber dann doch 4 tage später da. zumindest ist ein kühlkörper diesmal dabei, sowie ein 4 teilige plexiglas behausung, bei der sogar daran gedacht wurde, dass man eine 2.5″ hdd mit unterbringt.

cubietruck topview
cubietruck ( cubieboard 3 ) top view – power/nic/usb/vga

cubietruck sideview
cubietruck ( cubieboard 3 ) side view – led/sd/line/usb3

endlich gigabit ethernet, wlan, blutooth. fein, so dacht ich mir dass und die abmaße lassen mich hoffen, von den boards ein paar viele in den 19 zoll server zu bekommen, wie ich es gedacht hatte. mit s-ata anschluss geht die post ab, die sd-card ist nach-wie-vor kaum schneller als 10mbyte/s. aber moment, der treiber für den vermaledeiten realtek-chip ist kaum aufzustöbern. naja, versuch ich erstmal was da ist und saug also aufs neue ein paar images in verschiedenster konfiguration. aber der netzwerk-chip will nicht auf turbo schalten, mehr als 100 mbit/s gibts da derzeit nicht. fürs rz sicherlich ausreichend, doch die eisenbahnplatte war eigentlich für gigabit-ethernet gedacht.

muss ich wohl weitere images aus dem netz kramen. das video ruckelt auch hier, trotz zweier gpu´s läuft wohl alles in software ab und die cpu ist auf kante. das thema mit dem grafik-treiber ist damit leider noch nicht durch und wartet sehnsüchtig auf lösung….ebenso das wlan und dat blauzahn. die chipbezeichnungen sind kaum lesbar, so klein geschrieben, es gibt verschiedene revisionen, da sind nicht alle gleich.

cubietruck closeview
cubietruck ( cubieboard 3 ) close view – power/nic/sata/usb/hdmi connected

angenehmerweise hat das board einen 12v anschluss, nach kurzem test ist wohl aber kein wandler verbaut, der die 5v anschlussspannung hochschaltet. jedenfalls ist das ding mit 1.5 ampere noch gemütlich unterwegs, auch wenn in der spitze 2a angezeigt werden, sind das grad mal 10 watt aufnahmeleistung. im vergleich zu den circa 300 watt, die der dual-sockel-xeon-server aufnimmt, ist das doch recht bescheiden. wird sich jedoch noch zeigen, wie das mit der performance dann vergleichbar ist oder wie es korrelliert. ich denke jedoch, dass die leistung ausreichen wird, zumindest für die aktuelle phase der eisenbahnplatte.

serverAusschlachtung

doogie macht mir mut, die innereien vom dell-sever bei eGay reinzutun. ich brauch einiges an anlauf, da ich da kaum erfahrung und noch weniger nerv für habe, aber was solls. wenns denn geld einbringen sollte, ist es die paar stunden aufwand vielleicht wert.

also nehmen wir das ding gemeinsam auseinander, fotografieren es und schätzen grob, was wir als wunsch oder zielpreis uns vorstellen können. wir kommen auf sagenhafte 100 euro, die wir den teilen noch an wert zuschanzen, besser gesagt er. ich schätze nicht, dass für einen 8 oder 9 jahre alten bausatz noch jemand wirklich geld ausgeben will. sind doch alles füchse da bei den auktionen, die warten lieber ab und schießen es ein paar tage oder wochen später für n euro. was die dinger teilweise noch an geld im netz kosten und was sie mal gekostet haben, darf man garnicht so genau wissen – da wird einem nur üble.

perc scsi controller
perc scsi controller

also tippel ich ein wenig text in die artikelbeschreibung, lad die bilder hoch, die ich vorher noch ein wenig aufgehübscht habe und lass 10 tage zeit, für die rally. nichts passiert, kaum einer klickt auf die teile, beobachter finden sich kurz vor schluss, letztendlich gibts nur interessenten für die cpu und den raid-controller. jeweils für ein euro – hurra. tolle wurst.

cpu 64 bit
sockel 804 xeon

versprochen ist versprochen, ich pack die beiden dinger also ein, trödel ein bisschen mit dem versand und schick sie dann den neuen besitzern zu. glücklicherweise sind die anderen artikel, die automagisch verlängert wurden bzw neu eingestellt wurden, zu stornieren. noch so ein desaster fürn euro tu ich mir nicht an. schade, ists wohl nur noch elektronikschrott ….. zumindest kann ich die gehäuse und die netzteile gebrauchen, auch wenn 550 watt wohl mehr als genug sein dürften.

die anderen drei server brauch ich dann weder ausschlachten, noch die innereien verticken, die landen dann wohl direkt in der orangen tonne….

cubieboard

ich bin jetzt doch n bisschen fickrig geworden auf son kleines scheißboard. da ich ohne rootserver und ohne linux kaum an der eisenbahnplatte ( cloud ) weiter schrauben kann, begeb ich mich auf der suche im netz zu einem versand in de_DE.

entweder ich bin zu aufgeregt, zu unkondensiert oder warum auch immer, ich übersehe, dass die erste generation nur single-core ist, 1 gb ram hat und die netzwerkkarte nur 10/100 mbit/s schafft.  egal, für 50€ bin ich ja im budget des raspberry, aber mit doppelt so viel ram UND einem s-ata anschluss. das genügt mir als entschädigung. als ich das cubieboard in betrieb nehme.

cubie connected
cubieboard connected with sata hdd

auf der suche nach dokumentation, manuals, handbüchern – überhaupt irgendwelchen nützlichen informationen finde ich dann nach einigem suchen auch ein paar images, sie sich für sd-card eignen. ausserdem noch ein passendes „brenn-programm“ was die images da drauf tut. dabei fällt mir auch das ein oder andere image für den onboard-nand in die hände. ich saug erstmal was ich finde und probiere die verschiedenen ubuntu/debian/android versionen sukzessiv aus. einige booten garnicht, andere sind in zig versionen vorhanden – welche nehmen?

also bleibt mir wohl nichts übrig, als die verschiedenen konfigurationen zu checken. im wesentlichen schaue ich auf den treiber für die grafik einheit, also die gpu. dort ist eine mali-gpu verbaut, die direkt von arm stammt. das passenste triebwerk heißt „sunxi“ und ist direkt vom hersteller. die cpu, also der system-on-a-chip ( soc ) ist von allwinner und heißt a10. der schafft wohl 1080p, wie da im datenblatt steht – fragt sich nur mit wieviel frames pro sekunde :p

toll, warum hab ich die letzten monate bei den fights der x-server/clients nicht aufgepasst. mir, wayland, mesa, x11 … man was es da nun alles für zeug gibt. und wie zum henker wuppt man den treiber jetzt in den kernel :/ ich glaub, die frage krieg ich so schnell nicht beantwortet, daher krampf ich nicht weiter rum und mach mit config und install weiter.

einige versuche später bin ich noch nicht klüger, ich weiß zwar jetzt welche pakete so halbwegs laufen und wie man mit dem speicher haushaltet, frisch gebootet verbraucht das ding 80 mb mit xfce dann 180. ist der browser offen, sinds so um die 280 gb. tomcat läuft schon im hintergrund, oracles java ist auch drauf, nur die grafik ruckelt wie sau. von dem gigabyte ram sind 808 mb verfügbar, da bleibt noch ein bisschen luft für arbeitsdaten. jedoch noch kein open.gl, kein videostreaming, kein garnix in der richtung. die cpu auf vollanschlag kotzt, doch der treiber ist wohl noch immer nicht im kernel. muss ich mich jetzt wohl direkt mehr mit beschäftigen…..

cubie housed
cubieboard 1 in plexiglas behausung

tolle wurst, auf der einen seite lockt das ding mit kapazitäten, die eigentlich als settop-box ausreichen sollten und mir das video auf den fernseher streamt, auf der anderen seite könnte ich mir ein mini-nas bauen, da die sata-schnittstelle sowie drei usb anschlüsse platz für erweiterung lassen. aber ohne anständigen grafik-treiber, wirds wohl erstmal nix mit dem streaming-client. nuja, als load-balancer sollte der dampf wohl ausreichen, um die 100 mbit/s zu sätigen. übliche einstiegs-firewall-systeme haben auch nicht mehr und dsl oder vdsl ist derzeit auch nicht wesentlich schneller.

rackServer

durch einen bekannten bekomme ich zugriff auf vier 19 zoll server von dell ( meine lieblingsmarke :/ ) mit 1 HE, die wohl nicht nur durch die zweite abschreibung durch sind, sondern einfach zu viel strom fressen, als dass ein weiterbetrieb noch sinnvoll oder wirtschaftlich tragbar erscheint.

rack server
dell power edge 1850

also fahr ich da hin, shredder die ultra-scsi platten ein zwei mal mit dem raid tool und kann die vier büchsen mit nach haus nehmen. okay, nicht ganz geschenkt, aber beinahe 😉 …. zu hause angekommen, schmeiß ich so ein ding mal an, der düsenjetähnliche sound kommt mir ja bekannt vor, ist aber in einer wohnung noch sehr viel unschöner, als in einem büro. so what, soll ja eh ins rechenzentrum fürn schmalen thaler.

ich wollte die dinger ja ausschlachten und mit neuen innereien direkt im rack betreiben. spassenshalber messe ich mal die aufnahmeleistung, die im leerlauf bereits 180w mit einer xeon-cpu ( p4/prescott ähnlich ) verbrät. da brauch ich garnicht erst messen, was das ding frißt, wenn ich den zweiten sockel auch bestücke, cpus gibts genügend. ich hader ein wenig, ob ich nicht mangels cashflow einfach die kleinste konfiguration von den möglichen ins rz stelle. doch nachdem ich den taschenrechner angeworfen habe, sind die stromkosten ( ca. 50cent/kwh ) auf ein jahr hochgerechnet, zum schlecht werden viel. zu viel für die eisenbahnplatte.

ich lass das mal sacken, eilt ja nicht – denke ich mir so.

dell power edge 1850
19 zoll rack server

bigData

nun bin ich also doch beim thema „big-data“ gelandetund eher wie die jungfrau zum kinde zu diesem thema gelangt. daher ein paar gedanken zur einleitung in dieses thema.

bisher hatte ich mich mit erp-systemen ( enterprise resource planning aka sap&co. ) beschäftigt. dann gings um reporting-systeme ( abrechnungen, abschätzungen, berichte ) und darüber bin ich nun in der ecke gelandet, die aktiv wird, wenn die datenbank nicht mehr weiter kommt oder sogar dicke backen macht.

im wesentlichen geht es darum, eine große aufgabe so zu dimensionieren und zu portionieren, dass viele kleine maschinen damit zurecht kommen und in der summe dann mehr dampf haben, als eine dicke maschine.  statt die daten jedoch normalisiert ( möglichst ohne duplikate ) wie eine datenbank zu halten, wird bei big-data  jede tabelle im csv/tsv ( comma / tab separated value ) format als flatfile vorgehalten. die daten sind de-normalisiert, weil aufgrund der heutigen plattenkapazitäten, die schrumpfung auf das letzte byte aufgegeben ist und jeder eintrag ( eine zeile ) durchaus mega- oder gigabyte betragen kann.

die daten sind in einem verteilten dateisystem ( hadoop distributed file system / hdfs ) über mehrere rechner redundant verteilt und werden in einer „salami-taktik“ durchgerechnet und wieder zusammengeführt. so kann es passieren, dass ein quell-tabelle in einem full-cross-join ( alle mit allen vergleichen ) auf 300 oder 400 gigabyte swap-file explodiert. normalerweise ist diese menge mit den üblichen sytemen ( fibrechannel oder iscsi ) kaum zu bewältigen, da das nadelöhr / flaschenhals ( bottleneck )  der zugang zum speichersystem ist. in einem cluster mit 10 nodes macht das nur noch 40 gb swap pro node, bei 20 nodes nur noch 20 gb, die ausgelagert werden müssen. die so nutzbaren skaleneffekte sind ein hauptargument dieses verfahren.

die üppigen datenmengen, die so miteinander verglichen werden können, übersteigen die üblichen verfahren des business-intelligence ( bi ) oder data-mining ( dm ) bei weitem, da korrelationen durch model- und testgetriebene entwicklung ausprobiert und das jeweils sinnvollste modell anwendung finden kann. durch verschiedene konfigurationen des systems können die aufgaben optimal auf verarbeitet werden, da bestimmte jobs mal mehr ram, mal mehr cpu oder mal mehr festplatte benötigen. der flaschenhals läßt sich nach identifizierung weiten, in dem auch weitere maschinen in den cluster genommen werden können, um das gewünschte ergebnis zu produzieren.

so wird die möglichkeit geschaffen, völlig neue ansätze oder alte verworfene, durch try&error automatisiert die verschiedenen szenarien durchzuspielen, die bisher aus technischen oder wirtschaftlichen gründen ausser reichweite waren. die verknüpfung verschiedenster datenquellen kann somit über das bestehende datenmodell hinaus erfolgen, ohne dass die ein klassisches datenmodell verändert werden muss. durch transformationsprozesse werden genau die daten zur berechnung herangezogen, die dafür notwendig und sinnvoll sind.

das gängige werkzeug am markt nennt sich hadoop und wurde von yahoo in eigenregie entwickelt und ist seit 2007 ein teil der open-source-community. verschiedene dienstleister bündeln einige dieser frameworks und bibliotheken und sind mit ihren distributionen auch im kommerziellen sektor vertreten. die großen marken der it sind inzwischen auch vertreten und haben die kombination von relationalen und in-memory-datenbanken auch im großen stil im portfolio.

die ursprüngliche idee, legacy-hardware ( standard server / pizza boxen ) zu benutzen, um aufgaben zu lösen, für die vorher sechs- oder siebenstellige beträge notwendig waren, ist damit aber nicht vorbei. im gegenteil, die nutzung diverser resourcen im verbund ist immer noch zentrales argument. da die bisher verwendete hardware jedoch nicht für solch riesige datenmengen gedacht war, haben hersteller oder firmen wie facebook eine open-compute-initiative geschaffen, die server mit 24 und mehr festplatten in einem gehäuse möglich machen. da diese kategorie jedoch nicht mehr in die üblichen racks passte, wurde dort auch ein neuer standard geschaffen, der statt 19 zoll nun 21 zoll anwendung, die verschiedene verbesserungen mit sich bringen.

der ausgangspunkt für die sammlung solche riesiger datenmengen war im internet gegeben. durch suchmaschinen wurden immens viele seiten und damit daten zur bearbeitung, sichtung, indexierung, bewertung und zur verfügungstellung neu geschaffen. in sozialen netzwerken gab es themen und beiträge, die vorher kaum oder nur wenig miteinander verknüpft wurden.

selbst für große cluster gibt es auch heute noch aufgaben, die durch datenmodellierung von graphen erst erfassbar wurde ( kaufempfehlung als klassisches beispiel: leute die schuhe gekauft haben, kauften auch socken ). die verschiedenen mega- und metaebenen lassen sich mittels dieser technologie verknüpfen und ins verhältnis stellen, einhergehend mit diesem thema kam auch der begriff „nosql“ auf, da keine sequenziellen abfragen mehr gestellt wurden, sondern pipeline- oder baumartige abläufe die irgendwie miteinander verkettet waren.

ergebnis solcher analysen sind dann am ende ganz herkömmliche tabellen, wie man sie aus der tabellenkalkulation kennt, jedoch ist der unterschied, dass diese ein paar hundert millionen oder milliarden einträge lang sein können.

zusammengefasst: information overload industries