Wahrscheinlichkeit für einen Rechenfehler

[ethrandil]

Hallo,

oft wird argumentiert ein Algorithmus sei zwar nicht 100 prozentig korrekt, aber es sei so unwahrscheinlich dass er einmal falsch liegt, dass ein Rechenfehler des Computers wahrscheinlicher ist.

Nun frage ich mich: Wie groß ist die Wahrscheinlichkeit, dass sich ein handelsüblicher Computer verrechnet? In welcher Größenordnung liegt das?

mfg
- eth

[Trap]

Die einfachste und wahrscheinlichste Variante ist Speicherbits kippen um. Wenn man Speicher mit ECC hat, dann weiß ich nichtmehr welcher Mechanismus am wahrscheinlichsten Fehler verursacht. Dürfte aber seltener als einer pro Jahr sein.

[Elrood]

Die einfachste und wahrscheinlichste Variante ist Speicherbits kippen um. Wenn man Speicher mit ECC hat, dann weiß ich nichtmehr welcher Mechanismus am wahrscheinlichsten Fehler verursacht. Dürfte aber seltener als einer pro Jahr sein.

Ich meine gehört zu haben, daß man bei DRAM von einem Bitfehler pro GB und Tag ausgeht...

[transstilben]

Ich meine gehört zu haben, daß man bei DRAM von einem Bitfehler pro GB und Tag ausgeht...


Das erscheint mir deutlich zu pessimistisch. Ein Server (z.B. auf Linux) der auf einem "normalen" PC
mehrere Monate durchläuft und sagen wir ein GB Ram hat, sollte das "merken". Man bekäme das ja dann z.B. über falsche Checkksummen mit ...
Fehlerkorrigierende Maßnahmen wie ECC mal außer acht gelassen.

Man könnte ja auch mal ein Experiment machen: Jemand (besser mehrere) der seinen Internet-PC längere Zeit (Wochen) durchlaufen läßt, startet ein
Detektionsprogramm, daß nach "kippenden" Ram-Bits sucht.
Ich würde denken, daß bei 1 GB RAM im Mittel > 3 Monate nichts passiert. Demnach wäre Deine Angabe, Elrood zwei Größenordnungen
zu pessimistisch. Für generell aussagekräftige Ergebnisse wäre das Experiment sicher ungeeignet ... ich denke da z.B. an Störgrößen, wie den
Stromversorger, usw.

[Wuge]

Ich hab schon teilweise mehr als 12 Stunden Speichertests laufen lassen und trotz stark übertaktetem Speicher keine Fehler bekommen.

Bei nicht übertakteten Modulen dürfte die Fehlerquote noch deutlich niedriger sein.

[Gast]

Hallo,
Nun frage ich mich: Wie groß ist die Wahrscheinlichkeit, dass sich ein handelsüblicher Computer verrechnet? In welcher Größenordnung liegt das?



Bei meiner Festplatte wird eine MTBF (mean time between fault) von 600000 Stunden angegeben.
Wenn man nun mal die mechanische Komponente außer acht läßt (die ich selbst für die kritischere halte) und bedenkt,
daß da ja auch ein handelsüblicher Computer mit 16 MB Cache RAM und einer Menge Software am Werke ist,
sollte das doch ein guter Anhaltspunkt sein, oder ? Ich glaube jedenfalls, daß die Wahrscheinlichkeit für einen
Stromausfall deutlich größer ist (ot: Wie groß ist DIE eigentlich ?) als für einen Rechenfehler.

[RaumKraehe]

Hallo,

oft wird argumentiert ein Algorithmus sei zwar nicht 100 prozentig korrekt, aber es sei so unwahrscheinlich dass er einmal falsch liegt, dass ein Rechenfehler des Computers wahrscheinlicher ist.

Nun frage ich mich: Wie groß ist die Wahrscheinlichkeit, dass sich ein handelsüblicher Computer verrechnet? In welcher Größenordnung liegt das?

mfg
- eth

