Frage von Gelbmann Stephan:Hallo,
Ich habe eine AVI-Date, von der ich dder Meinung wahr, sie sauber von
gecaptured zu haben. Vor einem Jahr war ich der Meinung, sie habe keine
Klötzchen oder sonstige Fehler. Nach einigem hin und her kopieren vauf
verschiedene Festplatten, sehe ich einige farbige Klötzchen. Kann es
sein, das durch das Kopieren, irgenwelche Bitkipper, so etwas entstehen
kann?
Gruß Stephan
Antwort von Heiko Nocon:
Gelbmann Stephan wrote:
>Kann es
>sein, das durch das Kopieren, irgenwelche Bitkipper, so etwas entstehen
>kann?
Ja, natürlich. Die Hitliste der Ursachen:
1) Fehlerhafter RAM
2) Billich-IDE-Kabel
3) Defekte Chipsätze
Antwort von Thomas Henkel:
On Thu, 30 Jun 2005 22:14:10 0200, Heiko Nocon wrote:
>>Kann es
>>sein, das durch das Kopieren, irgenwelche Bitkipper, so etwas entstehen
>>kann?
>
> Ja, natürlich. Die Hitliste der Ursachen:
>
> 1) Fehlerhafter RAM
> 2) Billich-IDE-Kabel
> 3) Defekte Chipsätze
Nein, wirklich nicht. Fehlerhafte Hardware, die Bitfehler in Dateien
erzeugt, fällt auf. Und zwar praktisch immer und praktisch sofort. Es
hängen heute mehr als genug Fehlerkontrollen und -korrekturen mit in der
"Kopierkette", um ein unbemerktes Erzeugen von Dateifehlern nahezu
auszuschließen. Es ist mir in den letzten, sagen wir mal 6-8 Jahren meines
Computerdaseins nicht ein einziges Mal mehr passiert, dass eine Datei von
oder auf eine Festplatte unbemerkt fehlerhaft kopiert wurde. Bei Disketten
mag das klappen, aber bei Festplatten? Niemals. Nicht beim kopieren.
Höchstens bei einer anschließenden Zerstörung des Datenträgers durch
Alterung, physikalische oder mechanische Einwirkungen.
Also um die Ausgangsfrage zu beantworten: Nein, natürlich nicht.
Eine AVI-Datei, die auf Festplatten umkopiert wird, auch mehrfach, ist
immer ein bitgetreues Abbild der Ursprungsdatei. Darauf darf man sich
zumindest so sehr verlassen, wie man sich darauf verlassen darf, am
nächsten Sonntag wieder keinen Sechser im Lotto zu haben.
Ich habe eine ganz andere Vermutung dafür, dass Stephan jetzt
Klötzchenbildung sieht, wo sie ihm vor Jahren nicht aufgefallen ist: Früher
hat er einen VGA-Monitor benutzt, heute ein TFT-Display. Aber selbst wenn
es heute immernoch ein Röhrenbildschirm ist, ist die Signalqualität
inzwischen deutlich besser, als vor einigen Jahren. Das Bild ist damit
deutlich schärfer und er sieht erst jetzt die Klötzchen, die vor ein paar
Jahren aber genauso da waren. Nur dass sie damals noch von der unscharfen
Anzeige "verwaschen" wurden.
Ich würde Stephan raten, sich die Videos mal auf einem Fernseher anzusehen
(;über TV-Out) und sich dann an der subjektiv viel besseren Bildqualität zu
erfreuen.
Tom
PS: Ss gäbe *prinzipiell* noch die Möglichkeit, dass er jetzt einen anderen
Codec verwendet, der beim Decodieren Klötzchen erzeugt, welche von einer
älteren Version nicht erzeugt wurden. Oder dass er bei dem jetzt
verwendeten Codec irgendwelche Post-Processing-Optionen abgestellt hat,
welche die Klötzchenbildung reduzieren sollen. Aber ganz ehrlich: Ich bin
mir trotzdem sehr sicher, dass sclicht und einfach die jetzt schärfere
Darstellung des Bildschirmes die Ursache für das Klötzchenproblem ist. Und
wie gesagt: Zumindest so sicher wie kein Sechser im Lotto sind es
jedenfalls keine Kopierfehler und Bitkipper. Da bin ich mir ganz sicher...
:-)
Antwort von Alan Tiedemann:
Thomas Henkel schrieb:
> On Thu, 30 Jun 2005 22:14:10 0200, Heiko Nocon wrote:
>> Ja, natürlich. Die Hitliste der Ursachen:
>>
>> 1) Fehlerhafter RAM
>> 2) Billich-IDE-Kabel
>> 3) Defekte Chipsätze
>
> Nein, wirklich nicht. Fehlerhafte Hardware, die Bitfehler in Dateien
> erzeugt, fällt auf. Und zwar praktisch immer und praktisch sofort.
Nein.
> Es
> hängen heute mehr als genug Fehlerkontrollen und -korrekturen mit in der
> "Kopierkette", um ein unbemerktes Erzeugen von Dateifehlern nahezu
> auszuschließen.
Nein.
> Es ist mir in den letzten, sagen wir mal 6-8 Jahren meines
> Computerdaseins nicht ein einziges Mal mehr passiert, dass eine Datei von
> oder auf eine Festplatte unbemerkt fehlerhaft kopiert wurde. Bei Disketten
> mag das klappen, aber bei Festplatten? Niemals. Nicht beim kopieren.
Oh doch. BTST.
> Höchstens bei einer anschließenden Zerstörung des Datenträgers durch
> Alterung, physikalische oder mechanische Einwirkungen.
Nein.
VIA-Chipsatz-Bugs sind bekannt genug, und beim Kopieren auf CDs und DVDs
kommt es sowieso öfter als einem lieb sein kann zu derartigen
Katastrophen. Festplatten sind aber nicht ausgenommen.
Und kaputtes RAM kann Dateien beim Kopieren schneller zerstören als Du
"huch" sagen kannst. Mitbekommen tut man das *definitiv* nicht. BTST.
> Also um die Ausgangsfrage zu beantworten: Nein, natürlich nicht.
Aber selbstverfreilich.
> Eine AVI-Datei, die auf Festplatten umkopiert wird, auch mehrfach, ist
> immer ein bitgetreues Abbild der Ursprungsdatei.
Nicht unbedingt.
> Darauf darf man sich
> zumindest so sehr verlassen, wie man sich darauf verlassen darf, am
> nächsten Sonntag wieder keinen Sechser im Lotto zu haben.
*rofl* Die Wahrscheinlichkeit eines Bitkippers durch kaputtes RAM oder
kaputte Kabel oder kaputte Controller oder fehlerhafte Treiber oder
Viren oder oder oder ist definitiv *deutlich* größer als vier Richtige
im Lotto. Ohne Zusatzzahl.
> Ich habe eine ganz andere Vermutung dafür, dass Stephan jetzt
> Klötzchenbildung sieht, wo sie ihm vor Jahren nicht aufgefallen ist: Früher
> hat er einen VGA-Monitor benutzt, heute ein TFT-Display.
Äh... Nein. Dann muß er schon einen ziemlichen Matschmonitor gehabt
haben. An TFTs treten ganz andere "Merkwürdigkeiten" auf, bspw. mit
Schleiern überlagerte Bewegungen, absaufendes Schwarz, ruckelnde
Wiedergabe o.ä.
> Aber selbst wenn
> es heute immernoch ein Röhrenbildschirm ist, ist die Signalqualität
> inzwischen deutlich besser, als vor einigen Jahren. Das Bild ist damit
> deutlich schärfer und er sieht erst jetzt die Klötzchen, die vor ein paar
> Jahren aber genauso da waren. Nur dass sie damals noch von der unscharfen
> Anzeige "verwaschen" wurden.
Also schon mein guter alter NEC MultiSync 3D hatte ein so scharfes Bild,
daß Klötzchen in AVIs aufgefallen sind.
Die Unterschiede, die Du hier herbeireden möchtest, sind höchstens beim
Wechsel von einem handelsüblichen PAL-Fernseher zu einem TFT oder
PC-Monitor zu beobachten.
> Ich würde Stephan raten, sich die Videos mal auf einem Fernseher anzusehen
> (;über TV-Out) und sich dann an der subjektiv viel besseren Bildqualität zu
> erfreuen.
Ja, durch den eingebauten Hardware-Weichzeichner. "Besser" würde ich das
aber nicht nennen.
> Und
> wie gesagt: Zumindest so sicher wie kein Sechser im Lotto sind es
> jedenfalls keine Kopierfehler und Bitkipper. Da bin ich mir ganz sicher...
> :-)
Deiner Logik zufolge müßte ich in meinem Leben schon mindestens zehnmal
sechs Richtige im Lotto gehabt haben. Mit Zusatzzahl.
Gruß,
Alan
--
Bitte nur in die Newsgroup antworten! Re:-Mails rufe ich nur selten ab.
http://www.schwinde.de/webdesign/ ~ http://www.schwinde.de/cdr-info/
Mail: at 0815
hotmailcom ~ news-2003-10schwindede
Antwort von Alexander Noe":
Thomas Henkel wrote:
>>Ja, natürlich. Die Hitliste der Ursachen:
>>
>>1) Fehlerhafter RAM
>>2) Billich-IDE-Kabel
>>3) Defekte Chipsätze
>
>
> Nein, wirklich nicht. Fehlerhafte Hardware, die Bitfehler in Dateien
> erzeugt, fällt auf. Und zwar praktisch immer und praktisch sofort.
Ja, z.B. durch BSODs...
> Es
> hängen heute mehr als genug Fehlerkontrollen und -korrekturen mit in der
> "Kopierkette", um ein unbemerktes Erzeugen von Dateifehlern nahezu
> auszuschließen.
Wie denn das? Wenn die Daten im RAM verändert werden, stimmen doch alle
Prüfsummen, denn die werden gebildet über die zu sendenden Daten (;zu senden
von der Festplatte oder vom RAM aus), aber es wird nicht nach dem Schreiben
verglichen, ob die geschriebenen Daten identisch zu den ursprünglich
gelesenen sind, es sei denn, man kopiert mit xcopy /v
> Es ist mir in den letzten, sagen wir mal 6-8 Jahren meines
> Computerdaseins nicht ein einziges Mal mehr passiert, dass eine Datei von
> oder auf eine Festplatte unbemerkt fehlerhaft kopiert wurde.
Mir schon.
MfG
Alexander
Antwort von Heiko Nocon:
Thomas Henkel wrote:
>Nein, wirklich nicht. Fehlerhafte Hardware, die Bitfehler in Dateien
>erzeugt, fällt auf. Und zwar praktisch immer und praktisch sofort.
Nein. Das fällt, gerade bei Platten, die nur als reine Datenhalde
verwendet werden, i.d.R. erst dadurch auf, daß bestimmte Dateitypen, die
durch zusätzliche Prüfsummen geschützt sind (;z.B. Archivformate wie Zip)
beim Öffnen plötzlich CRC-Fehler anzeigen.
>Es
>hängen heute mehr als genug Fehlerkontrollen und -korrekturen mit in der
>"Kopierkette", um ein unbemerktes Erzeugen von Dateifehlern nahezu
>auszuschließen.
So ein Unsinn. Die einzige Fehlerkontrolle beim Schreiben findet
zwischen Controller und Platte statt und das auch nur dann, wenn die
Platte im DMA-Modus betrieben wird.
Gegen Fehler im RAM ist diese Prüfung prinzipbedingt völlig hilflos und
gegen Fehler im Controller zumindest zum Teil ebenfalls.
Sie schützt dann nämlich nur bereits defekte Daten und stellt sicher,
daß sie genau so defekt, wie sie sind, auf der Platte landen.
Schönes Beispiel ist das Verhalten beim ziemlich bekannten Bug der
Southbridge des VIA KT133A.
Noch nie was von gehört? Das zeigt dann wohl hinreichend, daß es mit
deinen Erfahrungen und deinem Wissen beim Thema PC-Hardware nicht sehr
weit her sein kann...
Antwort von Gernot Zander:
Hi,
in de.comp.tv video Thomas Henkel wrote:
>> Ja, natürlich. Die Hitliste der Ursachen:
>>
>> 1) Fehlerhafter RAM
>> 2) Billich-IDE-Kabel
>> 3) Defekte Chipsätze
> Nein, wirklich nicht. Fehlerhafte Hardware, die Bitfehler in Dateien
> erzeugt, fällt auf. Und zwar praktisch immer und praktisch sofort. Es
Nein, leider. Habe das gerade durch.
Vor ein paar Jahre ein Via-Chipsatz, der immer wieder Bitfehler
produziert hat, so in der Größenordnung 1 pro GB. Bemerkt
durch Neros Verify, als da ein DVD-Brenner reinkam. (;Via Apolle Pro.)
Dann IDE-Kabel, das zum DVD-Brenner fehlerhafte Daten geschickt
hat. Dto. bemerkt durch Neros Verify.
Und in den letzten Tagen RAM, die ersten 512 MB OK, der zweite
Riegel lief in dem Board nicht richtig. Ergebnis auch so ca.
2-3 Fehler auf 9 GB. Bemerkt durch die Behauptung eines Install-
Programms "Geschriebene Datei weicht von CAB-Datei ab" (;da war
der Riegel schon 1 Woche in Betrieb), dann mittels Prüfsummen-
programms in stundenlangen Tests eingegrenzt (;Rechner lief
sonst völlig einwandfrei). Weder Memtest noch Microsofts
Speichertest noch Prime95 haben den Speicher für fehlerhaft
befunden, Austausch von Netzteil und IDE-Kabel änderte nix,
nach dem Ausbau des 2. Riegels jedoch wieder einwandfreie
Kopien. Bloß gut, dass ich das früh bemerkt habe - aber von
"praktisch sofort" kann keine Rede sein.
mfg.
Gernot
--
(;Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Die Ehe ist eine wunderbare Einrichtung, die zwei Menschen befaehigt,
gemeinsam Schwierigkeiten zu ertragen, die sie nie gehabt haetten,
wenn sie einander nicht geheiratet haetten. (;Lucky Luke)
Antwort von Gernot Zander:
Hi,
in de.comp.tv video Heiko Nocon wrote:
> Schönes Beispiel ist das Verhalten beim ziemlich bekannten Bug der
> Southbridge des VIA KT133A.
Davon kann ich ein sehr langes und elendes Lied singen.
Zum Glück hat das Board dann irgendwan seinen EPROM ver-
loren, so dass er sich nicht mehr neu flashen ließ, und
hat mich vor weiteren Heilungsversuchen bewahrt (;und
lässt mich um Via-Chipsätze einen weiten Bogen machen).
Zum Glück prüfe ich jede gebrannte CD und alle kopierten
wichtigen Daten paranoiderweise mit CRC-Programmen extra
nochmal, so dass ich nix verloren habe.
mfg.
Gernot
--
(;Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Wer fähig Ist Sätze zu tippen, der ist auch fähig Schreibfehler zu
machen. Manche gehen jedoch weit über Ihre Fähigkeiten hinaus.
(;WoKo)
Antwort von Andre Beck:
Heiko Nocon writes:
> Thomas Henkel wrote:
>
>>Nein, wirklich nicht. Fehlerhafte Hardware, die Bitfehler in Dateien
>>erzeugt, fällt auf. Und zwar praktisch immer und praktisch sofort.
>
> Nein. Das fällt, gerade bei Platten, die nur als reine Datenhalde
> verwendet werden, i.d.R. erst dadurch auf, daß bestimmte Dateitypen, die
> durch zusätzliche Prüfsummen geschützt sind (;z.B. Archivformate wie Zip)
> beim Öffnen plötzlich CRC-Fehler anzeigen.
Ich habe "dank" eines üblen (;mittlerweile auch mir) bekannten Fehlers
in Win2k (;ohne SP4 *plus* einem Registry-Hack adressiert es Festplatten
prinzipiell Modulo 128GiB) praktisch ein Jahr lang Daten an vollkommen
andere Stellen der Platte geschrieben, als die vorgesehenen. Das fiel
nicht so schnell auf, weil heutige Platten riesige Datenwüsten sind,
und wenn man da auch noch -zig GiB Videodateien rumgammeln hat, die man
nicht anfasst, dann ist da unglaublich viel Platz, wo was geschrieben
werden kann ohne dass es lethale Folgen hat. Dann tauchten irgendwann
gröbere Fehler bei fsck auf, dann verschwand ein File aus dem Kernel-
Sourcetree, und das fiel dann endlich auf, als ich den mal wieder kom-
pilieren wollte. Das nur mal als Beispiel, wenn auch nicht für einen
Hardwarefehler, so doch dafür, dass auch größere Datenzerstörungen
(;ich habe u.a. mehrere Spiele im Umfang von insgesamt sicher 5GiB
installiert und wieder entfernt, also diese Menge an Daten in einer
anderen Partition überschrieben) nicht wirklich auffallen müssen.
Apropos Lotto: Wie hoch war gleich die Wahrscheinlichkeit eines 6ers
mit Zusatzzahl? Eins zu 14 Millionen? 14 Millionen *Bit* sind lächer-
lich wenig (;es sind ca. 2 bis 3 Sekunden DVD-Video) auf einer 160GB-
Platte, und das ist das tiefere Problem: Wenn es Dateien zerbröselt,
dann ist die Wahrscheinlichkeit, dass es elementare Sachen erwischt,
die man bemerkt, verflucht gering, weil die elementaren Sachen eher
klein sind. Es erwischt, wenn nicht wie in meinem Fall große Teile des
free space eines anderen Filesystems, halt zuerst die superfett aufge-
blähten Medienfiles, die den meisten Platz verkleistern. Und das fällt
dann irgendwann Jahre später auf, wenn man mal wieder reinguckt.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Christian Schroeder:
Alan Tiedemann schrieb:
> Thomas Henkel schrieb:
>>Ich habe eine ganz andere Vermutung dafür, dass Stephan jetzt
>>Klötzchenbildung sieht, wo sie ihm vor Jahren nicht aufgefallen ist: Früher
>>hat er einen VGA-Monitor benutzt, heute ein TFT-Display.
>
>
> Äh... Nein. Dann muß er schon einen ziemlichen Matschmonitor gehabt
> haben. An TFTs treten ganz andere "Merkwürdigkeiten" auf, bspw. mit
> Schleiern überlagerte Bewegungen, absaufendes Schwarz, ruckelnde
> Wiedergabe o.ä.
Hm, das habe ich bei mir auch beobachtet. Ich hab die über
Kabelfernsehen empfangenen Sendungen mit WinDVR und hoher Datenrate
aufgezeichnet und dann mit DivX eingedampft, bis die Qualität subjektiv
meinen Ansprüchen genügte. (;Hab damals verschiedene Raten ausprobiert).
Auf meinem Samtron 96p 19" Monitor sah das gut aus. Als ich mir dann
später ein Toshiba M30 Laptop gekauft hatte, sah ich diese Klötzchen im
Display. Dass der Röhrenmonitor schlecht ist, glaub ich nich, die Tests
damals bescheinigten dem ein scharfes Bild und das hat sich subjektiv
auch bestätigt. Naja, wenn man nah genug ran geht, sieht man die
Klötzchen da auch, aber auf nen halben Meter Entfernung eben nicht.
Zu den Bitfehlern: Die können leider auftreten, aber die
Bildschirmursache halte ich in diesem Fall für wahrscheinlicher.
--
Gruß Chris
Wir müssen uns Sisyphos als glücklichen Menschen vorstellen!
Antwort von Roland Schweiger:
> Ja, natürlich. Die Hitliste der Ursachen:
>
> 1) Fehlerhafter RAM
> 2) Billich-IDE-Kabel
> 3) Defekte Chipsätze
versteh ich eigentlich nicht :
Beim Kopieren dachte ich immer, gibts div. Prüfsummen und ähnliches,
Cyclic Redundancy Check (;CRC) und co.
Wird einfach weiterkopiert wenns Bit-Fehler gibt?
lg
Roland Schweiger
Antwort von Roland Schweiger:
> Schönes Beispiel ist das Verhalten beim ziemlich bekannten Bug der
> Southbridge des VIA KT133A.
Was ich aber dennoch nicht verstehe :
Wenn in einer Videodatei ein Bitfehler auftritt, mag das ja relativ
unbedeutend sein.
Was aber, wenn eine gängige .EXE Datei oft in Gebrauch ist (;sagen wir mal
word.exe)
Wenn das Programm (;zumindest teilw.) in Maschinensprache ist,
so kann doch ein einziges falsches Bit einen ganz anderen Befehl als gewollt
an den Prozessor schicken,
somit könnte im ungünstigen Fall ein falsches Bit das ganze word zum Absturz
bringen...
Weshalb aber passiert das so gut wie nie, obwohl es doch tatsächlich am und
an mal auch heutzutage noch Bitfehler gibt?
lg
Roland Schweiger
Antwort von Alan Tiedemann:
Roland Schweiger schrieb:
>> Ja, natürlich. Die Hitliste der Ursachen:
>>
>> 1) Fehlerhafter RAM
>> 2) Billich-IDE-Kabel
>> 3) Defekte Chipsätze
>
> versteh ich eigentlich nicht :
> Beim Kopieren dachte ich immer, gibts div. Prüfsummen und ähnliches,
> Cyclic Redundancy Check (;CRC) und co.
Auf dem Kabel. Sonst nirgends.
> Wird einfach weiterkopiert wenns Bit-Fehler gibt?
Klar. Oder machst Du nach jedem Kopiervorgang händisch ein Verify mit
bspw. "fc" oder "fcb"? Sicher nicht.
Bei einem Verschiebe-Vorgang gibt es prinzipbedingt gar keine
Möglichkeit der Überprüfung. Bevor Du zum Überprüfen kommst, ist das
Original ja schon weg.
Gruß,
Alan
--
Bitte nur in die Newsgroup antworten! Re:-Mails rufe ich nur selten ab.
http://www.schwinde.de/webdesign/ ~ http://www.schwinde.de/cdr-info/
Mail: at 0815hotmailcom ~ news-2003-10schwindede
Antwort von Gernot Zander:
Hi,
in de.comp.tv video Roland Schweiger wrote:
>> Ja, natürlich. Die Hitliste der Ursachen:
>>
>> 1) Fehlerhafter RAM
>> 2) Billich-IDE-Kabel
>> 3) Defekte Chipsätze
> versteh ich eigentlich nicht :
> Beim Kopieren dachte ich immer, gibts div. Prüfsummen und ähnliches,
> Cyclic Redundancy Check (;CRC) und co.
> Wird einfach weiterkopiert wenns Bit-Fehler gibt?
Teilweise.
SCSI hat Parity. Folge eines Fehlers ist ein Bus-Reset, was
man bei Festplatten an einer 10-s-Kunstpause merkt, bei CD-
LW am Selbsttest (;und Brennabbruch).
UDMA-IDE (;ab > UDMA2, glaube ich [die meisten Brenner machen
aber nur UDMA2, also ohne!]) hat CRC. Win schaltet bei
Fehlern den UDMA-Modus automatisch schrittweise zurück.
RAM gibts mit ECC, aber viele Boards unterstützen es nicht.
Daraus folgt: Bei HDD mit sagen wir UDMA5 fallen Fehler durch
das Kabel umgehend auf, wenn man in der Systemsteuerung nach-
sieht, welchen Modus er benutzt (;sonst auch nicht). Bei
Brennern mit <%UDMA2 dagegen nicht, da merkt man es erst
beim Vergleichen der Daten.
Da die Daten im RAM zwischengelagert werden, fallen RAM-
Fehler nur bei ECC umgehend auf, vor allem seltene Fehler
(;also wie ich es erlebt habe, 1 Bit auf 10 GB im Durchschnitt,
und wenn das auch nur eine bestimmte Speicherzelle ist) dagegen
kaum bis gar nicht.
Ganz übel (;hatte ich auch mal): Beim Transport zwischen Cache
und RAM. Dagegen hilft weder ECC noch sonstwas:-(;
mfg.
Gernot
--
(;Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Der Geldraum - unendliche Pleiten. Dies sind die Abenteuer des
Finanzministers Naseweis, der auf einem Schuldenberg sitzt, den
nie ein Mensch zuvor gesehen hat. (;Randolf Boes )
Antwort von Frank Derlin:
"Roland Schweiger" schrieb...
[snip]
> Weshalb aber passiert das so gut wie nie, obwohl es doch tatsächlich am und
> an mal auch heutzutage noch Bitfehler gibt?
Versuche bei den Überlegungen mit einzubeziehen, das das "Problem"
sporadisch auftritt und/oder nur bei hoher Busbelasung, wie es
bei Video - insbesondere Videoaufnahmen von analogen Quellen -
auftritt. Das bisle Laden von diversen EXE-DLL-Dateien, wovon die
Hälfte davon eh schon gecached sind, ist dagegen nur ein unhörbarer
Ansatz eines versuchten Luftholens.
BTW, wir hatten hier auch schon mal eine defekte CPU. Die tat nur
bei ausgewählter Decompression seltsame Dinge, iirc.
Gruß, Frank
Antwort von Gernot Zander:
Hi,
in de.comp.tv video Roland Schweiger wrote:
>> Schönes Beispiel ist das Verhalten beim ziemlich bekannten Bug der
>> Southbridge des VIA KT133A.
> Was ich aber dennoch nicht verstehe :
> Wenn in einer Videodatei ein Bitfehler auftritt, mag das ja relativ
> unbedeutend sein.
> Was aber, wenn eine gängige .EXE Datei oft in Gebrauch ist (;sagen wir mal
> word.exe)
> Wenn das Programm (;zumindest teilw.) in Maschinensprache ist,
> so kann doch ein einziges falsches Bit einen ganz anderen Befehl als gewollt
> an den Prozessor schicken,
> somit könnte im ungünstigen Fall ein falsches Bit das ganze word zum Absturz
> bringen...
> Weshalb aber passiert das so gut wie nie, obwohl es doch tatsächlich am und
> an mal auch heutzutage noch Bitfehler gibt?
Zum einen passiert es oft genug, dass Programme abschmieren (;"Allgemeine
Schutzverletzung..."), zum anderen musst du wie folgt rechnen:
Von den sagen wir 512 MB RAM kippt im Schnitt ein Bit.
Die Word.exe ist aber nur 20 MB, sagen wir, die DLLs nochmal 30 MB,
d.h. der Code zusammen 50 MB (;das ist schon sehr großzügig
gerechnet!). Das bringt das Risiko auf 1/10. Jetzt musst du im
Programm die gekippte Stelle auch noch treffen. Word hat sagen
wir mal 500 Funktionen, von denen du aber im Normalfall nur
20 benutzt und überhaupt nur 50 kennst. Das reduziert das Risiko
nochmal auf 1/10. Und dann muss der Fehler auch noch zu einem
Absturz führen, denn wie du oben schreibst, nur im ungünstigen
Fall führt das zum Absturz (;wenn z.B. eine Sprungadresse falsch
wird), handelt es sich um ein harmloses Daten-Byte, sowas wie
die Voreinstellung auf "1" bei der Seitenzahl zum Drucken z.B.,
oder eine Addition statt Subtraktion, führt das nicht zum
Absturz, sondern nur zu falschem Verhalten. Sagen wir mal, das
Risiko liegt hier bei 50%.
---> nur in 1 von 200 Fällen bringt der eine RAM-Fehler Word zum
Absturz. Ich tippe, es stürzt viel öfter durch andere
Programmierer-Fehler ab...
Und - was andere schon ganz richtig geschrieben haben - bei
Video-Verarbeitung ist das Verhältnis Daten vs. Programm
noch krasser, mehrere GB Daten stehen 1-2 MB Programm gegen-
über.
Anders sieht es aus, wenn der RAM einen Bitfehler an einer
festen Stelle hat, die immer wieder z.B. für den System-Stack
benutzt wird. Dann ist das ganze System instabil.
Dass Daten unterwegs öfter beschädigt werden, schließe ich
übrigens auch aus vielen Artikeln "beschädigte MP3s reparieren"
oder "Knackser in MP3s" oder so - denn auch sind ja nach dem
Encoden theoretisch erst mal einwandfrei. Offensichtlich ist
dann der Weg wie z.B. Ripper, Encoder, Newsgroup, 8x durch
die Tauschbörse*), dann Festplatte so fehlerbehaftet, dass
Fehler keine Seltenheit sind...
*) Auch tcp verwendet einen CRC, aber bei nur genügend großen
Datenmengen reicht selbst das nicht, auch CRC hat nur eine
endliche Sicherheit...
mfg.
Gernot
--
(;Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
Die HP 1536er brennen ab wie Waldgebiete bei Trockenheit. (;Thomas Dettmar)
Antwort von Roland Schweiger:
Ja, schon seltsam dass es immer noch nicht gelingt Datenfehler
auszuschliessen.
CPU Fehler durch (;wahrscheinlich) Überhitzung hatte ich auch schon :
Eing P4 mit 3 GHz und HT (;Northwood) auf einem ASUS P4P800 und wenn man dort
Prime95 laufen ließ,
wurden immer wieder Fehler gemeldet, war offenbar die FPU betroffen -
bessere Kühlung hatte das Problem tatsächlich gelöst.
Aber bei Festplatten mit NTFS und evtl. dynamic volumes dachte ich bislang
dass es wirklich nur selten zu Bitfehlern kommen würde
weil ich dachte die Platten hätten selbst auch noch Fehlerkorrektur.
Schon immer interessant zu lesen daß man da eben nicht so sicher sein
darf...
lg
Roland Schweiger
Antwort von Andre Beck:
"Roland Schweiger" writes:
>
> Ja, schon seltsam dass es immer noch nicht gelingt Datenfehler
> auszuschliessen.
Natürlich gelingt das - bei Systemen, die dafür entsprechend ausgestattet
sind. Also logischerweise nicht im gnadenlosem Preiskampf unterworfenen,
von Bananensoftware überschwemmten und mit M$ (;und vor allem den Folge-
erscheinungen des Monopols) gestraften Enduser-PC-Markt. Aber bereits im
PC-Server-Markt gibt man sich viel mehr Mühe, adäquate Kühlung (;die dann
leider einen eigenen Raum braucht), RAM mit ECC/Chipkill, SCSI/FW Storage
mit RAID, wirklich ausgereifte Chipsätze, weitere Redundanzen auf verschie-
denen Ebenen etc. Kostet aber halt Geld.
> Aber bei Festplatten mit NTFS und evtl. dynamic volumes dachte ich bislang
> dass es wirklich nur selten zu Bitfehlern kommen würde
Das Filesystem und/oder ein Logical Volume Management hat wenig Einfluss
auf Daten, die bereits fehlerhaft vom OS geschrieben werden, weil CPU
oder Speicher was zerbröselt haben. Eigentlich gar keinen, wenn wir mal
von Fehlern absehen, die auf Datenverlust durch Crash/Power loss beruhen.
Hier geht es dann eher darum, die Metadaten konsistent zu halten und
Folgekatastrophen zu vermeiden, weil ein zertrümmertes Antik-FS beim
stundenlangen fsck massenweise eigentlich noch intakte Reste von sich
selbst lieber entsorgt.
> weil ich dachte die Platten hätten selbst auch noch Fehlerkorrektur.
Sicher, die sitzt zwischen Schreibpuffer und Oberfläche, stellt also
sicher, dass ein Sektor genau so gelesen wird, wie er geschrieben wurde,
oder aber als nicht mehr nutzbar erkannt wird. Hilft also nur gegen das
Umkippen von Bits auf dem Medium selbst, bereits umgekippte Bits ver-
teidigt es hingegen mit Zähnen und Klauen.
> Schon immer interessant zu lesen daß man da eben nicht so sicher sein
> darf...
Es gab da mal so 'ne Rolle mit den 50 wichtigsten Gesetzen aus dem
Umfeld von Murphy's Law. Hing früher in jeder EDV-Abteilung. Gleich
neben der Idiotenharfe (;aka Abakus) im roten Holzkasten mit der Glas-
scheibe, dem Hämmerchen und der Aufschrift "Für Notfälle". Nur weil
das Zeug jetzt überall unter Schreibtischen Staub saugt haben sich
die Randbedingungen nicht grundlegend geändert, schon weil die all-
gemeine Verbesserung der Stabilität immer im Hase-Igel-Rennen mit
Moore's Law ist. Dazu kommt die Verbreitung, die schon allein wegen
der Statistik auch die abartigsten Fehler irgendwo manifestieren lässt.
An ungünstigen Orten durchaus auch mal kosmische Strahlen...
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
