Hallo, brauche ein paar Vorschläge für nichtflüchtige Speicheranbindung (Größe ~32GB) an einem Virtex 5 FPGA. Zum Projekthintergrund: Wir haben in der Vergangenheit ein Projekt realisiert, wo wir den Virtex 5 mit DDR2 Ram und Compact Flash realisiert hatten. Im Projekt ging es hauptsächlich darum, dass schnell ankommende Daten (~40-50MB/s) im Ram zwischengespeichert und auf Befehl zur Compact Flash rüberkopiert wurden. Der Ram ist ja schnell genug, der Compact Flash wurde damals mit Common Memory Mode angesteuert und erreichte eine Geschwindigkeit bis max. 20MB/s. Nun wollen wir in einem neuen Projekt mit ähnlich schnell ankommenden Daten den Ram am besten weglassen, stattdessen den nichtflüchtigen Speicher (z.B. CF) schneller machen, um die Daten direkt dort abspeichern zu können. Soweit ich sehe können ja die CF Karten bis zu 100MB/s im UDMA Mode, was ich noch versuchen will zu realisieren (evtl. Tipps oder Links wären super!!!). Doch was für Alternativen gäbe es? SD-Karten? Wo ja auch Werbung zum Teil mit Angaben von 90MB/s gemacht wird. Die Recherche im Forum bestätigt dies aber nicht! Zum einen brauchen wir einen Temperaturbereich von -40 bis +85°C, zum anderen werden die Speicher unter Strahlung laufen müssen, alles in einer Lebensdauer von mind. 5 Jahren. SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme, da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten in den nichtflüchtigen Speicher ablegen werden soll. Danke schonmal im voraus für Vorschläge Yafes
Ohne mich jetzt mit dem FPGA-Thema sonderlich gut auszukennen: Wenn ein Datenstrom schnell und zuverlässig (!) gespeichert werden muss, werdet ihr mit einem Speicher mit internem Controller Schwierigkeiten haben. Grund: Es ist nie klar, wie lange der Controller benötigt, um die Daten zu schreiben, und welchen Durchsatz er zuverlässig dauerhaft erreicht. Alles was also Speicherkarte, EMMC oder SSD ist, eher schwierig, bzw. wird ein großer Pufferspeicher und Reserven bei der Schreibgeschwindigkeit Pflicht. Ich würde mich bei parallelem NAND-Flash umsehen.
Yafes61 schrieb: > SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme, > da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten > in den nichtflüchtigen Speicher ablegen werden soll. Wenn ihr mit einer SSD nicht zurecht kommen könnt wird es dünn... SD und Co haben wie erwähnt Recht lange maximale Latenzen von mehreren hundert Millisekunden. Auch eine dauerhafte Rate von 50 mib/s ist höchst selten bis unwahrscheinlich. Selbst bei einer SSD nicht selbstverständlich. Gegen bzw. Für die Lebensdauer hilft Größe. Oder wie ist der Einwand gemeint?
FlashGordon schrieb: > Ohne mich jetzt mit dem FPGA-Thema sonderlich gut auszukennen: > > Wenn ein Datenstrom schnell und zuverlässig (!) gespeichert werden muss, > werdet ihr mit einem Speicher mit internem Controller Schwierigkeiten > haben. Grund: Es ist nie klar, wie lange der Controller benötigt, um die > Daten zu schreiben, und welchen Durchsatz er zuverlässig dauerhaft > erreicht. > > Alles was also Speicherkarte, EMMC oder SSD ist, eher schwierig, bzw. > wird ein großer Pufferspeicher und Reserven bei der > Schreibgeschwindigkeit Pflicht. > > Ich würde mich bei parallelem NAND-Flash umsehen. Als Zwischenpuffer kann evtl. der DDR2 Ram dienen, was bisher ja der Fall war, heißt aber ich kann ihn dann halt nicht weglassen. NAND-Flash sind aber interessant, schaue mir grad ein Datenblatt von einem Micron NAND-Flash an. Karl schrieb: > Yafes61 schrieb: >> SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme, >> da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten >> in den nichtflüchtigen Speicher ablegen werden soll. > > Wenn ihr mit einer SSD nicht zurecht kommen könnt wird es dünn... > > SD und Co haben wie erwähnt Recht lange maximale Latenzen von mehreren > hundert Millisekunden. Auch eine dauerhafte Rate von 50 mib/s ist höchst > selten bis unwahrscheinlich. Selbst bei einer SSD nicht > selbstverständlich. Gegen bzw. Für die Lebensdauer hilft Größe. Oder wie > ist der Einwand gemeint? Das mit der Lebensdauer ist folgendermaßen grob kalkuliert: Wir gehen von max. ca. 15 Schreibzyklen pro Zelle pro Tag aus. Je nachdem was für Daten ankommen kann es ja sein das zufällig eine Zelle am Tag 15 mal hin und her wechselt. So hätten wir 15 Schreibzyklen pro Zelle x 365 Tage = 5475 Schreibzyklen x 5 Jahre = 27375 Schreibzyklen (Worst Case!) Nur die SSDs mit SLC bieten ja 100.000 Schreibzyklen, die würden gehen. Aber ich brauche einen Zwsichenspeicher wie DDR2 Ram.
Yafes61 schrieb: > Je nachdem was für Daten ankommen kann es ja sein das zufällig eine > Zelle am Tag 15 mal hin und her wechselt. Du hast die Speicherverwaltung und das Wearleveling der Karten ausser Betracht gelassen: auch wenn du in einer Datei ständig nur 1 und das selbe Byte änderst, änderst du bei gutem Waerleveling jedesmal eine andere Speicherzelle. Und dann kann es sein, dass du eine Speicherkarte länger nicht mehr unter Strom hattest. In diese Fall wird die Karte in den ersten paar Minutan ziemlich langsam sein, weil sie intern erst mal alles umsotieren wird, damit die Speicherplätze im Flsh durchrotieren und der Inhalt aufgefrischt wird. Auf jeden Fall ist ein Medium mit Flash-Speicher niemals deterministisch. Du kannst also nie sicher sein, dass irgendetwas nach einer bestimmten (kurzen) Zeit abgeschlossen ist.
:
Bearbeitet durch Moderator
Danke erstmal für die Anregungen. Gibt es evtl. einen Link oder ein Design im Netz zur UDMA Ansteuerung von CF-Karten? Habe im letzten Design hier ca. 20MB/s geschafft, im Common Mode wie schon gesagt. Ich würde den gerne schneller hinbekommen. Mein DDR Ram wird in dem Falle als Zwischenspeicher dienen. Des weiteren schaue ich mir grad diesen NAND-Flash an: file:///C:/Users/CKalayci/Downloads/M73A_32Gb_64Gb_128Gb_256Gb_AsyncSync _NAND.pdf Dazu habe ich ein Example Design gefunden, mit ähnlichem NAND-Speicher: https://www.microsemi.com/document-portal/doc_view/129988-ac328-nand-flash-interface-design-example-app-note An sich sieht das ja nicht so komplex aus, rein von der Ansteuerung her. Wenn man den NAND-Flash direkt vom FPGA aus verwaltet, hat man theoretisch hier keine Latenz?!? Wie sieht es mit dem PCB Design aus? Was ist im Routing besonders zu beachten? (Datenlängen, parallel Routing, Terminierung etc.) Hat wer damit schon mal Erfahrung? Danke Yafes
Yafes61 schrieb: > Das mit der Lebensdauer ist folgendermaßen grob kalkuliert Vergiss diese Kalkulation. Ich teste seit ein paar Jahren SD-Karten mit Dauerschreibversuchen. Die meisten Karten sind nach erstaunlich schneller Zeit kaputt... Ich verweise mal auf den Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi" und den darin versteckten weitergehenden Link auf den Beitrag "Re: MIcroSD Karte durch Raspberry PI zerstört" Falls du Flashspeicher (irgendwelche, denn die basieren abgesehen vom Businterface ja auf der selben Technologie!) einsetzen willst, dann solltest du vorher ausgiebige Untersuchungen machen... Yafes61 schrieb: > Wenn man den NAND-Flash direkt vom FPGA aus verwaltet, hat man > theoretisch hier keine Latenz?!? Du brauchst dann aber eine sehr schlauen Verwaltung, die mit defekten Flash-Blöcken umgehen kann. Denn solche sind bei diesen Bauteinen "normal". Und dann lies dir zum Thema "Firmware und Speicherverwaltung" wie gesagt mal die obigen Beiträge durch. Du kommst mit sehr hoher Wahrscheinlichkeit zum Ergebnis: das willst du nicht selber machen...
:
Bearbeitet durch Moderator
bei 10x32GB täglich schon mal über ein SAN aus SSDs nachgedacht das per Sata,Gb-Ethernet oder Infiniband angesperochen wird? Vermutlich reicht dann aber der Virtex5 nicht mehr aus..
Lothar M. schrieb: > Du brauchst dann aber eine sehr schlauen Verwaltung, die mit defekten > Flash-Blöcken umgehen kann. Denn solche sind bei diesen Bauteinen > "normal". Und dann lies dir zum Thema "Firmware und Speicherverwaltung" > wie gesagt mal die obigen Beiträge durch. Du kommst mit sehr hoher > Wahrscheinlichkeit zum Ergebnis: das willst du nicht selber machen... Zum Punkt defekte Flash-Blöcke. Das Datenblatt sagt mir das die Zelle 60000 Schreib- bzw. Löschzyklen hat. Kann ich dem jetzt vertrauen und die Speicherverwaltung weglassen? So wie ich dich verstehe, nein.
Yafes61 schrieb: > SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme, > da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten Hä? Wenn vorher CF ging dann geht auch SSD. Da schreibt man nicht auf einer einzelnen Zelle rum, die haben alle Wear-Leveling. Eine Samsung 960 Pro 1TB NVME erlaubt 1,2 PetaByte TBW, das sind über 10 Jahre 320GB täglich. CF oder SDXC gehen viel früher kaputt, jedenfalls bei der Schreibrate. Ich würde allerdings den RAM Chip trotzdem im Design vorsehen: Man kann nie wissen wann der SSD Controller mal 'ne Pause für interne Verwaltungsaufgaben (Wear Leveling, s.o.) einlegt.
Jim M. schrieb: > Yafes61 schrieb: >> SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme, >> da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten > > Hä? Wenn vorher CF ging dann geht auch SSD. Da schreibt man nicht auf > einer einzelnen Zelle rum, die haben alle Wear-Leveling. > > Eine Samsung 960 Pro 1TB NVME erlaubt 1,2 PetaByte TBW, das sind über 10 > Jahre 320GB täglich. > > CF oder SDXC gehen viel früher kaputt, jedenfalls bei der Schreibrate. > > Ich würde allerdings den RAM Chip trotzdem im Design vorsehen: Man kann > nie wissen wann der SSD Controller mal 'ne Pause für interne > Verwaltungsaufgaben (Wear Leveling, s.o.) einlegt. Ich hab mal eine SSD gehabt am Rechner, wo ich mal eine Testsoftware hatte die 250GB in kürzerster Zeit gefüllt hatte. Geschätzt 150x habe ich das mit dieser Platte gemacht. War ne Samsung 840 Pro. Dann habe ich diese SSD als primäre Festplatte im Einsatz mit Windows 10. Nach einer gewissen Zeit fing an mein Rechner einzufrieren wenn ich bestimme Programme nutzte. Habe dann eine Clone auf eine andere SSD gemacht, die dann ganz normal funktionierte. Die kaputte SSD habe ich eingeschickt, bekam dann die neure 850 Pro vom Hersteller über die Garantie. Die SSD hat 3 Jahre gehalten. Deswegen frage ich auch skeptisch zum Thema SSD.
Ich hat mir das mal vor 4 Jahren angeschaut, das lief darauf hinaus das man ein schnelles PCIe im FPGA implementiert und da drüber die SSD dranbammelt. http://searchsolidstatestorage.techtarget.com/podcast/PCIe-SSD-technology-offers-benefits-beyond-speed
Lothar M. schrieb: > Falls du Flashspeicher (irgendwelche, denn die basieren abgesehen vom > Businterface ja auf der selben Technologie!) einsetzen willst, dann > solltest du vorher ausgiebige Untersuchungen machen... Was ich bei solchen Projekten generell mache ist, im Dauerbetrieb (ähnlich wie dein Beitrag) Speicher komplett zu füllen (mit Zufallsdaten, LFSR) und auszulesen, dabei zu vergleichen ob Write / Read Data übereinstimmen. Das über mehrere Tage. Meinst du mit ausgiebige Untersuchung sowas?
Yafes61 schrieb: > Die SSD > hat 3 Jahre gehalten. Deswegen frage ich auch skeptisch zum Thema SSD CT hatte Stresstest mit SSDs gemacht, dabei habe die SSDs ein vielfaches der Mindestschreibleistung gehalten. Die Samsung waren am ende von Test immer noch quicklebendig. Es könnte also auch sein, das es ein "normaler" Ausfall bei dir war. https://www.heise.de/newsticker/meldung/SSD-Langzeittest-beendet-Exitus-bei-9-1-Petabyte-3755009.html
Wir haben ebenfalls SSDs am werkeln und es kommt genau zu diesem Punkt: Grundsätzlich hohe Datenrate, aber dann sporadisch und nicht gut vorhersagbar Aussetzer und Blockaden des Controllers. Die Lösung war eine Art Cache im externen RAM und eine Verwaltung, die die SSDs beschreibt und verifiziert. Am Ende sind wird mit einem Array aus 4 SSDs rausgekommen, sozusagen RAID manuell. Vielleicht schaffst Du es ja einen, RAID Controller mit dem FPGA einzubinden und anzusteuern. Keine Ahnung wie kompliziert das ist. Wir lesen ein, schreiben parallel auf zwei RAMs, (falls eins mal kaputtgehen sollte) und ziehen dann aus beiden (mit Vergleich um Sicherzustellen) die Daten langsam raus und schieben sie parallel auf 2 SDDs und ihre Spiegel. Damit hat man im Mittel die doppelte Bandbreite jeder SSD und minimal die einfache Bandbreite einer SSD. Schreib-Lese-Bandbreite des Controllers ist wegen 4x Schreiben und 2x Rücklesen + 2x Lesen aus den RAMs und 2x Schreiben so etwa : 12x Nettodatenrate. Die Frage wäre, ob es möglich ist, das in einen FPGA zu bekommen. 4x SATA sollte eigentlich gehen.
Yafes61 schrieb: > Das über mehrere Tage. > Meinst du mit ausgiebige Untersuchung sowas? Wochen. Monate... ;-) Yafes61 schrieb: > Was ich bei solchen Projekten generell mache ist, im Dauerbetrieb > (ähnlich wie dein Beitrag) Speicher komplett zu füllen und auszulesen, > dabei zu vergleichen ob Write / Read Data übereinstimmen. Beim Flash kann es auch vorkommen, dass Daten die du nicht anrührst durch das mehrmalige Löschen eines benachbarten Blocks in Mitleidenschaft gezogen werden. Du solltest also den Speicher mit Daten befüllen, dann laufend einen Block löschen und beschreiben und dabei kontrollieren, ob die nicht manipulierten Daten konstant bleiben.
Lothar M. schrieb: > Du solltest also den Speicher mit Daten befüllen, dann laufend einen > Block löschen und beschreiben und dabei kontrollieren, ob die nicht > manipulierten Daten konstant bleiben. Speicher sind inzwischen so optimiert das sie ohne Cache nicht zuverlässig funktionieren, siehe Rawhammer https://www.heise.de/security/meldung/Rowhammer-RAM-Manipulationen-mit-dem-Vorschlaghammer-2571835.html Die Caches und wear leveling sind inzwischen essential geworden, älterer Speicher mit breiteren Strukturen mag noch unkaputtbar sein, moderner Speicher mit hoher Informationsdichte ist es nicht. Der ist aber so ausgelegt, das bei normalerer Anwendung (0815 Windows-User) über die spezifizierte Lebensdauer nichts passiert.
Du könntest Dich mal bei industriellen SSDs mit SLC Flash umsehen. Nicht billig, aber für -40..+85°C verfügbar und (pro Zelle) langlebiger als MLC Flash. Aber auch hier gilt: Je größer desto besser, da besser verteilt geschrieben werden kann. Alle heutigen Consumer SSDs verwenden MLC oder gar TLC Flash, da hat man pro Zelle nur noch ein paar tausend Schreibzyklen.
Bitwurschtler schrieb: > Speicher sind inzwischen so optimiert das sie ohne Cache nicht > zuverlässig funktionieren Die Optimierung beginnt schon ganz unten auf dem Speicherchip, der sogar so "optimiert" wurde, dass die erste Fehlerbereinigung auf dem Flash selber stattfinden muss...
:
Bearbeitet durch Moderator
Mac G. schrieb: > Alle heutigen Consumer SSDs verwenden MLC oder gar TLC Flash, da hat man > pro Zelle nur noch ein paar tausend Schreibzyklen. D.h. die Langzeitdauer wird allein durch das Verteilen erreicht? Stellt sich die Frage, wie das mit den Testergebnissen der Computerzeitschriften zusammenpasst, die angeblich Dauertests auf SSDs machen und sie kaum kaputt bekommen. Ich meine: Wenn wir ständig Daten draufschreiben, ist der Trick mit dem Verteilen schnell am Limit. Und bei uns geht auch in der Tat allenthalben eine kaputt. Daher die RAID-Lösung. Eine andere Frage: Wenn man so hohe Raten hat, dass andauern geschrieben wird, warum dann nicht einfach ein RAM-Array mit Energie-Puffer? Wir hatten in einer Firma mal so eine Informix-Datenbank am werkeln. Weil die Platten alle zu langsam waren (SSDs gab es noch nicht) hat man einfach einen Rechner als Server hingestellt, der 16GB RAM hatte und immer lief. Der hat garnichts auf Platten gespeichert und Anfragen nur aus dem RAM bedient. Mit den heutigen Methoden müsste sich doch einfach eine große RAM-Disk auf einem Industriecomputer anfertigen lassen, die die Bandbreite schafft. Mein Rechner hier wäre z.B. auf 8x16GB RAM aufrüstbar, wenn Ich es bräuchte. Keine Ahnung, wie schnell da eine RAM-Disk unter Windows ist, aber 100MB/sec scheint mir machbar.:-)
Analog OPA schrieb: > Ich meine: Wenn wir ständig Daten draufschreiben, ist der Trick mit dem > Verteilen schnell am Limit. nein, weil die Platten ja immer größer werden. Bei einer 512GB platte sind 1000 mal überschreiben auch schon 512TB. Das Interface (SATA) ist einfach zu langsam um die Platte schnell kaputt zu machen.
Eine eingebute Platte wird aber nicht mehr grösser :-) Ich gebe Dir natürlich Recht: Grösse macht Langlebigkeit. Aber SATA kann immerhin bis zu 16GBit und beim Rücklesen und Vergleichen auf Fehler sowie mehrfachem Schreiben, kriegt man das schon mit einer Nettorate von 4GBit hin und das wäre 500MB/s. Wenn man nun verteilt: 1000x512GB*8/16Gbps = 72h spätestens defekt, praktisch eher früher mit etwas Sicherheit von 99% gerechnet 0,7h bei voller Rate, 7h mit 1/10 Rate. Und unser Freund braucht 100MB/s also mehr, als ein 1/10. So wie Ich es sehe, hat er schon nach 7h Vollast eine Chance von > 10% auf Plattendefekt! Bei den 10x32GB wären es 16000 Tage und 160 Tage für die 1%-Schwelle. Wir rechnen mit einer Lebensdauer nach Ausfall für 10ppm -> 1,6 Tage MTBF Das wäre nicht tragbar!
Analog OPA schrieb: > D.h. die Langzeitdauer wird allein durch das Verteilen erreicht? Ja. Wie gesagt: Wearleverling. > Stellt sich die Frage, wie das mit den Testergebnissen der > Computerzeitschriften zusammenpasst, die angeblich Dauertests auf SSDs > machen und sie kaum kaputt bekommen. Genau so, dass der Test ohne oder mit schlechtem Wearleveling schon nach kürzester Zeit beendet wäre. Wearleveling nimmt nämlich auch beliebige Daten in die Hand: wenn du dein Flash zu 99% mit statischen Daten voll hast und nur auf 1% herumschreibst, dann werden die 99% zwischendurch umsortiert, dass auch andere Speicherblöche mal "drankommen"... Yafes61 schrieb: > SSD war eine Anregung, doch da hätten wir mit der Lebensdauer Probleme, > da der Schreibzyklus einer Zelle begrenzt ist und täglich 10x32GB Daten > in den nichtflüchtigen Speicher ablegen werden soll. Wenn CF funktionieren würden, dann funktionieren auch SSD, denn das Flash in der CF ist das selbe wie in der SSD. Allein die Firmware ist je nach Businterface evtl. ein wenig unterschiedlich.
:
Bearbeitet durch Moderator
Analog OPA schrieb: > Aber SATA kann > immerhin bis zu 16GBit 6 Gbit/s - und die SSDs können langsamer werden wenn man die komplett vollschreibt. Und es sind eher 3000 - 5000 Zyklen pro Zelle.
Flash sehe ich hier als sehr problematisch an. Da bräuchte es sehr viel Redundanz und entsprechende Caches... Eine Alternative könnte MRAM sein. Leider ist diese Technologie erst in überschaubaren Speichergrößen verfügbar. Everspin will Ende des Jahres mit einem PCIe Modul mit 16GByte auf den Markt kommen: https://www.everspin.com/nvnitro-technology Mit 1Mrd. Schreibzylken und (beim PCIe Modul mit WORST-CASE Latenz von 11µs) und bis zu 6GByte/s auch ordentlich schnell: https://www.everspin.com/file/1223/download Preis ist ein anderes Thema... Vielleicht könnte so ein Modul ja dein Cache darstellen. Als Massenspeicher dann eben "Standard" Festplatten oder SSDs
Dieses SSD-Angstgemacht bringt dich hier nicht weiter. Bei deiner Datenmenge musst du bei jeder Speichertechnologie nach mindestens 3 Punkten schauen: * DWPD (Disc-Writes-Per-Day) -> damit bleibt auch die SSD während ihrer Lebensdauer am Leben * NRER (Non-Recoverable-Error-Rate) -> Chance das dir der Speicher falsche Daten als gute Daten anbietet (z.B. 10^-15 bit) * Speicherzeit unpowered -> manche SSDs bieten lt. Datenblatt nur 3 Monate Liegezeit an. Andere NAND-Flashs 30 Jahre. schreib dir deine Anforderungen auf und sieh dich um.
Danke erstmal für die Anregungen. Um Kurz zusammenzufassen: - Um einen Zwischenpuffer wie RAM komme ich nicht drum rum - SSD wäre ein Lösungsweg, hier wird die Anbindung am FPGA via PCIe benötigt, richtig?? Vorteil SSD mit SLC Technologie und dem Wearleveling hätte ich eine hohe Lebensdauer - NAND Flash wäre eine weitere Alternative - CF ist auch möglich, muss aber einen UDMA Mode benutzen um höhere Datenraten zu erreichen. Habe den Common Mode implementiert, wie aufwändig wäre es den UDMA zu implementieren? Erfahrungen wären hilfreich - Egal welcher Weg gewählt wird, alle Speicher sollten einem Stresstest über mehrere Wochen unterliegen, um Lebenszeit zu testen (!) Yafes
Yafes61 schrieb: > - Egal welcher Weg gewählt wird, alle Speicher sollten einem Stresstest > über mehrere Wochen unterliegen, um Lebenszeit zu testen (!) Ich teste bis der Speicher kaputt ist. Denn wenn ich nur 4 Wochen teste, dann weiß ich nicht, ob das Ende am nächsten Tag käme oder ob da noch 8 Wochen Luft sind...
Yafes61 schrieb: > - SSD wäre ein Lösungsweg, hier wird die Anbindung am FPGA via PCIe > benötigt, richtig?? Vorteil SSD mit SLC Technologie und dem Wearleveling > hätte ich eine hohe Lebensdauer SLC ist eigentlich zu teuer, selbst die die PRO Versionen setzen auf MLC. Sie nutzen als Cache teilweise mit MLC als SLC. > - CF ist auch möglich, muss aber einen UDMA Mode benutzen um höhere > Datenraten zu erreichen. Habe den Common Mode implementiert, wie > aufwändig wäre es den UDMA zu implementieren? Erfahrungen wären > hilfreich hier müsste man schauen ob es Wearleveling gibt. Generell würde ich CF weniger zutrauen als SSD. > - Egal welcher Weg gewählt wird, alle Speicher sollten einem Stresstest > über mehrere Wochen unterliegen, um Lebenszeit zu testen (!) Das bringt wenig, wenn selbst einfache SSDs schon mehr also 6 Monate durchhalten. Dann doch lieber auf die zugesicherten Werte aus dem Datenblatt schauen. mit PCIe kann man direkt PCIe anbinden. http://www.samsung.com/semiconductor/minisite/ssd/downloads/document/NVMe_SSD_960_PRO_EVO_Brochure.pdf Dort steht "400 Terabytes Written", das sind bei deinen 50Mbyte/s immerhin 6Jahre - reicht das nicht?
Angehängte Dateien:
-
SSD_MTBF.gif
13 KB
Man muss ein bischen unterscheiden, ob man mit dem Totalausfall der Platte rechnet, weil sie gar nicht nicht mehr beschreibar ist oder dem Zeitpunkt, ab dem die Performance sinkt, weil immer mehr fürs Suchen noch beschreibbarer Bereiche drauf geht.beschreibbarer Fläche draufgeht. Dazu ist wichtig, die Anwendung zu betrachten, wie oft und wie lange etwas genutzt wird, welche maximale Bandbreite man braucht und wie stark dafür die Performance runtergehen darf. Ich hatte das für einen SATA-Speicher für Audio-Echtzeitdaten mal abgeschätzt und bin zu folgenden Werten gelangt: MTBF ist hier die geschätzte Zeit bis zum Fehler 50% - auf Basis des Durchsatzes und der Herstellerangaben, also nur ein sehr grober Richtwert. POGO ist die period of good operation, also die Zeit, in der das System bis an die voreingestellte Fehlergrenze kommt - in der Annahme dass dann die Performance noch entsprechend ist - was sie auch ist, wenn sie die Fehler wie angegeben entwickeln. Bei so einem Daten-Aquisesystem wie beim TE darf die Bandbreite z.B. nicht wirklich runtergehen, also muss man ein niedrige Fehlergrenze ansetzen Bei einem reinen Datenspeicher, darf die wiederum hoch sein, weil man die Platte gut ausnutzen möchte. Ausserdem ist diese infolge des Datenwachstums meist schon lange voll, bevor sie getauscht werden muss. Beim Server gibt es hingegen wieder nur wenig Datenwachstum, der spielt nur hin und her - schreibt also ständig und überschreibt. Auch gibt es einen Unterschied beim Heim- und Arbeitsplatz-PC mit speicherintensiven Berechnungen Meine Schlussfolgerung: Für Server und Datenzwischenspeicher sollte man schon zu performantem Speicher greifen, der einige Schreibzyklen verträgt. Der Rest kommt mit low cost aus. Ein generelles Datensicherheitsproblem und Backup-Anspruch besteht ohnehin bei allen. Ein Serverspezi hat mir mal erklärt, dass sie das Thema Backup und Performance / Sicherheit kombinieren, indem sie die Platten deutlich VOR dem Ablaufdatum austauschen und in den Schrank legen und ab und zu mal bestromen und lesen. D.h. die Platte wird beim minimalen "Langsamerwerden" schon ausgetauscht und nur noch als Backup verwendet. Der zieht einfach jede Woche die SSDs aus dem Schacht und steckt 2 neue rein. Ob das so sinnvoll ist, kann Ich nicht einschätzen.
Yafes61 schrieb: > - SSD wäre ein Lösungsweg, hier wird die Anbindung am FPGA via PCIe > benötigt, richtig?? Vorteil SSD mit SLC Technologie und dem Wearleveling > hätte ich eine hohe Lebensdauer ja, PCIe als PHY, jedoch bräuchtest du noch ein NVMe-Treiber. Das wäre dann eine CPU mit Linux noch dazu :) oder ein NVMe-Host (z.B. IP https://www.xilinx.com/products/intellectual-property/1-f2v39l.html#productspecs). Witzigerweise will der IP noch einen nicht zu kleinen DRAM dazu. Man kann auch auf SATA-IPs gehen, aber auch hier ist das alles andere als ein einfaches Design.
Tim schrieb: > Witzigerweise will der IP noch einen nicht zu kleinen DRAM dazu. Wahrscheinlich für einen Cache? Für Datengewinnungssysteme mit vielen Schreib- und Löschzyklen sind SSDs halt nicht unbedingt der Hit. Nur im Bereich Audio wird das inzwischen intensiv gemacht, allerdings will man die Rohdaten auch behalten, solange die Produktion läuft. Also nimmt man 32 Kanäle parallel auf und schreibt etwa 2x parallel 24 MB/s weg. Dann sind zwei 64er SSDs voll. Das Ganze wenn man klug ist nochmal auf ein Backup-System gleicher Größe. Statt wie früher zu überspielen, werden die rausgezogen und daheim in den Rechner gesteckt und nondestruktiv bearbeitet, oder bei der ersten destruktiven Bearbeitung auf die interne Platte gerendert. Überspielt werden die Daten auf der SSD erst, wenn die Produktion durch ist und die CDs produziert sind, also nach Wochen. So kommt man mit ein paar Sätzen SSDs jahrelang ohne Probleme aus. Vielleicht ist eine konventionelle Platte doch eine bessere Lösung?
Jürgen S. schrieb: > Für Datengewinnungssysteme mit vielen Schreib- und Löschzyklen sind SSDs > halt nicht unbedingt der Hit. doch genau dafür sind sie der Hit weil sie verdammt schnell sind. Sie werden aus dem Grund auch in NAS als Cache eingesetzt. > Vielleicht ist eine konventionelle Platte doch eine bessere Lösung? wenn es nicht gerader im viele Terabyte geht, machen sie keinen sinn mehr. Wenn so eine SSD 7 Jahre bei durchgehend 50Myte/s hält - was will man denn noch?
Flash-Disks werden in grossen (Petabyte+-) Speichersystemen als Frontend-Cache eingesetzt. Aus eigener Erfahrung kann ich sagen, dass sie deutlich weniger oft kaputtgehen (obwohl sie naturgemäss sehr viel öfter beschrieben und gelesen werden) als die dahinterliegenden drehenden Platten. Etwa eine im Jahr während im Schnitt jeden Monat zwei "klassische" Platten draufgehen.
Wir sind grad in der Projektplanung, daher versuche ich viele Informationen zu sammeln, um später die richtige Wahl zu treffen. Vielleicht kurz nochmal zum Projekt: Es wird ein Projekt fürs Orbit sein, heißt irgendwas wechseln / tauschen ist natürlich unmöglich, daher ist ein Dauertest auch ziemlich wichtig. Heißt z.B. SSDs mit SLC, auch wenn sie teurer wären, werden natürlich bevorzugt gegenüber MLC Technologie. Strahlung ist ein weiteres Thema, womit alles noch zusätzlich belastet wird und der ständige Temperaturwechsel. Vakuum sollte nicht das Problem sein. Für die... SSD Lösung: - Geplant sind eigentlich nur 32GB Speicher. Wenn man jetzt ne 64GB SSD hätte, aber nur 32GB von benutzt wirkt es sich doch auf die Lebensdauer aus, da mit Wearleaving viel breiter gefächert werden kann weil nur die Hälfte des Speichers verwendet wird, richtig? - Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!) - Wie verbinde ich vier PCIe Lanes vom FPGA zur SSDs, quasi nicht direkt, sondern über eine NVMe-Host IP?! Der noch zusätzlich ein Speicher benötigt? NAND-Flash: - Die direkte Lösung, ohne Speicherverwaltung, heißt kaputte Zelle sind halt kaputt => würde quasi gehen, da Kameradaten, ob nun ein oder mehrere Bits kaputt sind wären egal - Hierfür wird keine IP nötig, kann quasi aus dem Datenblatt heraus eigene FSM entwickeln ?! oder täusche ich mich CF: - hier besteht eine Lösung bis 20MB/s im mittel, Common Memory Mode - Frage wäre was mit dem PIO oder UMDA Mode an Geschwindigkeitsvorteil bringt (die besagten ~100MB/s aus den Datenblättern?!) Yafes
Yafes61 schrieb: > Es wird ein Projekt fürs Orbit sein, Ich gehe davon aus, dass so gut wie alle handelsüblichen "schnelleren" Speichermedien in irgendeiner Weise RAM mit an Bord haben, der dann sicher nicht ausreichend latch-up geschützt ist? Da hast Du dann u.U. nicht nur Bitfehler, sondern Totalausfall.
:
Bearbeitet durch User
Markus F. schrieb: > Yafes61 schrieb: >> Es wird ein Projekt fürs Orbit sein, > > Ich gehe davon aus, dass so gut wie alle handelsüblichen "schnelleren" > Speichermedien in irgendeiner Weise RAM mit an Bord haben, der dann > sicher nicht ausreichend latch-up geschützt ist? > > Da hast Du dann u.U. nicht nur Bitfehler, sondern Totalausfall. Der Arbeitsspeicher ist theoretisch nicht geschützt. Kommt aber in eine Bleikammer rein, um ihn so gut wie möglich zu schützen. Einen Totalausfall hatten wir im letzten Projekt nicht, der schon lange im Orbit ist. Das FPGA hingegen wird auf Bitkipper überwacht und im Falle dessen neu konfiguriert. Alles zusammen wird natürlich vorher in einem Strahlungstest getestet, d.h. die Dosis über mehrere Jahre wird auf die gesamte Einheit belastet. Die Einheit ist auch nicht ständig an, quasi nur wenn die Basisstation Kontakt hat (~20min) oder wenn was aufgenommen werden soll (~20min). Und das ca. 15 mal am Tag im Extremfall. Yafes
Yafes61 schrieb: > SSD Lösung: > - Geplant sind eigentlich nur 32GB Speicher. Wenn man jetzt ne 64GB SSD > hätte, aber nur 32GB von benutzt wirkt es sich doch auf die Lebensdauer > aus, da mit Wearleaving viel breiter gefächert werden kann weil nur die > Hälfte des Speichers verwendet wird, richtig? ja, außerdem gibt es bei neuere SSDs keine 32GB mehr. Ein einzelner Flashbaustein hat ja schon mehr Speicher. > - Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe > Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!) Ich würde davon ausgehen, das es auch mit x1 Funktioniert.
Yafes61 schrieb: > - Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe > Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!) Nein, PCIe ist an den Leitungen skalierbar du brauchst nur einen PCIe-Core aber soviel schnelle IO (MGT - MultiGigabitTransceiver) wie du Lanes anschliessen willst. Die hat aber nicht jeder FPGA, ein Spartan6-T nur soviel wie für einfach x1 gebraucht. Der Virtex-5 sollte x4 unterstützen: https://www.xilinx.com/products/intellectual-property/v5_pci_express_block_plus.html Allerdings gibt es bei PCIe noch Unterschiede bezüglich der Generation (Gen1, Gen1.1, Gen2, Gen3) https://www.xilinx.com/products/technology/pci-express.html am besten erst mal in die PCIe Grundlagen reinschnuppern, das ist nicht ganz so trivial: https://en.wikipedia.org/wiki/PCI_Express
@ Yafes61 (Gast) >Es wird ein Projekt fürs Orbit sein, heißt irgendwas wechseln / tauschen >ist natürlich unmöglich, daher ist ein Dauertest auch ziemlich wichtig. Ähhm, was macht man dann mit 10x32 GB täglich, wenn die sowieso nicht abfließen können? 320GB funkt man nicht einfach mal so zur Erde. >- Geplant sind eigentlich nur 32GB Speicher. Wenn man jetzt ne 64GB SSD >hätte, aber nur 32GB von benutzt wirkt es sich doch auf die Lebensdauer >aus, da mit Wearleaving viel breiter gefächert werden kann weil nur die >Hälfte des Speichers verwendet wird, richtig? Ja. >- Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe >Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!) Wo liegt das Problem? >- Die direkte Lösung, ohne Speicherverwaltung, heißt kaputte Zelle sind >halt kaputt => würde quasi gehen, da Kameradaten, ob nun ein oder >mehrere Bits kaputt sind wären egal Wirklich? Dann sieht euer "Teleskop" plötzlich komische Objekte. Ob das so sinnvoll ist. Hier würde ich MINDESTENS eine CRC draufpacken, wenn man die Fehler wieder korrigieren will eine ECC. >- Hierfür wird keine IP nötig, kann quasi aus dem Datenblatt heraus >eigene FSM entwickeln ?! Kann man, ist aber ein wenig hemdsärmelig. Und das soll dann in den Orbit? Spionagesatellit für Arme? >- Frage wäre was mit dem PIO oder UMDA Mode an Geschwindigkeitsvorteil >bringt (die besagten ~100MB/s aus den Datenblättern?!) Naja, das ist nur die Bandbreite der Schnittstelle. Der Flash MUSS das nicht zwangsläufig schaffen, schon gar nicht dauerhaft.
Falk B. schrieb: >>Es wird ein Projekt fürs Orbit sein, heißt irgendwas wechseln / tauschen >>ist natürlich unmöglich, daher ist ein Dauertest auch ziemlich wichtig. > > Ähhm, was macht man dann mit 10x32 GB täglich, wenn die sowieso nicht > abfließen können? 320GB funkt man nicht einfach mal so zur Erde. Deswegen ja auch 10x :-) Quasi 10 Überflüge Falk B. schrieb: >>- Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe >>Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!) > > Wo liegt das Problem? Weil ich ja dann mir einen bestimmten Virtex 5 besorgen muss der 4 Lanes hat, meiner hat angeblich nur 3.
Yafes61 schrieb: >> Wo liegt das Problem? > > Weil ich ja dann mir einen bestimmten Virtex 5 besorgen muss der 4 Lanes > hat, meiner hat angeblich nur 3. Geht's um den im "Bleianzug" ?! https://www.xilinx.com/support/documentation/data_sheets/ds192_V5QV_Device_Overview.pdf Da haste zwar nur 3 Blöcke aber jeder sollte 1,4 oder 8 lanes können (see p.12)
Yafes61 schrieb: > Weil ich ja dann mir einen bestimmten Virtex 5 besorgen muss der 4 Lanes > hat, meiner hat angeblich nur 3. wie schon oben geschrieben, reicht auf 1 Lane aus.
@Yafes61 (Gast) >> Ähhm, was macht man dann mit 10x32 GB täglich, wenn die sowieso nicht >> abfließen können? 320GB funkt man nicht einfach mal so zur Erde. >Deswegen ja auch 10x :-) Quasi 10 Überflüge Ja und dann? 1000 Überflüge um die Daten loszuwerden?
Yafes61 schrieb: > Wenn ich mir die SSDs mit Form Factor M2.2280 angucke sehe ich x4 PCIe > Lanes, heißt ich muss im FPGA 4x PCIe implementieren können (!) Ich bezweifle dass so ein Consumer-grade Stecker die Vibrationen beim Start übersteht. Ich habe den Eindruck dass du sehr blauäugig an das Thema ran gehst, selbst wenn es nur um einen Cubesat gehen sollte. Verzichte auf Stecker und löte eMMC-Flash drauf, eventuell mehrere parallel für Bandbreite.
Blechbieger schrieb: > Ich bezweifle dass so ein Consumer-grade Stecker die Vibrationen beim > Start übersteht. Im Datenblatt gibt es zumindest kein Limit Vibration: No electrical discontinuity greater than 1u sec shall occur. Mechanical Shock: No electrical discontinuity greater than 1u sec shall occur. Wenn man Start nicht aktiv, sollte es also keine Probleme geben, so mal die SSD ja verschraubt ist.
Peter II schrieb: > doch genau dafür sind sie der Hit weil sie verdammt schnell sind. Im Sinne der Langlebigkeit, meinte Ich. Gegenüber Platten mit ihrem Cache haben sie eben den Vorteil der großen Speicherfläche. Wenn man aber einen FPGA in der Schaltung hat, dann wäre ein echtes S-RAM der gegebene Puffer, um die dynamische Rate zu packen. Der Rest mit genug Parallelität auf Platte. Es gibt ja diese Micro-Drives. Die habe Ich auch schon mal als Wechselsystem eingesetzt.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.