Laut IBM darf sich ein Rechner ein mal in 20000 Jahren einfach so verechnen. Da mit sind keine Fehler der Software oder Hardware gemeint (inkl ECC-Speicher und solcher Spielereien). Sondern der verechnet sich einfach so. Finde die Quelle nur momentan nicht.

[transstilben]

Laut IBM darf sich ein Rechner ein mal in 20000 Jahren einfach so verechnen. Da mit sind keine Fehler der Software oder Hardware gemeint (inkl ECC-Speicher und solcher Spielereien). Sondern der verechnet sich einfach so. Finde die Quelle nur momentan nicht.

Meiner Meinung nach gehen da viele Parameter ein. Die NASA hat z.B. das Problem, daß die CPU's mit heute gängigen Strukturbreiten aufgrund von kosmischer Strahlung im All sehr viel störanfälliger sind,
als ein 8086 mit einem Micrometer. Wenn also IBM sagt IM MITTEL einmal in 20000 Jahren, dann gilt das nicht zwangsläufig im All und auch nicht zwangsläufig für aktuelle "geschrumpfte" Prozessoren von AMD oder INTEL.

[micki]

er hat nach verrechnen gefragt, nicht nach speicherfehlern.

ein pc verrechnet sich bei jeder float berechnung, im IEEE standard fuer single/double ist auch deifiniert wie gross der rechenfehler sein darf damit es standardconform ist. machst du mehrere berechnungen hintereinander, dann kommt auch mehr ungenauigkeit rein. Oft kommt auch unterschiedliches raus wenn du eine formel auf mehrere teilschritte aufteilst, statt sie in einer zeile zu schreiben. diese rechenfehler sind dann natuerlich auch cpu abhaengig, AMD, INTEL, SUN usw. werden dir leicht unterschiedliche resultate liefern.

[RaumKraehe]

er hat nach verrechnen gefragt, nicht nach speicherfehlern.

ein pc verrechnet sich bei jeder float berechnung, im IEEE standard fuer single/double ist auch deifiniert wie gross der rechenfehler sein darf damit es standardconform ist. machst du mehrere berechnungen hintereinander, dann kommt auch mehr ungenauigkeit rein. Oft kommt auch unterschiedliches raus wenn du eine formel auf mehrere teilschritte aufteilst, statt sie in einer zeile zu schreiben. diese rechenfehler sind dann natuerlich auch cpu abhaengig, AMD, INTEL, SUN usw. werden dir leicht unterschiedliche resultate liefern.

Das hat aber nichts mit Rechenfehlern zu tun. Sondern das ist eher ein Problem der begrenzten Genauigkeit heutiger Rechenwerke. Zumindest ist das meine Meinung.

Ab einer bestimmten Genauigkeit kann man mit heutigen Rechnern nicht mehr 100% vom Ergebniss auf die Ausgangswerte schließen da viel zu viele Informationen wärend des Rechnens einfach verpuffen. Das glit natürlich nicht für eine einfache Integer-Rechnung.

[Trap]

ein pc verrechnet sich bei jeder float berechnung, im IEEE standard fuer single/double ist auch deifiniert wie gross der rechenfehler sein darf damit es standardconform ist.
Nicht nur das, es ist auch definiert was das Ergebnis sein muss. Nach IEEE gibt es für jede Operation genau 1 richtiges Ergebnis und das berechnen die CPUs auch sehr zuverlässig.

machst du mehrere berechnungen hintereinander, dann kommt auch mehr ungenauigkeit rein. Oft kommt auch unterschiedliches raus wenn du eine formel auf mehrere teilschritte aufteilst, statt sie in einer zeile zu schreiben. diese rechenfehler sind dann natuerlich auch cpu abhaengig, AMD, INTEL, SUN usw. werden dir leicht unterschiedliche resultate liefern.
Das sind die Probleme bei der Entwicklung von Software mit FP Rechnungen, das hat nix damit zu tun, dass sich CPUs verrechnen würden.

Die Probleme die du da aufzählst, liegen daran, dass fast alle Programmiersprachen es mit den floats nicht so genau nehmen und damit für definierte Ergebnisse nicht zu gebrauchen sind. Man kann natürlich jeweils in ASM für jeden Befehlssatz Code schreiben, der exakt das gleiche Ergebnis ergibt, lohnt sich aber in den meisten Fällen nicht.

