Schlagwort-Archive: hardware

kurzweil.-.zweiter.akt

after 4 weeks of drying the boards on my heating, i tryed to arrange a date with doogie, who helped on the phase one. not knowing, how the pitch-wheel and the floppy was connected, the synth was just closer to be doomed. but, after 6 weeks or 7 we arranged a double day, to slowly rebuild the kurzweil from its parts.

first test run
kurzweil loose connected

reassembling … how to start without a manual on that level. so … isolating the parts from the case and other connected parts, was in the focus here. the power supply was also not to trust, but with a headphone, we went sure, that no noise nor sine waves came from that part, beside the expected voltage.  it looked good for the moment, power was there, no cable was missing, the defect buttons were easy to change … so lets try it.

second test run
kurzweil loose connected

nope, nothing to see on the display, not lights on, no sound nor growling from a short cut were to hear, so we ripped all parts of the case and connected each cable to a part, that was numbered or signed in somehow. but … fail. some 2-3-4 ends of cables were without a mark. hm, …. we tried to start the engine, but one of the ribbon cables starts smoking, a sure sign of a short cut, that was not the right port for that cable.  we stoped and looked on each board, not seeing the difference, we have had to made. so we started again, and the cable went hot instantly – again.

kurzweil inside
upside down inside the kurzweil

the engineers on kurzweil showed us, where the fork is hanging around. pumping current over a tiny, 0.14 mm² of cable, couldnt be more worse. they used big cables for big wattages, but why did they did that different, on the engine board then? we looked closer after some minutes, or was it hours of cluesless talkings. we suprisingly found 2 connectors without a cable, so we switched something between the sampler, i think the scanner and the engineaudio analog or digitized, anyhow, could be the case. we stoped breathing when we switched on the power plug again … and … the display starts working. but, as i estimated on old-fashioned-hardware, each part of the system needs to be connected the way it should, so we couldnt check part by part, we had to stuff all together, with the hope, its allright then.

k2500 boards
k2500 display and scanner board

the five knobs or buttons on the input board, which were dead as distances holder, they were quickly replaced by some from the a-z/+-# keyboard. five pieces, let one cost 50 cent, made that accident happen, that we started to enjoy then later. the system came up, the boot-cycle went successfully done and the thing came to life. but having everything upside down, not knowing what buttons to push, we tried some intuitive haptics by accident, but after everyone of us three tried it, some preset with playable pattern suprised us thru the headphones and speakers with sound. the rest was routine to not mixup the three packs of screws and as we nearly closed the parts of the case, the kdfx board went back to my mind.

i had spare parts to drop in, with more power, more harmonic distortions and bigger rooms to simulate. but first, i wanted to get warm a bit with that tier, to check, if its worth the switch from software-based production to this kind of hardware. i would notice, it is it worth, but fiddling the menue was not funny, so the vast.programmer needs to be setup … next or the very next weekend … some day. that reopening, droping in, updating the firmware with a floppy drive, then stimulating to live once again will need a long way to get warm with that idea. one nice part is, that after that years, the software is still online on kurzweils server, that is a big plus in that whole story.

crunching on arm

as far as it looks like, iam not the only one, crunching on arm. dzone got a article from thailand, where some guys connected 22 cubieboards, runinning apache spark, for in-memory-computation.

but ive seen the bottleneck of a 100 mbits network connector on cubieboard pretty much earlier. so ive decided to buy the cubietruck, which includes a 1 gbits adapter, which brings theoretically 128 mbyte/s a sata drive for saturation.

a cluster from france was presented before on cubieboard.org with the same idea, to fit as many cubieboards within a standard rack server enclosure, as possible.

i calculated 8 cubieboards in a 1 he server rack as maximum amount of boards and hard discs last year. the price is then something like 1600-2000 € for the hardware. for that price tag, the memory of 16 gb ram and 16 tb of hdd is not that much, but the theroretical bandwith between the nodes ( within the cluster ) is something like 8 gbits 🙂

8 nodes
8 boards in a 1 he standard rack server

the picture above shows the former choosed boards from hardkernel, called odroid, but the price for that board is above the budget, so i sized it down to a dual-core, from the quad-core.

eisenBahnPlatte

„was ist eigentlich eine holzeisenbahn?“

das projekt der private cloud den menschen zu vermitteln und dann noch zu erklären, dass man damit seine freizeit gestaltet, ist mir über die jahre nicht einfacher gefallen.

der begriff „eisenbahnplatte“ trifft vermutlich noch am ehesten dass, was otto normal bereits von anderen kennt, wenn es um viel arbeit, geld und liebe geht, das in ein projekt fließt, welches vermutlich nie wirtschaftlichen bedingungen unterworfen ist. man könnte es auch luxus nennen oder wie es allgemein genannt wird: hobby.

da ich mich nicht nur auf arbyte, sondern auch am wochenende oder nach feierabend mit den themen hier beschäftige, sah ich diesen begriff noch am dichtesten an dem, was eh schwer zu beschreiben ist. da dazu jede menge programmierung gehört, die erst gut läuft, wenn die konfiguration ein mindestmaß erreicht hat, ist die komplexität in zusammenhang mit der hardware und den modulen, die extern verwendet werden immens. ich hab garnicht präzise vor augen, wie viele schichten / layer nun tatsächlich involviert sind, manche sind absichtlich eingezogen, um module zu entkoppeln, andere lassen sich vielleicht auch reduzieren und einsparen.

da mir in den verschiedenen phasen schon beinahe der kopf geplatzt ist, hab ich teilweise oder an bestimmten punkten, die arbeit ruhen lassen und dinge aufgemalt, beschrieben oder sonstwie umrißen oder skizziert, damit nicht nur ich die dinge verstehe, sondern eben auch andere.

daher ist die eisenbahnplatte all das, wozu ich nach dem 3. oder 5. mal keine lust oder kraft hab, es zu schildern oder zu erklärbärn. daher auch der blog hier, um einsicht zu schaffen und ansichten zu vermitteln, die aussenstehenden oder interessierten die möglichkeit gibt, dinge zu erfahren, die sonst nur schwer oder schwierig zu erfassen oder gar zu finden sind.

die eisenbahnplatte fuhr schonmal“ mit drei nodes, doch sind mittlerweile alle server vom netz und derzeit wird neue hardware getestet und konfiguriert, damit der wirtschaftliche aspekt nicht zu kurz kommt.

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