nForce 4 gleiche Probleme wie KT133A??? Binärfehler!!!

- OCinside.de PC Forum
https://www.ocinside.de

-- Hardware
https://www.forum-inside.de/forums.cgi?forum=4

--- nForce 4 gleiche Probleme wie KT133A??? Binärfehler!!!
https://www.forum-inside.de/topic.cgi?forum=4&topic=14970

Ein Ausdruck des Beitrags mit 12 Antworten ergibt bei 3 Antworten pro Seite ca. 4 DIN A4 Seiten. Das entspricht bei 80 g/m² ca. 19.96 Gramm Papier.


-- Veröffentlicht durch Gibtnix am 11:26 am 4. Dez. 2005

mal ein anderer Ansatz woher das Problem kommen könnte; so wie ich dich verstehe benutzt du SATA-HDDs und gleichzeitig einen Referenztakt von 235 MHz? Die SATA-Ports 1+2 sollen beim Übertakten teilweise Probs machen, da der Controller nciht ganz korekt gefixt wird. Behoben kann dieses Problem durch verwenden von Port 3+4.

Dagegen dass es an einem zu scharfenRam-Timing lag spricht dass weder Memtest noch Prime angeschlagen haben - dadurch wird das System so stark ausgelastet, dass bei einem zu scharfen Timing eigentlich Fehler auftreten müssten...


-- Veröffentlicht durch mulle78 am 10:35 am 4. Dez. 2005

Übertakter aufgepasst:

Den Fehler konnte ich bei Corsair unterbinden, indem ich alle Spezifikationen eingehalten habe.... der MDT ist eingebaut und der Test bei Standardtakt ist zufriedenstellend verlaufen, keine Fehler bei 4000 (2x2000) kopierten Dateien (SATA HDD auf sich selbst und von IDE auf eine andere IDE, bei der ich vorher die Fehler hatte)

jetzt gehts wieder ans Übertakten und das alles mit MDT, statt Corsair. Ich habe eben mal den Speicher wieder auf DDR333 (166MHz) gestellt und den Referenztakt auf 235 MHz um die alten Einstellungen zu fahren. Dabei habe ich den Bluescreen PFN_LIST_CORRUPT erhalten, der ebenfalls auf Speicherprobleme hindeutet. Da der MDT Speicher ein sauberes SPD hat und dort auch Werde für DDR333 stehen, habe ich nicht nur die über CPUZ angezeigten Werte Tcl, Trc, Trcd und Tras fix gestellt, sonder mir ist aufgefallen, dass laut A64Tweaker auch die Werte Trfc und Read Preamble nicht wie vor bei DDR400 (200MHz) liefen.

Nun habe ich einfach mal alle Einstellungen so wieder eingestellt für das übertaktete System, dass ich alle Werte (Spannung, Speicher, HTT Multi) angepasst habe, ausser den Referenztakt. Nun läuften Trfc mit 14 Takten fix, wie bei DDR400, statt 12 wie bei DDR333 AUTO und Read Preamble mit 5,5ns fix wie bei DDR400 statt 6,5ns bei DDR333 automatisch eingestellt (wobei ich mich hier wundere, dass der Wert bei langsamer getaktetem Speicher höher ausfällt, also eine höhere Latenz angegeben ist).

Ich bin mir nicht sicher, ob ich das damals beim Übertakten des Corsair berücksichtigt hatte, denn auch diesen musste ich mit DDR333 fahren, damit er beim Übertakten nicht über 200 MHz lief. Jetzt kann ich die Trfc und Read Preamble Werte nicht mehr vergleichen, da schon ausgebaut.

lasse ich jetzt Clockgen über Windows laufen, verrechnet sich die CPU laut Prime erste bei ca. 2,5 GHz statt 2,0 GHz Default.