[_Dirk_]

Beim Datenaustausch zwischen verschiedenen Clockdomains (z.B. CPU <-> RAM)
kommt es grundsätzlich zu einem Synchronisationsproblem. Setup- oder Holdtime der FFs in den Synchronisationsschaltungen können dabei nicht immer eingehalten werden, so daß es zu metastabilen Zuständen kommen kann. Die Wahrscheinlichkeit hierfür (MTBF) hängt von den Frequenzen der Clockdomains, der Abfrage-Frequenz (Abfragen der Synchronisationsschaltung) und von den verwendeten FFs ab.

Abhängig von diesen Faktoren kann sich eine MTBF von wenigen Sekunden oder auch von millionen von Jahren ergeben. Ich glaube das die Synchronisationsschaltungen normalerweise so ausgelegt werden, daß sich eine MTBF von mindestens 100 Jahren ergibt. Dies bedeutet aber nicht, daß ein Rechner dann garantiert 100 Jahre fehlerfrei läuft. Es kann theoretisch auch schon nach wenigen Sekunden zu einem Fehler kommen (auch wenn dies extrem unwahrscheinlich ist).

[Gast]

Wie würde ein Rechenfehler vom User wahrgenommen?

[RaumKraehe]

Wie würde ein Rechenfehler vom User wahrgenommen?

Am falschen Ergebniss?

[Gast]

Jo, aber auch nur wenn man gerade den Rechner benutzt. ;)

Er kann isch ja auch in einem Spiel verrechnen. Kann dies zu einem Absturz führen? Oder wird dann im Spiel einfach kurz etwas falsch dargestellt (würde mann ja höchstwarscheinlich nicht bemerken)?

[Trap]

Wie würde ein Rechenfehler vom User wahrgenommen?
Das kommt drauf an in welcher Berechnung er vorkommt. Es kann garnichts ausmachen, die Anwendung abstürzen lassen, alles mögliche...
Falsche Ergebnisse sind nicht die einzige mögliche Auswirkung.

Es gibt da von den fault-tolerant systems Leuten einigen Studien dazu, wie sich einzelne Fehler fortplanzen, beobachtbare Auswirkungen sind eher die Ausnahme, zumindest bei Fehlern im Betriebssystemcode.

[Gauron Kampeck]

In der Kommunikationstechnikvorlesung (für die ich gerade lerne:frown:) wird eine Bitfehlerwahrscheinlichkeit bei CPUs von 10^-9 angegeben. Ich vermute aber, dass fast alle Fehler durch Redundanz im Chip aufgefangen werden, da sich sonst die Rechner sekündlich (bei Taktraten im GHz-Bereich) verrechnen würden, so dass die Anzahl der nicht erkannten Fehler um einige 10er-Potenzen sinkt.
Desweiteren soll die hier angesprochene kosmische Strahlung nicht nur bei Satelliten Probleme bereiten. Irgendwo hab ich mal gelesen, dass bereits auf einem Interkontinantalflug ein (modernes, sagen wir 65nm-CPU) Notebook während der Reise mit ca. 50%iger Wahrscheinlichkeit abstürzt.

[transstilben]

Ich wage mal eine Schätzung: Die Wahrscheinlichkeit, daß sich ein handelsüblicher Einfach-Server (mit üblicher fehlerkorrigierender Hardware)
in seiner Lebzeit (sagen wir 15 Jahre) einmal "spontan" verrechnet, ist kleiner als 0.5

[Gast]

Schonmal nach einem Sonnensturm ergebniskritische Anwendungen ausgeführt?
Ich hatte das mal mit SuperPI, hat sich ewig verrechnet. Aber den nächsten Tag war es, trotz gleichen Einstellungen, wieder okay.

[RaumKraehe]

Schonmal nach einem Sonnensturm ergebniskritische Anwendungen ausgeführt?
Ich hatte das mal mit SuperPI, hat sich ewig verrechnet. Aber den nächsten Tag war es, trotz gleichen Einstellungen, wieder okay.

