mikrocontroller.net

Forum: PC Hard- und Software pc bauen fuer riesige datenmengen


Autor: Can Cobe (moklok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

moechte gerne einen pc bauen.

viele viele daten pakete kommen auf mehreren leitungen rein...

daten pakete unterlaufen kleinerer berechnungen (vernachlaessigbar)...

daten sollen auf festplatte...


ich moechte so viele daten so schnell wie moeglich auf die festplatte 
bringen.  und moechte dann auch diese daten im nachhinein bearbeiten und 
anzeigen... sprich die daten wieder abholen und zurueckschreiben...


jetzt ist das natuerlich wegen der festplatte ziemlich langsam... wollte 
fragen was man da machen kann, wenn man maximal 2000 euro fuer so einen 
rechner hinlegen moechte.  was gibt es fuer optionen wenn man bis zu 
50000 euro fuer so einen rechner hinlegen wollte?


frage ist ein wenig allgemein gehalten... wuerd mich aber ueber ideen 
und gedankengaenge freuen...

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:
> ich moechte so viele daten so schnell wie moeglich auf die festplatte
> bringen.  und moechte dann auch diese daten im nachhinein bearbeiten und
> anzeigen... sprich die daten wieder abholen und zurueckschreiben..

Zahlen!

Autor: Sebastian Hepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir kommen SSD (Solid State Disks) in den Sinn. Die sind zwar 
schweineteuer, aber rasend schnell im Vergleich zu herkömmlichen 
Festplatten.

Autor: Silvia A. (silvia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:

> frage ist ein wenig allgemein gehalten...

Kann man wohl sagen. Was dem Einen riesige Datenmengen und gewaltige 
Datenraten sind, das ist dem Anderen Kleckerkram und tröpfelnde Bits.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian Hepp schrieb:

> Mir kommen SSD (Solid State Disks) in den Sinn. Die sind zwar
> schweineteuer, aber rasend schnell im Vergleich zu herkömmlichen
> Festplatten.

Beim Schreiben nur bedingt. SSDs sind da perfekt in Webseiten-Tests, 
weil der Test maximal ein paar Tage dauert. Allein - die Dinger werden 
mit der Zeit langsamer. Klassische Disks nicht.

Autor: Can Cobe (moklok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

danke schonmal fuer die zahlreichen antworten...


um eine hausnummer zu geben was die datenmenge angeht:

es geht darum, dass ich mehrere sensoren an den pc schliessen moechte... 
das geht bei 10 sensoren los, die jeweils einen datenwert von 5*64bit 
abgeben. das alle 50ms.

jetzt soll das aber erweiterbar sein. sprich ich moechte nach und nach 
bei 100, 200 ...2000 sensoren enden. und das soll bis zu 3monate so 
durchlaufen.

jetzt ist mir klar, dass das so ziemlich ueberall aus den naehten 
platzt.


wollte deshalb von vornerein mein system einschraenken.  frage ist wie?

also nicht so viele sensoren, nicht so lange aufnahmedauer oder nicht so 
hohe abtastung...

deshalb wollte ich mal ausloten, was denn ueberhaupt moeglich ist, wenn 
man fuer einen rechner 2000 euro hinlegt (also einen teueren heimpc) 
oder 50000 euro (also einen speziellen industriepc mit bestimmten 
techniken, die ich noch nicht kenne)

danke

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man könnte natürlich auch einfach mehrere "PCs" nehmen, das wäre 
natürlich zu einfach...

Autor: qwerty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie willst du die Daten verarbeiten?

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:
> es geht darum, dass ich mehrere sensoren an den pc schliessen moechte...
> das geht bei 10 sensoren los, die jeweils einen datenwert von 5*64bit
> abgeben. das alle 50ms.

Also ein Sensor bringt eine Datenrate von 5  64bit  20 /s = 800 byte/s

Also weder die Datenrate noch die Datenmenge sind für einen PC ein 
Problem.
Das Einzige, über das du dir Gedanken machen musst ist die Verbindung 
Sensor -> PC.
:-)

Autor: Tishima (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Hast Du mal die benötigten datenraten durchgerechnet und den benötigten 
Speicherplatz.

Wenn ich mich nicht verechnet habe ist das garnicht so wild.

Bin bei 2000 Sensoren auf 1,6MB/s und insgesamt 16GB Daten gekommen.

Da kannste locker auf einen USB Stick speichern.

gruß,
Bjoern

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nackte Datenrate: 40 x 20 x 2000 = 1,6MB/sec + Overhead. Fliegenschiss.

Datenmenge: 1,6MB/s x 3 Monate = 17TB. Normales RAID-5 SATA Rack, wenns 
am Stück online sein muss. Sonst: Alles was soviel Daten fasst und keine 
Floppy-Disk ist.

Interessanter wird die Frage, die Daten von den 2000 Quellen 
einzusammeln. Hast du eine Vorstellung davon wie du die anbinden willst?

Autor: Can Cobe (moklok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@läubi

ich wollte gerne erstmal ausloten, was mit einem pc moeglich ist...

also erstmal, was ist mit der richtigen hardware moeglich->kein/geringer 
zusaetzlicher softwareaufwand.

und dann zu den mehr pc loesungen uebergehen->viel zusaetzlicher 
softwareaufwand...

@rest
einen moment bitte... so viele antworten, die ich noch nicht gelesen 
habe...

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:
> ich wollte gerne erstmal ausloten, was mit einem pc moeglich ist...

Der wird bei 1.6Mbyte/sec Däumchen drehen
Wie geben deine Sensoren die Daten aus? Ich rate mal 1-Wire.
Als PC wird jede Mediamarktgurke mit genug externen Festplatten oder so 
ausreichen.

Autor: Can Cobe (moklok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@qwerty

daten werden einfach graphisch als kurve dargestellt.  nur kleine 
berechnungen +*-/. aber werden mal daten aus dem vorderen teil der 
messung mit teilen ganz hinten verrechnet.  oder nur jede zweite wert 
mit jedem dritten wert eines anderen sensors.... muss also die ganze 
festplatte rauf und runter rennen, um mir die richtigen werte zu 
suchen... (bitte keine datenbank diskussion ausloesen;)


@rest

die aufnahme bereitet mir hier nicht die sorge... (ausser der teil mit 
sensor->PC , soll noch ein weiteres thema sein).  mir bereitet die 
bearbeitung der daten sorgen, wenn ich dazu die 16GB hoch und runter 
rennen muss.

wenn dabei also nicht alles in den RAM passen sollte.  24GB RAM ist hier 
glaube ich die grenze bei "gewohnlichen" heimpcs.  geht da mehr? oder 
gibt es doch eine annehmbare loesung von der festplatte aus, so dass ich 
nach oben hin mehr luft habe?

moechte halt gerne, dass ich nicht ewig auf die gezeichneten linien 
warten muss (so gefuehlt unter einer minute)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:

> bearbeitung der daten sorgen, wenn ich dazu die 16GB hoch und runter
> rennen muss.

Nullen vorne sind unwichtig. Nullen hinten nicht.
1,6MB/s sind 140GB/Tag. RAM kannste knicken bei 3 Monaten.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dafür müsste man mehr über die Daten wissen und auch über die 
berechnungen? Ich glaueb nicht das du immer mehre GB an daten verrechnen 
willst. Mann muss sie halt so ablegen das man sinnvoll daruf zugreifen 
kann. Und wenn du am ende eh durchschnittswerde haben willst, kann man 
zustäzlich schon mal den durschnitt von 1 Stunde, 1min oder 1Tag 
ablegen.

Es werden heute rießige Datenmenge (mehre TB) z.b. für Rainbow-Tabels 
abgelegt und für den Zugriff ist drozdem schnell auch ohne 24GB Ram. Man 
muss sich halt vorher ein paar gedanken machen was man mit den Daten 
anstellen will.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:
> moechte halt gerne, dass ich nicht ewig auf die gezeichneten linien
> warten muss (so gefuehlt unter einer minute)

Du musst doch nie alles lesen. Es genügt Den darzustellenden Bereich zu 
lesen. Auch Wenn dieser ein Tag groß ist, musst du ja nicht jeden 
Datensatz lesen, dein Bildschirm ist ja nur ein paar tausend px breit.

Autor: Can Cobe (moklok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uppa... danke

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
4-fach sata raid Karte, = 90€ +8x 70€ 2T Festplatten (50.4W) = 650€ für
16T Raid. Einfach 2X in einen Rechner, dann hast du ein 32T Raid mit 16T
Nutzlast. Sprich für ca 2400€ kannst du dir einen Rechner 
zusammenstellen,
welcher 32T Raid hat und deinen Bedürfnissen entspricht. Wenn du mit der
Graphickarte aufpasst, dann kannst du so ein System in einem Tower 
einbauen,
mit einem Netzteil inkl spare Platten.

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:
> mir bereitet die
> bearbeitung der daten sorgen, wenn ich dazu die 16GB hoch und runter
> rennen muss.

Das ist dem PC sowas von egal. Aktuelle Spiele sind auch gerne mal 
größer (ob besser lass ich mal unkommentiert), da wird beim Ladevorgang 
auch gerattert ohne Ende.

Notfalls könnte man sich noch so sachen wie Hashing oder Komprimierung 
überlegen, um möglichst sinnvoll zu arbeiten.

Aber für alle Überlegungen in der Richtung braucht man mehr 
Informationen über die gewünschten Rechenoperationen.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:

> wenn dabei also nicht alles in den RAM passen sollte.  24GB RAM ist hier
> glaube ich die grenze bei "gewohnlichen" heimpcs.  geht da mehr? oder
> gibt es doch eine annehmbare loesung von der festplatte aus, so dass ich
> nach oben hin mehr luft habe?

Viele Serverboards können mehr, brauchen aber registered/buffered DIMMs. 
128GB sind kein großes technisches Problem und mit Standardteilen 
erreichbar.

fchk

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gefühlsmäßig würde ich reichlich RAM zum Zwischenspeichern nutzen und 
evtl. ein paar flinke HDs mit 15000 U/min suchen. Daten tagelang im RAM 
speichern würde ich auf jeden Fall vermeiden, da schon ein kurzer 
Stromausfall die ganzen Messwerte vernichten würde!

Problem ist wahrscheinlich die Zeitscheibe beim Einsammeln der Daten in 
den PC. Wenn da vorher schon dezentral etwas sinnvoll gesiebt würde, 
könnte man jede Menge Aufwand sparen.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> ein paar flinke HDs mit 15000 U/min suchen

kommmt sehr auf die Zugriffe an, diese Festplatten haben zwar eine recht 
kleine Zugriffszeit (aber imme noch viel langsamner als SSD) aber die 
Transferrate ist nicht so toll.Wenn man also linear durch die Datenmenge 
lesen will machen diese Festplatten keinen sinn. Sie machen nur bei 
Datenbanken sinn, weil dort mit Idizierten Daten gearbeitet wird, der 
Index liegt im Ram und dann müsen möglichst schnell die Daten dazu 
gelesen werden.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Datentenanfall vorher auf ein erträgliches Maß zu reduzieren oder 
auf mehrere Geräte zu verteilen? Damit reduziert sich gleichzeitig das 
Verlustrisiko. Allerdings ist die GENAUE!!! zeitliche Synchronsation 
aller beteiligten Rechner nötig, um die Daten hinterher sinnvoll 
verwenden zu können!

Ob SSDs großer Kapazität schon der Stein des Weisen sind, wage ich heute 
noch zu bezweifen, da in der ct bei einigen Messungen nur die 4-fache 
Geschwindigkeit erreicht wurde (über alles gemessen). Wenn ich dann den 
Preis sehe ... z.B. 
http://www.alternate.de/html/highlights.html?hgid=...

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> nur die 4-fache
> Geschwindigkeit erreicht wurde (über alles gemessen)
Was für eine Geschwindigkeit? Die Transferrate oder die Zugriffszeit? 
Die Zugriffszeit ändert sich von 8ms auf 0.2ms  - das ist mehr als sich 
in den letzen 10Jahren bei den Festplatten getan hat.
Heute hat man die Wahl wenn man wenige Daten mit verteilten Zugriffen 
hat dann SSD, wenn man viele Daten speichern will dann HDD.

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal
http://www.mrtg.org/rrdtool/

an.

Autor: new (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich sollte jeder aktuelle PC mit den Daten zurechtkommen, sogar 
ein ATOM. 1,6MB/s ist ja nicht viel. Festplatten schaffen min. 60MB/s im 
Raid mehr. Kommt jetzt drauf an, was du alles mit den Daten machen 
willst, dann könnte ein größerer Prozessor nicht schlecht sein.

Die Datenmengen sind dank 2TB Festplatten auch nicht mehr das Problem. 
Bei dem Controller sollte man aber drauf achten, dass er mit >2TB klar 
kommt.
Ein Raid (extra Controller) würde ich auf jeden Fall einsetzten, gerade 
aus Sicht der Ausfallsicherheit.

Ich sehe das Problem auch eher im Bereich der Datenübertragung zum PC, 
hier musst du ein vernünftiges Protokoll schreiben.

Die Idee mit Speichern von Mittelwerten während der Messung könnte wenn 
richtig umgesetzt die Anzeigegeschwindigkeit deutlich erhöhen.

Autor: Gunther L. (what)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:

> daten werden einfach graphisch als kurve dargestellt.  nur kleine
> berechnungen +*-/. aber werden mal daten aus dem vorderen teil der
> messung mit teilen ganz hinten verrechnet.  oder nur jede zweite wert
> mit jedem dritten wert eines anderen sensors.... muss also die ganze
> festplatte rauf und runter rennen, um mir die richtigen werte zu
> suchen... (bitte keine datenbank diskussion ausloesen;)

Auch wenn dir die Diskussion über Datenbank überhaupt nicht gefällt, 
aber ich finde es geschwindigkeitstechnisch schon entscheidend, wie Du 
auf die Daten und dementsprechend Datenbank zugreifen möchtest.

Ich tippe, daß zwei (oder drei oder später 200 000) billige kleine 
Rechner, auf denen z.B. MongoDB, CouchDB oder irgendeine andere 
Datenbank, welche geclustert und auf welche via Map/Reduce zugegriffen 
wird, schneller ist, als eine mit Raid, SSDs und RAM hochgezüchtete 
Maschine. Google machts übrigens auch nicht anders...

Wenn mehr Maschinen da sind, können auch die Sensoren auf mehrere 
Maschinen aufgeteilt werden.

Gruß,
Gunther

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gunther L. schrieb:
> Ich tippe, daß zwei (oder drei oder später 200 000) billige kleine
> Rechner, auf denen z.B. MongoDB, CouchDB oder irgendeine andere
> Datenbank, welche geclustert und auf welche via Map/Reduce zugegriffen
> wird, schneller ist, als eine mit Raid, SSDs und RAM hochgezüchtete
> Maschine. Google machts übrigens auch nicht anders...

Je nach Anwendung/Algorithmen kann das schneller sein, kann aber auch 
deutlich langsamer sein, da zum einen weitere Layer hinzufügt werden 
(Anwendung -> (OS->Netzwerk->OS->) DB -> OS -> HD statt Anwendung -> OS 
-> HD), zum anderen noch die Latenzen bzw. der geringe Durchsatz (außer 
man nimmt 10GbE) hinzu kommen.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Je nach Anwendung/Algorithmen kann das schneller sein, kann aber auch
> deutlich langsamer sein, da zum einen weitere Layer hinzufügt werden

Mit der Glaskugel würde ich behaupten, daß der Durchsatz wenn er auf 
mehrere Schultern parallel verteilt wird, besser sein könnte UND mehrere 
Caches einen flinkeren Zugriff ermöglichen könnTen. Leider ist die Sache 
nicht ganz so einfach. Sonst würden DB-Gurus nicht 3 Wochen Lehrgang 
brauchen.

Autor: Jens G. (jensig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Datenbanken haben aber auch so ihren Overhead, der gerade bei 
Minizugriffen, wie eben die Inserts der vielen Einzelwerte pro Sekunde, 
schwer zuschlagen kann. Die Daten von 2000 Sensoren alle 20ms (also 
100000 Inserts) sind schon nicht wenig für eine DB. Mit 
Zwischenbufferung im Programm läßt sich das aber teilweise entschärfen 
(also mehrere Werte gebündelt in einem Insert).
Wenn es aber dann um das Auslesen und Verrechnen vieler Einzelwerte, die 
irgendwo zufällig herumliegen, geht, macht sich eine DB ganz gut, denn 
man kann eigentlich ganz gut auch komplexere Zugrffe in Form von SQL 
formulieren, und die DB weis eigentlich am besten, wie sie das am 
effektivsten macht.

Ansonsten sind die 1,6MB/s kein Problem - heutige normale SATA-Platten 
machen inzwischen über 100MB/s, wenn die nicht zufällige Spurwechsel 
machen müssen.
Und wie schon oben angedeutet: während der Meßwertaufnahme kann man die 
Werte ja schon vorberechnen, so daß dann spätere Analysen bereits 
vorberechnete Werte benutzen kann.

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist halt die Frage was mit den Daten im Anschluss passieren soll. Was 
ändert sich denn alle 50ms was man über Monate mit 2000 Sensoren 
erfasst?
Ethernet kannst du für die Anbindung der Sensoren vergessen, es muss 
mindestens FastEthernet sein. Ansonsten muss Irgendwas die Daten von 
mehreren Sensoren abfangen und dann gebündelt schicken.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Condi schrieb:
> Ethernet kannst du für die Anbindung der Sensoren vergessen

nein, wenn jeder Sensor mit 10Mbit an einem Gigabit switch hängt von wo 
aus es dann zum PC geht ist das kein Problem.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht denn nun deine Lösung aus ?

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry aber mir drängt sich da wieder der Gedanke auf, daß der TE sich 
nicht ganz bewusst ist welche Datenmengen er erzeugen und später 
'irgendwie' verarbeiten will. Was willer damit tun? 2000 Sensoren und 20 
 3600  24 * 90 Messwerte pro Sensor über 90Tage????
Beim Überfliegen des Threads habe ich dann gelesen daß er die Daten 
eigentlich nur als Kurve anzeigen will?
Ich denke der TE sollte etwas dazu sagen was das für Daten sind und wie 
die weiter benutzt werden. Vieleicht endet das wie schon öfter damit, 
daß man dem TE eine Lösung aufzeigen kann in der 50 statt 2000 Sensoren 
genügen und man die Messwerte auf ein 1/10 bis 1/1000 pro Sensor 
reduzieren kann.

Es kann ja nicht der Ernst sein sich 160 TByte anschauen zu wollen, 
rechnet mal wie lange ihr damit zu Gange seid, wenn ihr pro Diagramm bis 
z.B. 4000 Messwerte anzeigt und jedes Diagramm 10s anschaut.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Condi schrieb:
>> Ethernet kannst du für die Anbindung der Sensoren vergessen
>
> nein, wenn jeder Sensor mit 10Mbit an einem Gigabit switch hängt von wo
> aus es dann zum PC geht ist das kein Problem.

Naja, man bräuchte dann einen Switch mit mindestens 2001 Ports, außerdem 
wären das bei 2000 Sensoren und 50 ms Abtastperiode 40.000 Pakete pro 
Sekunde, die ganz ordentlich Last im IP-Stack produzieren dürften.
Bei solchen Mengen an Einzelwerten ist das eigentlich einzig sinnvolle, 
diese erstmal extern zu möglichst großen Paketen zusammenzufassen und 
dann diese an den PC zu übergeben. Mit vielen winzigen Einzelpaketen 
kann man nämlich auch bei an sich lächerlichen netto-Datenraten jeden PC 
recht schnell an die Lastgrenze treiben.

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Peter schrieb:
>> Condi schrieb:
>>> Ethernet kannst du für die Anbindung der Sensoren vergessen
>>
>> nein, wenn jeder Sensor mit 10Mbit an einem Gigabit switch hängt von wo
>> aus es dann zum PC geht ist das kein Problem.
>
> Naja, man bräuchte dann einen Switch mit mindestens 2001 Ports, außerdem
> wären das bei 2000 Sensoren und 50 ms Abtastperiode 40.000 Pakete pro
> Sekunde, die ganz ordentlich Last im IP-Stack produzieren dürften.
> Bei solchen Mengen an Einzelwerten ist das eigentlich einzig sinnvolle,
> diese erstmal extern zu möglichst großen Paketen zusammenzufassen und
> dann diese an den PC zu übergeben. Mit vielen winzigen Einzelpaketen
> kann man nämlich auch bei an sich lächerlichen netto-Datenraten jeden PC
> recht schnell an die Lastgrenze treiben.

Jepp, man müsste dafür sorgen, daß nicht pro Einzelwert ein komplettes 
Paket gesendet wird, sonst hast du eine Nettodatenauslastung im 
Prozentbereich. Dann nützt dir dein schönstes Gigabyte-Netzwerk nix. 
Aber das ist eine Frage der Sender, die müssten entsprechend eine Anzahl 
an Sensordaten akkumulieren.
Egal, ich denke soweit hat sich der TE noch gar keine Gedanken gemacht. 
Das klingt wieder nach so einer 'spontanen Idee'.

Autor: Jens G. (jensig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das klingt wieder nach so einer 'spontanen Idee'.

Den Eindruck habe ich auch ...

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für 2000 Sensoren sind es nichtmal 14Tb, also bei Raid1(+0) sind es 32Tb
Speicherplatz, welche benötigt werden. Was anderes macht keinen Sinn.
Sind dann 16 Platten auf 2 Kontrollern.
Ein Pc schafft 200.000 Pakete/Sek ohne Paketverlust bei 64byte Paketen.
Das sind dann gerade 20% der PC-Leistung die da dann für 40000 Pakete 
aufgebracht werden müssen. Das war jetzt angenommene UDP Verbindungen,
bei TCP ist der Datenverlust garantiert.
Wenn man aber von 3€ je Ethernetanschluss ausgeht, dann macht das schon
6k aus, die Sensoren dürften auch 20€ kosten, also wird da sicherlich
mindestens 50k hinblättern müssen für das Projekt und warscheinlich
reicht das nicht.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:

> Was anderes macht keinen Sinn.

Weshalb kein RAID5? Bei der Datenrate schreibend reicht das locker.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich gehe sogar davon aus das sich die daten garantiert auf ein Bruchteil 
der größe zusammenpacken lassen. Denn die Sensoren werden wo fast immer 
die gleichen werte abliefern.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Raid 5 ist für lesen optimiert, nicht für das schreiben, da geht die 
Datenrate dann in den Keller. Das eigentliche Problem ist aber, wenn 
eine
Platte ausfällt. Normalerweise geht das Raid dann Offline oder read-only 
modus mit tracelog und macht mal ein rebuild, sollte eine spare 
vorhanden sein. Die günstigeren Raid Kontroller aber sind dann offline 
und dann geht gar nichts. Bei Raid 1 wird problemlos weitergeschrieben 
und bei besseren
Kontrollern kann auch gleichzeitig ein Rebuild gemacht werden.
Die I/O Kapazität darf in diesem Falle aber nicht von einer 
Datenauswertung
schon reserviert sein, denn sonst passiert auch hier eine Datenverlust.
Und den UPS nicht vergessen, oder eienn Batteriebuffer für den Raid.
Stromausfall nähmlich ist für HW-Raid sehr sehr problematisch.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, das kommt darauf an.Bei 3000 Geschäftsfilialen, wo mittels OPENCV 
der Besucherflow analysiert wurde (Videoüberwachung) und deren realtime 
Bewegung
mittels ADSL an die Zentrale gesant wurde, auch da wurde eine 3 Monate 
Aufzeichnung gemacht. Solche Daten kann man nicht komprimieren und 
Heutzutage
sind ein paar Tb bezahlbar. Wenn es aber nur Temperatursensoren oder 
sowas
ist, dann gebe ich dir recht.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Raid 5 ist für lesen optimiert, nicht für das schreiben, da geht die
> Datenrate dann in den Keller.
für die Paar Daten reicht es allemal

> Das eigentliche Problem ist aber, wenn
> eine Platte ausfällt
> Normalerweise geht das Raid dann Offline oder read-only
> modus mit tracelog und macht mal ein rebuild, sollte eine spare
> vorhanden sein.
also bei ICP, Adaptec und 3Ware ist es nicht der Fall. Das würde ich dem 
sinn wiedersprechen das das system verfügbar bleibt.

> Die günstigeren Raid Kontroller aber sind dann offline
> und dann geht gar nichts.
Selbst das billigste SoftwareRaid geht nicht offline, ich kenne kein 
System was offline geht wenn eine Festplatte ausfällt.
Wenn ein 2.Festplatte ausfällt dann wird das system ReadOnly geschaltet 
was aber nur für extrem Datenrettung sinnvoll ist

> Und den UPS nicht vergessen, oder eienn Batteriebuffer für den Raid.
> Stromausfall nähmlich ist für HW-Raid sehr sehr problematisch.
jedes Raidsystem sollte man mit USV betreiben egal ob Raid1 oder Raid5

Aber hier geht es um große Datenmengen und eine recht geringen Datenrate 
dafür ist Raid5 genau das richtige.

Autor: Gunther L. (what)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß sowieso nicht, was der ganze Aufwand soll.

Wenn der Supercomputer dann mal auswertet, rechnet und rechnet und 
rechnet... Was nützt es dir dann, wenn du weißt, dass das Ergebnis 42 
ist?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:

> Raid 5 ist für lesen optimiert, nicht für das schreiben, da geht die
> Datenrate dann in den Keller.

Zur Erinnerung: Hier geht es im eine Rohdatenrate von 1,6MB/s.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn bei Raid5 eine zweite Platte ausfällt, dann sind die Daten 
unwiderruflich verloren. Bei Adaptec, wenn eine Platte ausfällt, und die
wird ersetzt, dann wird ein Rebuild gemacht, und solange der nicht 
fertig ist, steht das System. Dasselbe gilt bei einer spare Platte. 
Teilweise kann Adaptec nichtmal ein Raid5 System von 2 Platten lesen. 
Ich bezieh mich da auf
die teuren 5x controller. Wenn du aber von Raid6 oder Raid10 sprichst, 
ja
dann ist es was anderes. Raid6, da musst du bei einem Plattenausfall 
Glück haben, damit das Stripe nicht auf der defekten Platte ist.
Bei Raid5 brauchst du aber für 14Tb 50Tb an Festplatten, bei Raid(0)1 
sind es 32Tb und bei Raid10 (was nicht Raid0+Raid1 ist) sind es 100Tb, 
wie auch bei Raid6.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Bei Adaptec, wenn eine Platte ausfällt, und die
> wird ersetzt, dann wird ein Rebuild gemacht, und solange der nicht
> fertig ist, steht das System. Dasselbe gilt bei einer spare Platte.
dann macht du etwas falsch, unsere controller konnten das (das war vor 
5Jahren noch mit SCSI). Klar ist beim Rebuild das System langsamer aber 
ist verfügbar.

> Teilweise kann Adaptec nichtmal ein Raid5 System von 2 Platten lesen.
> Ich bezieh mich da auf
> die teuren 5x controller.
also bei unsere Systemen mit 8 Festplatten und Raid5 konnten von alles 
Festplatten gleichtig lesen. Aus dem Grund steigt ja auch die Datenrate 
wenn mehr festplatten im System sind.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Wenn bei Raid5 eine zweite Platte ausfällt, dann sind die Daten
> unwiderruflich verloren.

es gibt ja nur nur Totalausfall, ein Raidcontroller schmeist die 
Festplatte auch bei einem Defekten Sektor raus. (Was besonders ärgerlich 
ist, wenn es bei der 2.Festplatte eines Raid5 passiert). Und für diesen 
zweck gibt/gab es bei ICP eine möglichkeit das System als readonly zu 
nutzen und man konnte auf alle Daten zugreifen die nicht auf dem 
defekten sektor lagen.

Wenn eine Festplatte komplett ausfällt, dann ist klar das man da nicht 
mehr viel lesen kann.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:

> Wenn bei Raid5 eine zweite Platte ausfällt, dann sind die Daten
> unwiderruflich verloren.

Ja, aber die Forderung nach kaum noch steigerungsfähiger Verfügbarkeit 
wurde hier m.W. nicht erhoben.

> Bei Adaptec, wenn eine Platte ausfällt, und die
> wird ersetzt, dann wird ein Rebuild gemacht, und solange der nicht
> fertig ist, steht das System.

Die mir bekannten Systeme besitzen dafür entsprechende Prioritäten, 
wodurch auch bei laufendem Rebuild problemlos mit dem System gearbeitet 
werden kann. Wenn das mit diesem Adaptec nicht möglich ist, dann gehört 
der für professionellen Einsatz trotz des Namens in die Mülltonne, oder 
läuft unter "Spielzeug für Homeanwender".

Jedenfalls habe ich mit Aufällen von RAID-Adaptern (und RAID-Systemen 
aller Grössenordnungen) durchaus auch meine Erfahrungen und man spürt 
deutlich einen Unterschied, kann aber damit arbeiten.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist nur so bei Raid5, auch bei professionellen systemen.
Raid5 hat Vor und Nachteile, aber kein Profi würde Raid5 für sowas 
verwenden.
Raid5 heisst automatisch 3,5,9 Platten, ansosnten geht die Performance 
in den
Keller und bei Raid5 hat man einen Geschwindigkeitsnachteil gegenüber 
einer
einzelnen Platte, das Lesen ist merklich langsamer.

Ja, das stand nicht in den Anforderungen.
Ich bin davon ausgegangen, daß wenn 200.000 Datensätze je Sekunde für 3 
Monate aufgezeichnet werden müssten, diese normalerweise bei 
nichtaufzeichnung verlorengehen und das ganze Experiment für die Tonne 
ist
sollte so ein Fall eintreten.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:

> Raid5 hat Vor und Nachteile, aber kein Profi würde Raid5 für sowas
> verwenden.

Wenn du implizit die von ihm bisher nicht genannte Anforderung einbaust, 
dass höchste Verfügbarkeit gewährleistet werden muss, dann gebe ich dir 
Recht.

Allerdings würde ich dann statt dessen einen zweiten PC verwenden, der 
die gleichen Daten parallel protokolliert. Nicht nur Platten können 
verrecken.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Raid5 hat Vor und Nachteile, aber kein Profi würde Raid5 für sowas
> verwenden.

also ich mache das Beruflich sehe mich dadurch schon als Profi und würde 
es machen - weil es das beste Preis-Leistungsverhältnis für diese 
Anforderung ist. Was hilft es wenn du 10 fach gespiegelte Platten hast 
aber keine reduntantes Netwerk und Netzteil?

> ... und bei Raid5 hat man einen Geschwindigkeitsnachteil gegenüber
> einer einzelnen Platte, das Lesen ist merklich langsamer.
also die 300Mbyte/s sekunde reichen uns - ich glaube nicht das da eine 
Festplatte schneller ist

Das schreiben ist bei Raid5 langsamer aber doch nicht das lesen.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> also die 300Mbyte/s sekunde reichen uns - ich glaube nicht das da eine
> Festplatte schneller ist

Beim Rebuild kann alles entschieden langsamer werden (je nach 
Systemauslastung)! Besonders schlecht ist: wenn sich große Files während 
des Rebuilds laufend ändern, die rebuildet werden sollen. Dann versucht 
er x mal die aktuelle Version auf die anderen Platten zu schreiben, wird 
aber dabei immer wieder gestört. Dann brauchen 73GB 3 Tage.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> Beim Rebuild kann alles entschieden langsamer werden (je nach
> Systemauslastung)!

ja aber die oben berechneten 2Myte/s schafft man auch da noch.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Raid5 wird aus Stripes gelesen, welche mittels Xor zusammengefügt 
werden,
und langsamer als eine einzelne Platte wird es, da es von allen Platten 
gelesen werden muß, und dann zusammengefügt wird. Bei einem HW Raid
hat man auch einen großen HW Cache welcher die Schreibsachen auch 
buffert.
Wenn man allerdings eine einzelne Platte an das Raid hängt und als Raid0 
konfiguriert, dann merkt man den Geschwindigkeitsunterschied zum Raid5.
Ansonsten trügt der HW-Cach (Ram) eine größere Geschwindigkeit vor.

Raid01 hat in diesem Falle den Vorteil, daß es beim Lesen mehr als 
doppelt so
schnell ist als Raid5 und man dafür die langsamen und günstigen 2Tb 
5400rpm Platten nehmen kann bei gleicher Performance und erheblich 
weniger Kosten.
Ansonsten findet man selten Festplatten mit weniger als 10.000rpm in 
einem
guten Raid. Außnahme bildet der Raid zum Zwecke der Archivierung der 
Daten.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grössere zusammenhängende Blöcke zu schreiben ist bei RAID5 mit oder 
Spare mit oder ohne Rebuild vom Prinzip her gleich. Gebremst wird dabei 
nur, weil die Platten besser beschäftigt sind als sonst und evtl. je 
nach Konfiguration ein Teil der Zeit für Rebuild reserviert wird. Es ist 
das Lesen, was deutlich langsamer wird. Worum es in der Fragestellung 
aber zunächst nicht geht.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Bei Raid5 wird aus Stripes gelesen, welche mittels Xor zusammengefügt
> werden.

und da ist der Denkfehler!

Wenn ich von 8 Festplatten jeweil 512byte lesen und sie nach Raid5 Xor 
verrechne dann habe ich noch 7 x 512 byte übrig. Damit steigt die 
Leseleistung je zusätliche Festplatte (solange die CPU es schafft)

Die Zugriffszeit ist gleich (bzw. die der lagsamsten platte) aber ich 
habe noch dem Zugriff die 7fache Datenmenge.

> Raid01 hat in diesem Falle den Vorteil, daß es beim Lesen mehr als
> doppelt so
> schnell ist als Raid5 und man dafür die langsamen und günstigen 2Tb
> 5400rpm Platten nehmen kann bei gleicher Performance und erheblich
> weniger Kosten.

Wenn ich 10TB mit 2TB Festplatten bauen will, dann brauche ich bei Raid1 
20 Festplatten, bei Raid5 6 Festplatten. Dabei ist das Raid5 auch noch 
schneller weil er von 6 Festplatten gleichzeitig lesen kann und und das 
Raid1 nur von 2 Festplatten.

Wo ist jetzt noch mal der Vorteil von deinem Raid1?

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
das mit dem

> Bei Raid5 wird aus Stripes gelesen, welche mittels Xor zusammengefügt
> werden.

ist natürlich richtig, aber das ist keine erklärung warum es langsamer 
sein soll.

Die Frage ist aber warum ein Kontroller die Daten überhaupt mit Xor 
zusammenfügen sollte, wenn das raid normal arbeitet dann braucht er 
überhaupt nichts zu rechnen beim lesen, er kann die Prüfsumme einfach 
ignorieren.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
>
> Wenn ich 10TB mit 2TB Festplatten bauen will, dann brauche ich bei Raid1
> 20 Festplatten, bei Raid5 6 Festplatten. Dabei ist das Raid5 auch noch
> schneller weil er von 6 Festplatten gleichzeitig lesen kann und und das
> Raid1 nur von 2 Festplatten.
>
> Wo ist jetzt noch mal der Vorteil von deinem Raid1?

Battle Against Any RAID F...
http://www.miracleas.com/BAARF/BAARF2.html

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Battle Against Any RAID F...
> http://www.miracleas.com/BAARF/BAARF2.html

ein Link ohne Kommentar ist recht wenig wert, soll ich mir jetzt alle 
Dokumente durchlesen und dann hoffen das ich erkenne auf was du 
hindeutest?

Zumindest bei überfliegen konnte ich rauslesen das ein Raid5 beim 
schreiben langsamer und beim lesen recht schnell ist. Und dabei auch 
recht recht kostengünstig. Und das ist doch für den zweck gut so. Die 
daten kommen recht langsam rein und sollen schnell analysiert werden.

Autor: frage (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum wird hier seit zig Seiten über RAID(s?) diskutiert wo es um 
1,6MB/s geht (das ist ja nicht mal die Datenrate die ein unkomprimiertes 
Video erreicht) und der TO sich seit dem 19. nicht mehr gemeldet hat?

Autor: Sebastian F. (milchknilch0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Condi schrieb:
>> Ethernet kannst du für die Anbindung der Sensoren vergessen
>
> nein, wenn jeder Sensor mit 10Mbit an einem Gigabit switch hängt von wo
> aus es dann zum PC geht ist das kein Problem.

Doch ist es, du wirst jede Menge Drops bekommen, außer du hast Switche 
mit richtig Dampf. Ich dachte da eher an sowas wie 10Base2 oder 10Base5. 
Da bekommt man recht günstig ein paar Sensoren dran.
Bei 10/100/1000 BaseT dürfte der Preis der Verkabelung wesentlich höher 
sein als die des Rechners.

@Oszi40
Wenn dein Raid mit 74Gb 3 Tage zum rebuilden brauch, dann würde ich mir 
mal Gedanken machen. Selbst mein alter Promise Controller schafft in der 
Stunde 300GB und liefert nebenbei noch 30MB/s Random R/W und der hat 
keinen Cache. Da stirbt ja schon die nächste Platte bevor die Spare 
eingearbeitet ist.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>3 Tage zum rebuilden
Eine leere HD braucht maximal 20 Minuten am gleichen, arbeitslosen 
Rechner. Bei dem gestressten Rechner ändern sich jedoch die Daten 
schneller als der Rebuild stattfinden kann.

Autor: Sebastian F. (milchknilch0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
60Mib/s vs 0,3MiB/s da stimmen die Prioritäten nicht. Für Hobby ganz 
nett, aber ansonsten nicht zu gebrauchen.

Autor: Can Cobe (moklok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin noch da...

wow ich dachte der thread waere schon gestorben...

ist ja ganz schoen was los hier ;)


um vielleicht ein paar fragen zu beantworten...

ja, es ist eine spontane idee.  dabei ging es mir aber auch darum mein 
intresse und wissen zu erweitern, was denn alles moeglich ist... deshalb 
auch ganz am anfang schon gesagt: "deshalb wollte ich mal ausloten, was 
denn ueberhaupt moeglich ist"

deshalb danke nochmal fuer die rege beteiligung...


also was ich rausgehoert habe, sind mehrere raid vorschlaege. aber wie 
ich jetzt verstanden habe ist das speichern wohl nicht so das problem. 
hatte aber schon bei weniger daten das problem, die daten anzeigen zu 
lassen.  sprich zoomen, links rechts scrollen.  das ist zieeeemlich 
hackig, wegen der festplattenrennerei (vordere werte muessen mit 
hinteren verrechnet werden).  die analyse ist rechnerisch nicht komplex 
(+*-/).  kann insbesondere fuers scrollen/zoomen nicht alle ergebnisse 
im RAM puffern.  reichen da schon die raid vorschlaege oder kann man das 
vollkommen knicken?


weiterhin habe ich jetzt verstanden, dass das einlesen der sensorwerte 
ein viel groesseres problem darstellt.  wenn ich jetzt mehrere 
mikrokontroller/PCs verwende, die mir die daten zu grossen paketen 
schnuere, wie kann man die dann am besten zeitlich synchronisieren?? 
(diese frage stelle ich mal in einem neuen thread, weil der hier schon 
so lang ist)

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:
> kann insbesondere fuers scrollen/zoomen nicht alle ergebnisse
> im RAM puffern.

Du musst doch nur so viele Werte lesen, wie dein Bildschirm Pixel hat, 
wo ist das Problem?

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leg doch einfach in ein paar weiteren MiB diverse Zoomstufen ab. 
Mittelwert über 1/5/15/60/300 Minuten und 12h/24h. DA muss man nichts 
neu berechnen und die Anzeige geht sehr flott.

Autor: Can Cobe (moklok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Du musst doch nur so viele Werte lesen, wie dein Bildschirm Pixel hat,
wo ist das Problem?"

was ist denn wenn ich aufsummierte werte darstellen moechte.

also verlauf einer aufsummierung ueber ersten monat.

und verlauf einer aufsummierung ueber dritten monat.

da muss ich doch viel mehr werte auslesen als mein bildschirm pixel hat.


"Leg doch einfach in ein paar weiteren MiB diverse Zoomstufen ab.
Mittelwert über 1/5/15/60/300 Minuten und 12h/24h. DA muss man nichts
neu berechnen und die Anzeige geht sehr flott."

geht das auch fuer die "summenanalyse"?? hmm... wie lange wird das wohl 
dauern diese zoomstufen zu erstellen...

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Can Cobe schrieb:
> "Du musst doch nur so viele Werte lesen, wie dein Bildschirm Pixel hat,
> wo ist das Problem?"
>
> was ist denn wenn ich aufsummierte werte darstellen moechte.
>
> also verlauf einer aufsummierung ueber ersten monat.
>
> und verlauf einer aufsummierung ueber dritten monat.
>
> da muss ich doch viel mehr werte auslesen als mein bildschirm pixel hat.
>
>
> "Leg doch einfach in ein paar weiteren MiB diverse Zoomstufen ab.
> Mittelwert über 1/5/15/60/300 Minuten und 12h/24h. DA muss man nichts
> neu berechnen und die Anzeige geht sehr flott."
>
> geht das auch fuer die "summenanalyse"?? hmm... wie lange wird das wohl
> dauern diese zoomstufen zu erstellen...

Die Berechnung fällt nicht ins Gewicht, da der Durchsatz hauptsächlich 
von den Festplatten/Netzwerk/etc. begrenzt wird.
Kurz gerechnet
5 * 8 Bytes * 20/s = 800 Bytes/s ~ 69 MB pro Tag ~ 6 GB für 90 Tage pro Sensor.
 Passt also in den Hauptspeicher, kann aber auch direkt beim Einlesen 
berechnet werden.
Wenn die Daten mit 100 MB/s von den Festplatten kommen braucht das
6 GB / 100 MB/s = 60 s pro Sensor.
 Für die gesamten 14 TB wären das 140000 s ~ 1.6 Tage.
(zum Vergleich: aktuelle GPUs schaffen bis zu 1.5 TFlops (bei 32-Bit FP 
6 TFlops), ein Core-i7 bis zu 100 GFlops)

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem liegt an dem Allgemeinen. Klar klingt es viel 2000 Sensoren 
und alle 50ms usw. aber wenn du dann nur ein paar popelige Grafiken mit 
malen willst, brauch man das alles nicht. Da werden entsprechende 
Fenster festgelegt und dann die Daten entsprechend abgelegt. So spart 
man sich den ganzen Kram und kommt mit ein paar MB aus. Des geschieht 
live nebenbei.
Wenn man viel raus holen will, muss man optimieren.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.