[EDIT]
Bei mir im BIOS wird der Read Preamble Wert anderes ausgelesen/angegeben, wie von A64Tweaker interpretiert. Musste den Wert im BIOS auf 5,0 ns stellen, damit er wie bei der automatischen Einstellung vom BIOS bei DDR400, in A64Tweaker mit 5,5 ns angezeigt wird. Mit dem korrekten Read Preamble Wert und dem korrekten Trfc Wert fuhr er jetzt auch mit einem Referenztakt von 235 MHz hoch und das bei DDR333 Einstellung.

Ein Schnelltest mit Windows Software ließ bei DDR333 die CPU bis 2,52 GHz und RAM bis 209 MHz zu und bei DDR366 (183MHz) bis 2,48GHz und RAM bis 226 MHz. Ich denke da sollten 2,35 GHz und DDR333 im Ramen sein, also CPU 2,35 GHz und RAM 195 MHz. Oder was meint ihr?[/EDIT]

[EDIT2]
So Jungens und Mädels, ich kann jetzt wieder beruhigt schlafen.

Der Rechner lief jetzt sauber 24 Stunden durch. Prime95 hat keine Fehler gemacht und die Platten auch nicht. Von IDE1 auf IDE 2 4501 Kopieen ohne Fehler und auf der SATA Platte 3731 Kopieen ohne Fehler. Und das bei Athlon64 3200+@2350 MHz; RAM 195MHz@DDR333 mit gefixten Timings und Spannung auf der CPU bei 113% (1,54 Volt). Eventuell versuch ich die CPU noch etwas zu entlasten, indem ich die Spannung etwas senke.

Wenn es nicht am Speicher lag, dann lag es wohl am Trfc und Read Preamble Wert, die durch AUTO Einstellung über das BIOS zu scharf eingestellt waren, denn der Speicher lief auf DDR333, aber mit Taktraten von DDR400.

Obwohl, ich meine mich zu erinnern, dass ich beim Corsair einen Fehler bei Defaulttakt hatte.... von etlichen Versuchen, aber einen Fehler. Der MDT läuft bei mir jetzt jedenfalls einwandfrei.
[/EDIT2]


-- Veröffentlicht durch mulle78 am 14:01 am 25. Nov. 2005

also der RAM ist "NONAME".... eigentlich Corsair zwei mal 512 MB CL2,5 DDR400

habe jetzt mal auf DDR333 getaktet und siehe da, deutlich weniger Fehler, aber nicht Fehlerfrei:

HD1 160GB 450 Kopien ohne Fehler
HD2 250 GB 911 Kopien und troz runtergetaktetem Speicher ein Fehler
00EF65AA: 2E 26

Da die Feherrate statistisch so drastisch gesunken ist, ist ja schon mal ein Lichtblick. Was meint ihr... ist das nun ein Chipsatzproblem oder ein Speicherproblem... ob ich mal auf Single Chanel umstelle?

Aber allgemein muss ja der Chipsatz ein Problem haben, gibt ja doch par Threads über das Thema im i-Net. Gerade weil er auf der langsameren Systemplatte nicht so häufig aufgefallen ist und die Installation bei mir quasi steht und höchstens beim Defragmentieren Daten verschoben oder kopiert werden, ist mir das alles erst jetzt aufgefallen.


-- Veröffentlicht durch mulle78 am 16:34 am 24. Nov. 2005

Kopieen von HD 2 auf sich selbst am sekundären IDE Controller ebenfalls fehlerhaft:

990 Kopiervorgänge und 5 Fehler

0111AC3A: FF F7
037B95AA: 28 20
072D55AA: 88 80
07ED85AA: 4E 46
0C24E5AA: FF F7


-- Veröffentlicht durch Marauder25 am 14:38 am 24. Nov. 2005

Ja das wäre ne Möglichkeit.

Ich erinner mich zwar an etwas, aber kann auch unwichtig sein.
Als ich mir meinen Athlon XP 2400+ gekauft habe damals, habe ich ihn zuerst auf einem Epox Board gehabt, da dieses aber beim kopieren auch andauernd Datenfehler produziert hat, bzw. auch einige Abstürze im Betrieb, hab ich es durch ein Gigabyte Board ersetzt.
Damals war das Problem mit dem Chipsatz 686B so massiv, das ganze Serien wieder zurückgerufen werden mussten.