Also wenn dein Rechner in einer orbitalen Umlaufbahn um die Erde fliegen würde könnte ich dir das glauben. Aber auf der Erde bei einer Höher +/- 500m @ Meerespiegel kann ich mir das beim besten willen nicht vorstellen. :eek:

[transstilben]

Schonmal nach einem Sonnensturm ergebniskritische Anwendungen ausgeführt?
Ich hatte das mal mit SuperPI, hat sich ewig verrechnet. Aber den nächsten Tag war es, trotz gleichen Einstellungen, wieder okay.


Ja, ohne es zu wissen. Sicher, daß Deine Hardware innerhalb der Spezifikation läuft ?
Hast du eine USV ? Hast du ECC- oder Parity-gecheckten RAM ? War es heiß draußen ?
Bist du sicher, daß du die Wahrscheinlichkeitsrechnung richtig verstanden hast ?

[MrMostar]

siehe hier:
http://www.edn.com/index.asp?layout=article&articleid=CA454636
zitat:
The potential impact on typical memory applications illustrates the importance of considering soft errors. A cell phone with one 4-Mbit, low-power memory with an SER of 1000 FITs per megabit will likely have a soft error every 28 years. A high-end router with 10 Gbits of SRAM and an SER of 600 FITs per megabit can experience an error every 170 hours. For a router farm that uses 100 Gbits of memory, a potential networking error interrupting its proper operation could occur every 17 hours. Finally, consider a person on an airplane over the Atlantic at 35,000 ft working on a laptop with 256 Mbytes (2 Gbits) of memory. At this altitude, the SER of 600 FITs per megabit becomes 100,000 FITs per megabit, resulting in a potential error every five hours.
kommt also wesentlich häufiger vor, nur muss man solche Fehler erst mal entdecken...

Gruss

[transstilben]

siehe hier:
http://www.edn.com/index.asp?layout=article&articleid=CA454636
zitat:

kommt also wesentlich häufiger vor, nur muss man solche Fehler erst mal entdecken...

Gruss


Nehmen wir doch mal das Beispiel der Suche nach Primzahlen.
Viele viele Rechner rechnen Monate lang. Anschließend wird (bei positivem Befund)
das Ergebnis von anderer Hardware verifiziert. Hier sollte ein Fehler sofort entdeckt werden.
Wohlgemerkt, geht es hier nicht um überhitzende, übertaktete unzuverlässige Billig-Hardware vom Discounter,
die an einer 1 Euro 95 Mehrfachsteckdosenleiste hängt, an der außerdem ein Teekocher und ein schlecht entstörter Fön eingesteckt sind. :nono:

[MrMostar]

Lese bitte mal den ganzen Artikel.
die Primzahlberechnung benötigt nur einen winzigen Bruchteil des Gesamtspeichers (etliche Zehnerpotenzen kleiner als der gesamte Speicher)
So ist es nicht erwunderlich, das die Bitfehlereinschläge auch über Monate hinweg nicht gerade die Variablen des Primzahlberechnungsprogramms treffen.
Würdest du ein Programm verwenden dessen Variablen den GESAMTEN Speicher verwenden, würdest du schon auf Fehler alle 101 bis 102 Stunden treffen.

[transstilben]

Lese bitte mal den ganzen Artikel.
die Primzahlberechnung benötigt nur einen winzigen Bruchteil des Gesamtspeichers (etliche Zehnerpotenzen kleiner als der gesamte Speicher)
So ist es nicht erwunderlich, das die Bitfehlereinschläge auch über Monate hinweg nicht gerade die Variablen des Primzahlberechnungsprogramms treffen.
Würdest du ein Programm verwenden dessen Variablen den GESAMTEN Speicher verwenden, würdest du schon auf Fehler alle 101 bis 102 Stunden treffen.

