Ist eine Fehlerkorrektur via Software bei Fehlern im RAM möglich?
-
rapso schrieb:
Entsprechend kommt es auf die anforderungen an die man hat, aber einfach fehlererkennung bzw fehlerkorrektur grundsaetzlich ausschliessen ist nicht wirklich eine durchdachte reaktion.
^^das sehe ich genauso. ohne ECC bzw. FEC hätten wir heute weder mobilfunk noch WLAN, kein DSL und CDs auch nicht. fehlererkennung und -beseitigung ist schon fast 'ne schlüsseltechnologie, die es uns erlaubt, unser digitales zeug über die grützigsten übertragungswege zu scheuchen und auf den miesesten medien zu speichern.
-
naja es wurde konkret geschrieben "so eine Art Software ECC". ich hab mich da wohl ein wenig zu sehr auf den "Software ECC" teil konzentriert, und den "so eine Art" teil ignoriert.
ich meine einfach, dass man eine fehlererkennung/-korrektur die so vollständig/sicher ist wie eine hardware ECC implementierung, in software einfach nicht machen kann.
dass man trotzdem einiges machen kann ist klar. also "so eine Art" ja, aber eben nicht gleich gut.
-
hustbaer schrieb:
ich meine einfach, dass man eine fehlererkennung/-korrektur die so vollständig/sicher ist wie eine hardware ECC implementierung, in software einfach nicht machen kann.
warum nicht? die algorithmen bzw. verfahren wären dieselben, ist im grunde egal, ob du sie in hardware oder software implementierst. die software-version ist langsamer, weil sie für gewisse dinge, die in hardware zeitgleich passieren, einen haufen maschinencode durch 'ne CPU schubsen muss. aber das wäre auch der einzige unterschied.
-
abc.w schrieb:
rapso schrieb:
...es kommt ganz auf die implementierung an, ich habe implementierungen gesehen die sowas per hand machten...
die armen Programmierer, die sowas gemacht haben...dachte ich auch erst, aber als ich dann den kranken spass gesehen habe den sie impmlementierten, war ich eher neidisch
naja es wurde konkret geschrieben "so eine Art Software ECC". ich hab mich da wohl ein wenig zu sehr auf den "Software ECC" teil konzentriert, und den "so eine Art" teil ignoriert.
ich meine einfach, dass man eine fehlererkennung/-korrektur die so vollständig/sicher ist wie eine hardware ECC implementierung, in software einfach nicht machen kann.
dass man trotzdem einiges machen kann ist klar. also "so eine Art" ja, aber eben nicht gleich gut.
die hardware erkennung/bereinigung ist auch nicht die sicherste, da man ja mit sehr limitierten speicherresourcen klarkommen muss und ECC meines wissens auch nur ein fehlerhaftes bit bereinigen kann. die chancen auf zwei im selben bereich sind zwar normalerweise gering, aber wenn ein speicherriegel gerade kaputt geht, dann ist es ueblicher (und dann piept der rechner wie ein flipper automat :D)
im gegensatz dazu kannst du in software komplett speicherbereiche spiegeln, wenn es sein muss. software fehlerkorrekturen sind eigentlich ne sehr uebliche sache, nicht gerade in bezug auf ram, aber sonst bei den meisten netzwerk protokollen, bei laufwerken/medien und die validierung wird oft in software gemacht.
ich denke, wenn er etwas from scratch programmiert, wird er mit etwas vorsicht auch ne sichere sache implementieren koennen.
-
;fricky schrieb:
hustbaer schrieb:
ich meine einfach, dass man eine fehlererkennung/-korrektur die so vollständig/sicher ist wie eine hardware ECC implementierung, in software einfach nicht machen kann.
warum nicht? die algorithmen bzw. verfahren wären dieselben, ist im grunde egal, ob du sie in hardware oder software implementierst. die software-version ist langsamer, weil sie für gewisse dinge, die in hardware zeitgleich passieren, einen haufen maschinencode durch 'ne CPU schubsen muss. aber das wäre auch der einzige unterschied.
wie willst du den check für den stack machen, auf dem registerinhalte + rücksprungadresse landen, die gesichert werden, weil gerade ein interrupt losgeht? in software geht das nicht. in hardware ist das ganz einfach, weil die logik in den speicher-controller integriert ist.
das meine ich mit "vollständig".
-
raps schrieb:
naja es wurde konkret geschrieben "so eine Art Software ECC". ich hab mich da wohl ein wenig zu sehr auf den "Software ECC" teil konzentriert, und den "so eine Art" teil ignoriert.
ich meine einfach, dass man eine fehlererkennung/-korrektur die so vollständig/sicher ist wie eine hardware ECC implementierung, in software einfach nicht machen kann.
dass man trotzdem einiges machen kann ist klar. also "so eine Art" ja, aber eben nicht gleich gut.
die hardware erkennung/bereinigung ist auch nicht die sicherste, da man ja mit sehr limitierten speicherresourcen klarkommen muss und ECC meines wissens auch nur ein fehlerhaftes bit bereinigen kann.
das kommt auf die implementierung an. du hast bei ECC ram ein zusätzliches bit pro byte zur verfügung. wenn du eine blockgrösse von z.b. 16 oder gar 64 byte nimmst, kannst du da ziemlich viel damit anfangen. auch doppelbit fehler korrigieren, und fehler mit mehr als 2 bit immer noch sehr zuverlässig erkennen.
die chancen auf zwei im selben bereich sind zwar normalerweise gering, aber wenn ein speicherriegel gerade kaputt geht, dann ist es ueblicher (und dann piept der rechner wie ein flipper automat :D)
im gegensatz dazu kannst du in software komplett speicherbereiche spiegeln, wenn es sein muss.es gibt auch sog. "chipkill" RAM. da kannst du während der rechner läuft ein schadhaftes modul rausnehmen und austauschen, ohne dass irgendwas passiert. alles kein problem, bzw. alles nur eine kostenfrage
software fehlerkorrekturen sind eigentlich ne sehr uebliche sache, nicht gerade in bezug auf ram
wir reden hier aber über RAM.
ich denke, wenn er etwas from scratch programmiert, wird er mit etwas vorsicht auch ne sichere sache implementieren koennen.
siehe meine antwort an fricky: es gibt dinge, die kannst du mit einer software implementierung für RAM einfach nicht machen.
p.S.: bei netzwerk-protokollen verwendet man eher fehler-erkennung + re-transmission als fehlerkorrektur. und auch bei festplatten, CD-ROMs etc. giesst man solche sachen heute eher in hardware als da über software was zu machen. was aber mit dem eigentlichen thema dieses threads nichts zu tun hat, und was auch nicht bedeutet dass man DIESE dinge nicht einfach in software machen könnte. wenn man dem arbeitsspeicher vertraut, ist es einfach, über andere dinge fehlerkorrektur zu rechnen. wenn man aber - ausser ein paar registern - nichts mehr hat, wird es schwierig bis unmöglich.
p.p.S.: bei CPUs auf denen man den cache direkt adressieren kann ginge vermutlich was. bzw. wenn man z.B. on-chip RAM hat dem man vertrauen kann. und natürlich vorausgesetzt man bekommt das erwähnte problem mit z.b. interrupts irgendwie in den griff.
-
hustbaer schrieb:
;fricky schrieb:
hustbaer schrieb:
ich meine einfach, dass man eine fehlererkennung/-korrektur die so vollständig/sicher ist wie eine hardware ECC implementierung, in software einfach nicht machen kann.
warum nicht? die algorithmen bzw. verfahren wären dieselben, ist im grunde egal, ob du sie in hardware oder software implementierst. die software-version ist langsamer, weil sie für gewisse dinge, die in hardware zeitgleich passieren, einen haufen maschinencode durch 'ne CPU schubsen muss. aber das wäre auch der einzige unterschied.
wie willst du den check für den stack machen, auf dem registerinhalte + rücksprungadresse landen, die gesichert werden, weil gerade ein interrupt losgeht? in software geht das nicht.
du brauchst nur dafür zu sorgen, dass für die fehlerkorrigier-routine selbst intakter speicher vorhanden ist (also für ihren code und ihre variablen), dann musste dir überlegen, wie ein zugriff auf den angeschlagenen speicher die fehlerkorrektur antriggert. beispiel für ARM-CPUs: zugriff auf unbelegte adressen löst eine sogenannte 'data-abort exception' aus. du definierst nun einen teil des 'freien' adressraums für das defekte RAM uns sagst deinem programm: 'hier hast du speicher'. greift das programm nun auf eine dieser adressen zu, gibt's 'ne data-abort exception. dein exceptionhandler simuliert den zugriff einschliesslich fehlerkorrektur und springt wieder zurück. das hauptprogramm merkt davon nicht das geringste. solche abgefangenen zugriffe sind natürlich wesentlich langsamer, als richtige speicherzugriffe, aber das wissen wir ja schon seit der ersten seite. das ganze geht übrigens auch aus interrupt-routinen heraus, weil exceptions eine höhere priorität haben.
^^btw, ich hab' sowas ähnliches mal gemacht, allerdings nicht mit einer fehlerkorrektur, sondern als speichererweiterung ein serielles RAM in den adressraum eines ARM-basierten controllers eingeblendet.hustbaer schrieb:
p.S.: bei netzwerk-protokollen verwendet man eher fehler-erkennung + re-transmission als fehlerkorrektur.
kannste so pauschal nicht sagen. manchmal erreicht man mit fehlerkorrektur einen höheren durchsatz als mit paketwiederholungen (am besten mit einem mix aus beidem, siehe z.b. WLAN).
-
;fricky schrieb:
du brauchst nur dafür zu sorgen, dass für die fehlerkorrigier-routine selbst intakter speicher vorhanden ist (also für ihren code und ihre variablen)
hast du aber üblicherweise auf einem system ohne hardware ECC nicht.
d.h. nicht ausser den registern.und denk mal nach: wo liegen denn die daten für die MMU? richtig, im speicher. hast du wieder ein stück speicher das du nicht prüfen kannst.
-
hustbaer schrieb:
;fricky schrieb:
du brauchst nur dafür zu sorgen, dass für die fehlerkorrigier-routine selbst intakter speicher vorhanden ist (also für ihren code und ihre variablen)
hast du aber üblicherweise auf einem system ohne hardware ECC nicht.
d.h. nicht ausser den registern.dann starten wir eben am anfang eine kleine assembler-routine, die ein paar zusammenhängened RAM-zellen sucht, die heile sind, damit sie der fehlerkorrigierer benutzen kann. wenn wir von den bedingungen des OP ausgehen, der geschrieben hat, dass einzelne defekte bits immer 0 oder 1 sind (also nicht erst nach einer gewissen zeit umkippen) muss der kleine asm-code nur abwechselnd 0x55 und 0xaa schreiben und zurücklesen, dazu braucht er kein eigenes RAM. und dann sollte das funzen. etwas mehr phantasie bitte, meister petz. *fg*
-
@;fricky:
Wenn du guckst was ich auf Seite zwei geschreiben habe, wirst du vermutlich verstehen, warum mich diese Idee nun nicht gerade aus den Socken haut.
hustbaer schrieb:
NASA schrieb:
Stellt euch einfach mal vor, das RAM einer Sonde der NASA ist defekt und nun würde man mit einem SW Patch das Problem beheben wollen.
Wenn man die defekten Stellen im RAM kennt, ist das denke ich kein Problem.
Auch defekte Stellen zu finden sollte kein Problem sein.Schwierig bis unmöglich wird es erst dann, wenn man spontan auftretende Fehler "verlustfrei" überstehen können möchte, wie das eben mit ECC RAM recht gut geht.
Ein bisschen besser mitlesen bitte, Herr Sperrdifferenzialrat.