Vielleicht wenn alle Stricke reissen, mal das Board tauschen.
Evtl. liegt wirklich ein Defekt am Board bzw. an der North/Southbridge vor.

Mike


-- Veröffentlicht durch mulle78 am 13:49 am 24. Nov. 2005

ja ich benutze Rundkabel. Die waren bis dato mit den Platten auf meinem A7S333 im Einsatz und dort gab es defenitiv keine Fehler, weil dies das Nachvolgesystem des KT133A war und ich dort den Test bei Einführung mit dem Kopieren und Vergleichen gemacht habe.

Ich habe aber vor, die Kabel durch andere zu ersetzen, die beim Maimboard origianl dbei waren.

(Geändert von mulle78 um 13:49 am Nov. 24, 2005)


-- Veröffentlicht durch Marauder25 am 12:56 am 24. Nov. 2005

Du benutzt wahrscheinlich IDE Rundkabel, oder?

Dieser Fehler kann dort nämlich auftreten, wenn die Adern "unsauber" aufgeteilt wurden. Tausch doch mal das Kabel gegen ein Standard Flachband Kabel aus.

Mike


-- Veröffentlicht durch mulle78 am 10:30 am 24. Nov. 2005

den RAM hab ich mal mit memtest86 über Nacht geprüft und 0 Fehler... wie aussagekräftig das auch immer ist.

Netzteilprobleme möchte ich auch ausschließen, da die Spannungen laut BIOS und MBM im Ramen sind. Auch habe ich keine Anzeichen für zu schwache Spannungsversorgung bemerkt.

Zur Zeit teste ich das Kopieren auf einem Kanal, also auf die gleiche Platte ... vielleicht passiert es ja nur, wenn ich von Kanal a auf b kopiere...

Ferner bekomme ich nächste Woche meine erste SATA Platte... mal sehen wie sie sich verhält in dem System und von SATA auf IDE kopieren, was dabei raus kommt.


-- Veröffentlicht durch hax0r am 9:10 am 24. Nov. 2005


Zitat von X1ALPHA um 8:26 am Nov. 24, 2005
Ram "im Arsch"!




Im Betrieb sind mir keine Stabilitätsprobleme aufgefallen. Prime95 rechnete nach meinem Übertakten Nächtelang ohne Fehler.


Ich schätze mal, wenn der RAM nen Knacks hätte, wären deutlich mehr Fehler zu sehen als 4 Bitfehler bei ~1300 Kopiervorgängen.

Haste mal Kabel, Festplatten, evtl. auch NT geprüft?


-- Veröffentlicht durch X1ALPHA am 8:26 am 24. Nov. 2005

Ram "im Arsch"!


-- Veröffentlicht durch mulle78 am 8:02 am 24. Nov. 2005

da haben wir es, auch bei Standardtakt Bitfehler:

02FB55AA: 0A 02


-- Veröffentlicht durch mulle78 am 7:18 am 24. Nov. 2005

Hallo @all,

ich habe ein Problem mit meinem DFI LanParty Ultra, mit dem nForce 4 Chipsatz, für den Sockel 939. Manchmal sind beim Datensichern mit Nero nach dem Check Bitfehler auf den Medien aufgefallen, was ich aber noch auf die Medien selbst geschoben hatte. Der Fehler kam selten vor und betraf zum Glück bisher nur private Fotos die sich nach dem Brennen trotzdem weiterhin öffnen ließen. Bei Medien mit anderen Inhalten habe ich diese weggeworfen, neu gebrannt und dann trat der Fehler nicht mehr auf. Er erschien also nicht repoduzierbar.