Mir ist durchaus bewußt, daß der Speicher ein kritischer Faktor ist und daß es vom konkreten Programm abhängig ist,
ob man einen Speicherfehler bemerken würde oder nicht. Ich habe ja schon weiter oben vorgeschlagen, in einem eigenen Experiment, die Wahrscheinlichkeit eines kippenden Bits im Speicher auf der in Frage stehenden Hardware zu bestimmen.
ECC und Parity würden ja auch gar keinen Sinn machen, wenn die Wahrscheinlichkeit für einen Fehler bei einer bestimmten Speichergröße
nicht einen bestimmten relevanten Wert erreichen würde ...

[Paul Brain]

Ich habe hier seit 3 Jahren 2GB ECC-Speicher im Einsatz, und es gab bislang keinen einzigen Speicherfehler, den ECC korrigieren hätte müssen. Das Reporting ins DMI-Log ist für Single- und Multibitfehler eingeschaltet, aber da stand noch nie was anderes drin als viell. eine CMOS-Checkum-Error nach einem BIOS-Update, oder ein Keyboard error wenns mal nach einem Umbau vergessen wurde anzuschliessen... ;-)

Solche Speicherfehler dürften also wirklich extremst selten sein, wiewohl sie aber auch sicher auftreten. Wissen kann mans nie, viell. steht in meinem Log in diesem Moment bereits was drinnen... ;-)

[mickii]

Das hat aber nichts mit Rechenfehlern zu tun.es ist ein rechenfehler aufgrund begrenzter genauigkeit, nur weil er vordefinierte ausmasse hat, ist es nicht kein rechenfehler.

[mickii]

Nicht nur das, es ist auch definiert was das Ergebnis sein muss. Nach IEEE gibt es für jede Operation genau 1 richtiges Ergebnis und das berechnen die CPUs auch sehr zuverlässig.1 Ergebnis innerhalb vom Tolleranzbereich, bei den CPU-herstellern kann man sogar die genauen angaben finden wieviel ihre FPU vorbeirechnet. Ueber die Zeit akkumulieren sich die Fehler.



Das sind die Probleme bei der Entwicklung von Software mit FP Rechnungen, das hat nix damit zu tun, dass sich CPUs verrechnen würden.Es hat nur mit der ungenauigkeit der FPU zu tun, die Software baut dann nur auf den Fehlern der FPU und kann nichts dafuer. Beweis -> Ein und dieselbe Software laeuft auf verschiedenen CPUs -> abweichende Ergebnisse.


Man kann natürlich jeweils in ASM für jeden Befehlssatz Code schreiben, der exakt das gleiche Ergebnis ergibt, lohnt sich aber in den meisten Fällen nicht.
Es stimmt schon das es zum einen an compilern liegt, aber ebenso ungenau sehen es die FPU hersteller, ich hatte schon in assembler geschriebene programme (bzw programmteile) zum compilieren von BSP-trees die auf nem pentium ganz andere Trees lieferten als auf nem K6.

[Trap]

1 Ergebnis innerhalb vom Tolleranzbereich, bei den CPU-herstellern kann man sogar die genauen angaben finden wieviel ihre FPU vorbeirechnet. Ueber die Zeit akkumulieren sich die Fehler.
Entweder es gibt einen Toleranzbereich oder es gibt nur 1 richtiges Ergebnis, beides gleichzeitig geht nicht. Da du so schön behauptest hast, dass man das bei den CPU-Herstellern finden kann, gib mal einen Link :biggrin:

[mickii]

Entweder es gibt einen Toleranzbereich oder es gibt nur 1 richtiges Ergebnis, beides gleichzeitig geht nicht. Da du so schön behauptest hast, dass man das bei den CPU-Herstellern finden kann, gib mal einen Link :biggrin:
auf die schneller z.b. :
http://developer.download.nvidia.com/compute/cuda/0_8/NVIDIA_CUDA_Programming_Guide_0.8.pdf
appendix A

fuer pentium(1) und k6 hatte ich die paper auch mal gefunden. bin jetzt aber zu faul fuer "richtige" cpus zu suchen.

[czuk]

