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...
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!
Mir kommen SSD (Solid State Disks) in den Sinn. Die sind zwar schweineteuer, aber rasend schnell im Vergleich zu herkömmlichen Festplatten.
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.
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.
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
Man könnte natürlich auch einfach mehrere "PCs" nehmen, das wäre natürlich zu einfach...
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. :-)
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
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?
@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...
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.
@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)
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.
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.
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.
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.
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.
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
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.
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.
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=3649&tgid=3673&tgid=1029&tn=HARDWARE&l1=Festplatten&l2=Solid+State+Drives&;
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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'.
>Das klingt wieder nach so einer 'spontanen Idee'.
Den Eindruck habe ich auch ...
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.
Chris schrieb: > Was anderes macht keinen Sinn. Weshalb kein RAID5? Bei der Datenrate schreibend reicht das locker.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
oszi40 schrieb: > Beim Rebuild kann alles entschieden langsamer werden (je nach > Systemauslastung)! ja aber die oben berechneten 2Myte/s schafft man auch da noch.
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.
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.
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?
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.
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
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.
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?
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.
>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.
60Mib/s vs 0,3MiB/s da stimmen die Prioritäten nicht. Für Hobby ganz nett, aber ansonsten nicht zu gebrauchen.
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)
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?
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.
"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...
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
1 | 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
1 | 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)
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.