Nun bin ich dazu übergegangen, die Daten vorher schon per Software in ein ISO-File zu packen und dieses später zu brennen. Die ISO-Files habe ich vorher entpackt, um die Daten mit der Software Filesync 2.18 binär zu vergleichen. Und tatsächlich, bei großen Dateien traten vereinzelt Bitfehler auf. Die Daten gingen bei dem Test immer von einer HDD auf eine andere. Zu anderen Tests bin ich noch nicht gekommen. Dieses Problem und da ich auch vom KT133A Bug stark betroffen war, haben mich veranlasst ein altes Script hervor zu kramen.

Über Nacht habe ich mit dem Bordeigenen Tool "fc" einen ca. 4 GB großen Datenbestand in Dateien von 50 bis 400 MB aufgeteilt immer wieder von einer HDD auf eine andere kopieren und vergleichen lassen. Von 1385 kopierten Dateien sind vier unterschiedlich:

0049A5AA: 09 01
008DE5AA: 0A 02
023615AA: 28 20
05A3B5AA: 2F 27

An meinem Rechner habe ich am primären Controller ein WD 160 GB und einen LG Brenner und am zweiten Controller eine WD mit 250 GB und ebenfalls einen LG Brenner.

Hier das Script:

Code

REM :fc oder comp
SET methode=fc

REM :Bitte sourcen angeben im Stiel c:\abc\xyz
SET source=E:\QUELLE
SET target=D:\PRUEFEN

FOR /F "TOKENS=1* DELIMS=\ " %%z IN ("%source%") DO SET lw=%%z
FOR /F "TOKENS=2,3,4* DELIMS=. " %%i IN ("%DATE%") DO SET INF_DATE=%%kj_%%jm_%%id
FOR /F "TOKENS=1,2,3,4* DELIMS=:, " %%i IN ("%TIME%") DO SET INF_TIME=%%ih.%%jm.%%ks.%%lms

%lw%
cd "%source%"
del *.mylog

:schleife

xcopy /R /Y "%source%\*.*" "%target%"
IF %methode%==comp FOR %%f IN (*.*) DO %methode% "%source%\%%f" "%target%\%%f" /D >>"%temp%\logfile_from_%INF_DATE%_%INF_TIME%.mylog"
IF %methode%==fc FOR %%f IN (*.*) DO %methode% "%source%\%%f" "%target%\%%f" /B >>"%temp%\logfile_from_%INF_DATE%_%INF_TIME%.mylog"
del /Q /F "%target%\*.*"

goto schleife

REM c:
REM cd\

notepad "%temp%\logfile_from_%INF_DATE%_%INF_TIME%.mylog"


Im Einsatz habe ich die Standard Microsoft IDE Treiber, da ich mit den nForce Treibern akute Geschwindigkeitseinbrüche auf dem BUS festgestellt habe, wenn mehrere Tasks parallel Daten von HDD 1 zu 2 und umgekehrt schicken. Ebenfalls lassen sich nicht parallel Daten Brennen und das ist für mich existenziell. Alle Dokumente halte ich doppelt vor und brenne sie zur gleichen Zeit um Zeit zu sparen.

Im Betrieb sind mir keine Stabilitätsprobleme aufgefallen. Prime95 rechnete nach meinem Übertakten Nächtelang ohne Fehler.

Hier die Einstellungen: Venice 3200+ auf 2350 MHz, Referenztakt auf 235 MHz, HTT auf 4X mit 960 MHz, RAM mit DDR333, also mit 195 MHz, die CPU läuft mit 113% vCore, also mit 1,5 statt 1,35 Volt. Alle Komponenten außer der CPU sind also in der Spezifikation betrieben.

Ich werde mein System einmal auf Standard takten und schauen ob ich immer noch Bitfehler habe, es könnte ja an der übertakteten CPU liegen?! Oder…

Kann sich einer die Mühe machen und seinen Chipsatz in einer ähnlichen Konfiguration mal auf Herz und Nieren prüfen?!


OCinside.de PC Forum
© 2001 - 2024 www.ocinside.de