Schaut euch mal um bei SEU / MBU , oder zu deutsch Neutronenbeschuß aus dem All.
Vor Neutronen kann man sich verdammt schlecht schützen, es gibt auch Regionen auf der Welt, die stärker betroffen sind als wir. Kritischer wird die Geschichte, je kleiner die Strukturen und je größer die Speicherdichten werden.
So gab es Rechenzentren, die durch die bloße Umstellung auf höhere Speicherdichten plötzlich ein Vielfaches an Bitkippern hatten als gewohnt.

Die Wahrscheinlichkeit bewegt sich jedoch in Regionen von 10^-9 pro Betriebsstunde. Also relativ unwahrscheinlich, aber möglich.
Je höher man reist und vor allem dann im Weltall ist die Geschichte ein vielfaches kritischer. Mit ein Grund dafür, warum die NASA noch oftmals (neben verschiedenen Redundanz-Design-Lösungen) auf alte Hardware setzt, die noch "grobe" Struktur-Größen bietet.

Ich habe mich mal ne Zeit lang beruflich mit dieser Thematik beschäftigt. Gerade in der Luftfahrt ist es interessant zu wissen, wie oft so ein Bitkipper, erzeugt durch SEU / MBUs auftreten kann und wie dann das Fehlerverhalten aussieht.

[RavenTS]

Das Problem ist wohl weniger, wie oft sich ein Computer verrechnet, sondern wie oft dies für den Endanwender von Bedeutung ist.

Der normale Anwender wird auch eher seltener mit kosmischer Strahlung zu kämpfen haben (im Gegensatz zu Luftfahrt, Raumfahrt etc.), so daß man diesen Bereich eigentlich ausklammern kann.
Wichtiger sind da schon die Betriebsbedingungen (Spannung, Temperatur) oder möglicherweise fehlerhafte Software, also nicht unbedingt hardwarebedingte Rechenfehler und deren Wahrscheinlichkeit hängt von jedem Benutzer individuell ab. Wer seinen Rechner nicht ans Limit treibt und stets nur "sichere" Software benutzt, wird kaum mal wirklich ein Problem haben.

Selbst wenn mal irgendwo ein Bit kippt, was natürlich mit zunehmender Miniaturisierung etwas wahrscheinlicher wird (aber immernoch verdammt gering ist!) hängt es eher an der Programmierung der Software. Es ist immernoch deutlich effizienter einen Schritt einfach ein zweites (oder x-tes) mal durchzuführen als die Hardware weniger störanfällig zu machen...

[Gast]

Es ist immernoch deutlich effizienter einen Schritt einfach ein zweites (oder x-tes) mal durchzuführen als die Hardware weniger störanfällig zu machen...


Man muss jetzt nur noch interpretieren können, welches von den Ergebnissen das richtige ist, oder?
Ist es denn nicht einfacher, einen Schritt dreimal zu rechnen, als eine Logik zum Interpretieren des Ergebnisses zu konstruieren?
Dreimal deswegen, weil man dann das Ergebnis als das richtige identifizieren kann, welches zweimal vorkam, da ein Rechenfehler nur sehr unwahrscheinlich 2 mal hintereinander mit gleichem Ergebnis rauskommt.

[mickii]

Es ist immernoch deutlich effizienter einen Schritt einfach ein zweites (oder x-tes) mal durchzuführen als die Hardware weniger störanfällig zu machen...Man muss jetzt nur noch interpretieren können, welches von den Ergebnissen das richtige ist, oder?
Ist es denn nicht einfacher, einen Schritt dreimal zu rechnen, als eine Logik zum Interpretieren des Ergebnisses zu konstruieren?
genau die selbe aussage wie in dem quote selbst aus meiner sicht. was willst du damit also erreichen?

[Gast]

Man muss jetzt nur noch interpretieren können, welches von den Ergebnissen das richtige ist, oder?
Ist es denn nicht einfacher, einen Schritt dreimal zu rechnen, als eine Logik zum Interpretieren des Ergebnisses zu konstruieren?
Dreimal deswegen, weil man dann das Ergebnis als das richtige identifizieren kann, welches zweimal vorkam, da ein Rechenfehler nur sehr unwahrscheinlich 2 mal hintereinander mit gleichem Ergebnis rauskommt.

Tut mir leid, wer lesen kann ist klar im Vorteil, du hast recht.