Intel: 250 FSB Wall geknackt mit MDT

Mr.Mito schrieb:
Prime testet ja auch nur Prozi / Speicher und sonst nix !

ja hast recht, hatte ich vergessen

Mr.Mito schrieb:
:lol: Dann stimmt was mit dem System nicht, denn Rechenfehler sind NICHT normal. Billig Ram, zu wenig vdimm ... Mit guten Komponenten läuft JEDES System Prime stable @default, wenn nicht stimmt was nicht. :rolleyes:

das war nicht auf mein system bezogen sondern auf die erfahrungen anderer user in diesem bzw. anderen foren

Mr.Mito schrieb:
MemtestX86 ist UNGENAUER als Prime95 und zeigt Rechenfehler/Speicherfehler NICHT so schnell/genau an.

das würde ich nicht sagen, ich hatte mal "kaputten" speicher von einem notebook mit memtest86 getestet und bekam prompt über 5 millionen fehler angeziegt und zwar jeden einzelnen, memtest sollte man von der vorgehensweise auch nicht mit prime vergleichen, da es nicht den prozzi sondern die ram testet

Mr.Mito schrieb:
Bsp: Für Memtestx86 reichten 2,9Vdimm(real), für Prime95 musste ich 3Vdimm(real) anlegen. (2x256MB BH-5)

ich habe garnicht die möglichkeit 2,9 bzw.3v zu geben, weshalb mein ram immer mit 2.76v läuft, trotzdem läuft mein system stabil

Mr.Mito schrieb:
Nutzt du Prime 2x, wegen HT? :rolleyes:

ja klar, hatte ich schon 10 mal gepostet :rolleyes:

Mr.Mito schrieb:
Prozi und/oder tick zu wenig vdimm, siehe oben. :p

wenns immer nur an zu wenig vdimm oder vcore liegen würde, hätten wir eine ganze reihe von problemen weniger :rolleyes:

Mr.Mito schrieb:
Geringe Rechenfehler machen bei Videokompression rein gar nix, das siehste net mal, aber rock solid ist dein System NICHT, denn es VERRECHNET SICH !

es geht auch nicht um rechenfehler sondern um stabilität
du solltest nicht den fehler machen,
rechenfehler = instabilität
instabilität = rechenfehler
zu setzen. ist dein system instabil, stürtzt dein rechner einfach ohne vorwarnung bei der videoumwandlung ab, da kommt keine nette fehlermeldung wie bei prime und du kannst schön dem normalen windows-alltag nachgehen

Mr.Mito schrieb:

fakt ist, dass videokompression den gesamten rechner (bis auf die graka) an die grenzen bringt, prime95 nicht ;)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Es ist definitiv so, dass Rechenfehler zu einer Instabilität führen - nur ist es eben auch so, dass diese Rechenfehler nicht immer sofort zum Vorschein kommen und das System erstmal vordergründig stabil erscheint.

Fakt ist, dass Prime95 - richtig eingesetzt - das System definitiv mehr belastet als Videoencoden und gleichzeitig eine Möglichkeit der Fehlererkennung bietet, was beim Videoencoden nicht der Fall ist (Ausnahme: Das Programm stürzt ab.). Das Einzige, das beim Videoencoden ETWAS mehr belastet wird, ist die Festplatte; wobei dies meiner Meinung nach klar vernachlässigbar ist bzw. durch den (permanenten) Einsatz von Festplattenbenchmarks gleichzeitig mit Prime ebenso einfach "simulieren" lässt.
 
mit gesamten rechner meine ich
prozzi, mobo, ram, nt

ich kann deine aussage nicht nachvollziehen, prime und co. laufen bei mir stundenlang, aber TMPGenc ist bei nicht nur einmal abgestürtzt
 
das würde ich nicht sagen, ich hatte mal "kaputten" speicher von einem notebook mit memtest86 getestet und bekam prompt über 5 millionen fehler angeziegt und zwar jeden einzelnen, memtest sollte man von der vorgehensweise auch nicht mit prime vergleichen, da es nicht den prozzi sondern die ram testet
Ne, ne, ich vergleiche das nur z.T. miteinander.

Ich finde beide Progs gut und benutze Sie auch, allerdings nutz ich Memtest auch als Stab Test beim Ram OC und genau da ist es nicht so genau wie Prime, aber zum schnellen testen sehr gut geeignet. :)

Wenn nen Riegel wirklich defekt ist, ist ja klar das man nur Memtestx86 und kein prime 95 verwendet, beim OC sieht das anders aus und Fehler sieht man nicht so direkt. Prime ist eben NOCH genauer, wenn es sich um Speicher OC handelt und man den vollen Ram nutzt.

wenns immer nur an zu wenig vdimm oder vcore liegen würde, hätten wir eine ganze reihe von problemen weniger
Wenn Prime nen Rechenfehler bringt hab ich das bisher immer mit bissel mehr Vcore/vdimm/anderen Timings oder geringfügig runtertakten hinbekommen. Wenn die HW halt einfach am Ende ist, hilft nur runtertakten, zum laufen bekommt man es auf jeden Fall, sofern kein defekt und/oder eine Inkompatibilität zwischen 2 Komponenten vorliegt.

Oder ne Einstellung @BIOS die evt. bei dem FSB "zu stramm" ist.

es geht auch nicht um rechenfehler sondern um stabilität
du solltest nicht den fehler machen,
rechenfehler = instabilität
instabilität = rechenfehler
zu setzen. ist dein system instabil, stürtzt dein rechner einfach ohne vorwarnung bei der videoumwandlung ab, da kommt keine nette fehlermeldung wie bei prime und du kannst schön dem normalen windows-alltag nachgehen
Ich mache nicht den Fehler das gleichzusetzen, es IST das gleiche.

Rechenfehler verursachen ein unstable Sys, egal ob es "Windows" stabil ist oder nicht.

Es macht HW-Fehler und KÖNNTE dadurch mal abstürzen, das will ich vermeiden.

Es soll genau so zuverlässig sein und richtig rechnen wie @default auch. :)

fakt ist, dass videokompression den gesamten rechner (bis auf die graka) an die grenzen bringt, prime95 nicht
Wenn er sich dort verrechnet, siehst du die Fehler nicht, außer er macht etliche auf einmal und dein Prog schmiert weg.

Videokompression zeigt dir keine Fehler an und ich als zusätzlichen Test sicherlich gut, aber um Rechenfehler, die OC bedingt enstehen, festzustellen ist Prime95 einfach nen super Proggi. :)

ich kann deine aussage nicht nachvollziehen, prime und co. laufen bei mir stundenlang, aber TMPGenc ist bei nicht nur einmal abgestürtzt
Wie lang lief Prime denn / welche Einstellungen? Welcher Takt und wie weit musstest du runter gehen, damit TMPGenc funzte?

Hatte ich echt noch nie. Wenn mein Sys prime95 stable ist(12-24h in place und einmal mit voller Ramnutzung über n8), der Chipsatz es auch def. macht (zoggn ohne Ende), dann funzte bisher ALLES was ich gemacht habe.
 
Zuletzt bearbeitet:
@ mito

sorry, war die letzten 2 tage nicht zu hause, ich meld mich später
aber ziemlich interessante diskussion bisher :)
 
Mr.Mito schrieb:
Ne, ne, ich vergleiche das nur z.T. miteinander.

Ich finde beide Progs gut und benutze Sie auch, allerdings nutz ich Memtest auch als Stab Test beim Ram OC und genau da ist es nicht so genau wie Prime, aber zum schnellen testen sehr gut geeignet. :)

ja memtest ist wirklich ein sehr gutes prog, zum OC testen als auch für defekte rams sehr gut zu gebrauchen

Mr.Mito schrieb:
Wenn nen Riegel wirklich defekt ist, ist ja klar das man nur Memtestx86 und kein prime 95 verwendet, beim OC sieht das anders aus und Fehler sieht man nicht so direkt. Prime ist eben NOCH genauer, wenn es sich um Speicher OC handelt und man den vollen Ram nutzt.

aber wenn man nicht genau weiß, ob der ram defekt ist, sollte man das ja erstmal herausfinden, und deshalb würde ich da memtest nehmen und nicht prime

Mr.Mito schrieb:
Wenn Prime nen Rechenfehler bringt hab ich das bisher immer mit bissel mehr Vcore/vdimm/anderen Timings oder geringfügig runtertakten hinbekommen. Wenn die HW halt einfach am Ende ist, hilft nur runtertakten, zum laufen bekommt man es auf jeden Fall, sofern kein defekt und/oder eine Inkompatibilität zwischen 2 Komponenten vorliegt.

bei einigen MDTs ist es leider so, dass bei einem bestimmten takt einfach schluss ist, egal ob man timings verschlechtert oder die vdimm erhöht, wenn schluss ist dann ist schluss :(

Mr.Mito schrieb:
Ich mache nicht den Fehler das gleichzusetzen, es IST das gleiche.

Rechenfehler verursachen ein unstable Sys, egal ob es "Windows" stabil ist oder nicht.

Es macht HW-Fehler und KÖNNTE dadurch mal abstürzen, das will ich vermeiden.

Es soll genau so zuverlässig sein und richtig rechnen wie @default auch. :)

Wenn er sich dort verrechnet, siehst du die Fehler nicht, außer er macht etliche auf einmal und dein Prog schmiert weg.

Videokompression zeigt dir keine Fehler an und ich als zusätzlichen Test sicherlich gut, aber um Rechenfehler, die OC bedingt enstehen, festzustellen ist Prime95 einfach nen super Proggi. :)

du meinst, rechenfehler würden sich bei videobearbeitung nicht so sehr auswirken wie bei prime, aber wir würden sich denn rechenfehler überhaupt bei videobearbeitung auswirken ??
ganz einfach: in abstürtzen, das ist fakt
und meiner meinung nach gibts auch nicht sowas wie "videobearbeitung reagiert nicht so sehr wie prog a oder b"
bei einem rechenfehler stürtzt entweder das prog ab oder windows, "bischen gibts nicht", behaupte ich mal ganz spontan, ich lasse mich auch gerne vom gegenteil überzeugen ;)

Mr.Mito schrieb:
Wie lang lief Prime denn / welche Einstellungen? Welcher Takt und wie weit musstest du runter gehen, damit TMPGenc funzte?

Hatte ich echt noch nie. Wenn mein Sys prime95 stable ist(12-24h in place und einmal mit voller Ramnutzung über n8), der Chipsatz es auch def. macht (zoggn ohne Ende), dann funzte bisher ALLES was ich gemacht habe.

is leider schon ne weile her, da mein rechner jetzt so läuft, wie ich es mir vorgestellt habe

prime lief ca. 2h, einstellungen waren unverändert, kein plan welche version es war :( takt war 233mhz, 3-4-4-8, 2,76vdimm (real)
prime lief die 2h durch, ich ging davon aus, dass das system stabil war, jedenfalls schmierte mir superpi bei loop15 oder so ab und TMPGenc reagierte nach ner weile überhaupt nicht mehr, maus blieb hängen, als half nur noch ein restart, es lag wohl auch an der temp vom prozzi, die lag bei ca. 60 grad, kein plan woran das noch hätte liegen können

aber du weißt ja wie das ist, macht man einmal eine schlechte erfahrung mit nem proggi, steigt man sofort auf andere um

teste ich auf stabilität, sieht das bei mir folgendermaßen aus:
prozzi: videokompression von mind. 12h mit tmpgenc, superpi 32m
ram: memtest von mind. 5h, superpi 32m
graka: 3dmark03 mothernature mit 4xAA und 8xAF im loop, mind. 2h


bestehen alle komponenten meines rechners obige aufgaben, bezeichne ich ihn als 100% stabil

wie siehts bei dir aus? :xmas:
 
Zuletzt bearbeitet:
aber wenn man nicht genau weiß, ob der ram defekt ist, sollte man das ja erstmal herausfinden, und deshalb würde ich da memtest nehmen und nicht prime

Sagte ich etwas anderes, eigentlich nicht. ;) *g* Mir ging es ja um OC testen und da ist Prime genauer.

du meinst, rechenfehler würden sich bei videobearbeitung nicht so sehr auswirken wie bei prime, aber wir würden sich denn rechenfehler überhaupt bei videobearbeitung auswirken ??
ganz einfach: in abstürtzen, das ist fakt
und meiner meinung nach gibts auch nicht sowas wie "videobearbeitung reagiert nicht so sehr wie prog a oder b"
bei einem rechenfehler stürtzt entweder das prog ab oder windows, "bischen gibts nicht", behaupte ich mal ganz spontan, ich lasse mich auch gerne vom gegenteil überzeugen ;)

Sagen wir der Prozzi verrechnet sich und es entstehen ein paar fehlerhafte Pixel im Film an ner sehr hektischen Scene.

Das siehst du NIEMALS. Durch einen oder sogar mehrere Rechenfehler muss der PC nicht zwangsläufig abstürzen, oder wieso kann man mit nem non prime95 stable sys manchmal auch stunden lang zoggn?

Prime zeigt mir diese Fehler an, was andere Programme (leider) nicht machen. Die semmeln nur bei harten Fehlern ab. Wenn bei nem Film nen paar Pixel fehlerhaft berechnet werden, schert das dat Prog relativ wenig.

Meine Meinung.

prime lief ca. 2h, einstellungen waren unverändert, kein plan welche version es war takt war 233mhz, 3-4-4-8, 2,76vdimm (real)
prime lief die 2h durch, ich ging davon aus, dass das system stabil war, jedenfalls schmierte mir superpi bei loop15 oder so ab und TMPGenc reagierte nach ner weile überhaupt nicht mehr, maus blieb hängen, als half nur noch ein restart

2h Prime ist nichts. :fresse: Des weiteren gibt es sehr viele verschiedene Möglichkeiten mit Prime zu testen. 8k-4096k / in place fft / 15-20min pro fft ist gut für "zwischendurch", über n8 mit voller Ramauslastung. :)

Super PI lief bei mir schon so oft und Prime brachte nach 2-3min schon nen Fehler, daher halt ich davon nix mehr. Ist ne Spielerrei zum antesten, aber kein Stabtest.

es lag wohl auch an der temp vom prozzi, die lag bei ca. 60 grad, kein plan woran das noch hätte liegen können

Gut möglich, wobei Prime bei mir mehr heizt als Videos umwandeln. Wieso sich dein Intel anders verhält :confused: Mein Prozzi will z.B. immer das ich ihn unter 50°C halte, sofern er max oced ist. *g*

aber du weißt ja wie das ist, macht man einmal eine schlechte erfahrung mit nem proggi, steigt man sofort auf andere um

Mhhh, jain, ich schau mir die Progs sehr oft später mal wieder an, sofern se net wirklich "totaler Müll" sind, was ich bei Prime95 nicht finde. :)

teste ich auf stabilität, sieht das bei mir folgendermaßen aus:
prozzi: videokompression von mind. 12h mit tmpgenc, superpi 32m
ram: memtest von mind. 5h, superpi 32m
graka: 3dmark03 mothernature mit 4xAA und 8xAF im loop, mind. 2h

bestehen alle komponenten meines rechners obige aufgaben, bezeichne ich ihn als 100% stabil

wie siehts bei dir aus? :xmas:

Speicher ~1h mit Memtestx86 antesten, danach @Prime 95 mit voller Ramausnutzung (12h+) und das ganze wieder wenn ich den max Takt @Prozi gefunden habe. :) Filme rippen kommt dann irgendwann ma, da es bisher IMMER funktioniert hat leg ich darauf net so wirklich großen Wert.

Chipsatz/Graka 3d-quark 01/03 und viel, sehr viel zoggn. Far Cry ist besonders gut zum testen geeignet (auch Chipsatz/bringt direkt Fehler, zumindest bei meinem NF II).
 
Mr.Mito schrieb:
Sagte ich etwas anderes, eigentlich nicht. ;) *g*

hab ich das gesagt ? ;)

Mr.Mito schrieb:
Mir ging es ja um OC testen und da ist Prime genauer.

:fire:

Mr.Mito schrieb:
Sagen wir der Prozzi verrechnet sich und es entstehen ein paar fehlerhafte Pixel im Film an ner sehr hektischen Scene.

ich kann dir definitiv sagen, wenn pixel im film entstehen, kommt das sicher nicht von einem instabilen system ;) das ist ganz einfach eine sache des codecs und deren einstellungen, kannst mir glauben

Mr.Mito schrieb:
Das siehst du NIEMALS. Durch einen oder sogar mehrere Rechenfehler muss der PC nicht zwangsläufig abstürzen, oder wieso kann man mit nem non prime95 stable sys manchmal auch stunden lang zoggn?

Prime zeigt mir diese Fehler an, was andere Programme (leider) nicht machen. Die semmeln nur bei harten Fehlern ab. Wenn bei nem Film nen paar Pixel fehlerhaft berechnet werden, schert das dat Prog relativ wenig.

Meine Meinung.

wie unterscheidest du zwischen harten und unharten fehlern ?
wie kommst du darauf, dass bei einem instabilen sys. "ein paar" pixel falsch berechnet werden ...


Mr.Mito schrieb:
2h Prime ist nichts. :fresse: Des weiteren gibt es sehr viele verschiedene Möglichkeiten mit Prime zu testen. 8k-4096k / in place fft / 15-20min pro fft ist gut für "zwischendurch", über n8 mit voller Ramauslastung. :)

Super PI lief bei mir schon so oft und Prime brachte nach 2-3min schon nen Fehler, daher halt ich davon nix mehr. Ist ne Spielerrei zum antesten, aber kein Stabtest.

ja richtig, 2h prime ist nichts, andere testen auch nur mit 2h, trotzdem denke ich, dass 2h zu wenig sind


Mr.Mito schrieb:
Gut möglich, wobei Prime bei mir mehr heizt als Videos umwandeln. Wieso sich dein Intel anders verhält :confused: Mein Prozzi will z.B. immer das ich ihn unter 50°C halte, sofern er max oced ist. *g*

kann ich garnicht glauben, dass prime bei dir mehr heizt ...
wie wandelst du die videos um ??

wenn ich von videokompression bzw. umwandlung spreche, dann meine ich immer UNKOMPRIMIERTES MATERIAL also ROHMATERIAL in mpeg2 umrechnen, das ist nicht zu vergleichen als ne dvd rippen oder nen avi-film in mpeg2 umzurechnen, sorry hätte ich sagen müssen

Mr.Mito schrieb:
Mhhh, jain, ich schau mir die Progs sehr oft später mal wieder an, sofern se net wirklich "totaler Müll" sind, was ich bei Prime95 nicht finde. :)

gib mir mal n link von der aktuellsten version und zeig mir deine einstellungen

Mr.Mito schrieb:
Speicher ~1h mit Memtestx86 antesten, danach @Prime 95 mit voller Ramausnutzung (12h+) und das ganze wieder wenn ich den max Takt @Prozi gefunden habe. :) Filme rippen kommt dann irgendwann ma, da es bisher IMMER funktioniert hat leg ich darauf net so wirklich großen Wert.

Chipsatz/Graka 3d-quark 01/03 und viel, sehr viel zoggn. Far Cry ist besonders gut zum testen geeignet (auch Chipsatz/bringt direkt Fehler, zumindest bei meinem NF II).

deine variante is sicher ebenso belastend für den rechner :)
alledings halte ich "reale" anwendungen wie umwandlungen und zocken für aussagekräftiger wie prime, auch wenns um andere sachen geht wie prozzi und ram testen

aber ich denke das ist ansichtssache :bigok:
 
@Ceylon lol kannste mir mal verraten in wievilen Foren du deine ergebnisse noch reingepostet hast?
LOL habs bei THG, CHIP und hier endeckt LMAO :xmas:
 
Zuletzt bearbeitet:
@Silver:

Ich find das Gespräch echt :bigok: :d

ich kann dir definitiv sagen, wenn pixel im film entstehen, kommt das sicher nicht von einem instabilen system das ist ganz einfach eine sache des codecs und deren einstellungen, kannst mir glauben

Da haste mich scheinbar missverstanden. Das ganze war theoretischer Natur und es bezog sich auf verrechen @encoden. Sagen wir nen paar Pixel im vid sind fehlerhaft durch einen Rechenfehler (1Bild mit 4-5 Pixelfehlern), das würdest du NIE sehen, höchstens mit Standbild und Lupe. :fresse:

wie unterscheidest du zwischen harten und unharten fehlern ?
wie kommst du darauf, dass bei einem instabilen sys. "ein paar" pixel falsch berechnet werden ...

Na ja wenn Prime mir nen Rechenfehler auswirft kann ich manchmal trotzdem stunden lang zoggn, also können die Rechenfehler net "so schlimm" sein. Wenn das Sys richtig unstable ist, semmelt es beim gamen ect. weg. Daher trenn ich zwischen "Windoof/zogg stable" und Prime95 stable, denn das sind 2 paar Schuhe.

Zum unstable Sys und falsch berechnen --> dumm gesagt. Ich meinte wenn Prime Rechenfehler meldet, aber das encoden funzt, das dann auch 100%ig beim encoden z.T. falsch berechnet wird, was man aber nicht sehen muss. (theoretischer Natur, aber plausibel ;) )

kann ich garnicht glauben, dass prime bei dir mehr heizt ...
wie wandelst du die videos um ??

Kommt relativ selten vor. Ich glaub es war Xmpeg @DivX.

wenn ich von videokompression bzw. umwandlung spreche, dann meine ich immer UNKOMPRIMIERTES MATERIAL also ROHMATERIAL in mpeg2 umrechnen, das ist nicht zu vergleichen als ne dvd rippen oder nen avi-film in mpeg2 umzurechnen, sorry hätte ich sagen müssen

Ok, Missverständnis, denn ich ging von "DVD rippen" aus. ;)

gib mir mal n link von der aktuellsten version und zeig mir deine einstellungen

www.mersenne.org

Einstellungen:

Tagsüber 8-4096k / in place fft / 15-20min pro fft

Nachts dat gleiche, nur mit voller Ramausnutzung (also in place ausmachen und den ganzen Ram freigeben)

Tagsüber bringt das nix, denn 1. is der PC dann nur am swappen 2. ist die Auslastung nahe zu 0 wenn man am PC was arbeitet (wieso ka, denke ma er bekommt net schnell genug Nachschub zum rechnen).

Das taugt nur wenn man NIX am PC macht und einfach laufen lässt. :)

deine variante is sicher ebenso belastend für den rechner
alledings halte ich "reale" anwendungen wie umwandlungen und zocken für aussagekräftiger wie prime, auch wenns um andere sachen geht wie prozzi und ram testen

aber ich denke das ist ansichtssache

Stimmt, ist Ansichtssache. Wir fahren ja beide, mit den verschiedenen Möglichkeiten, ganz gut und Prime95 zeigte mir halt oft genug die Grenzen :fresse:, dazu noch 3 Tage dauerzoggn und etliche 3D-Quark loops (wobei manche Gamez VIEL besser sind) und die Möhre fuppt. :) Ich verbinde Testprogramme die ich gut finde eben mit normalen Anwendungen --> :bigok: :)

Ich nehm halt Prime95/Memtestx86 für Prozi/Ram und du encodest irgendwelche vidz, stresst wohl beides sehr viel, aber mir gefällt Prime95 einfach besser, da es mir Fehler anhand einer Fehlermeldung anzeigt, was beim Filme rippen nicht passiert. Ich DENKE MIR halt das kleinere Rechenfehler beim encoden nix machen und das dat Prog nur bei "schwerwiegenden" Fehlern absemmelt. Ob es so ist, ka. ;)

Nimm doch einfach Prime95 UND vidz, dann isset 100%ig stable und hat auch keine Rechenfehler. :bigok:
 
Mr.Mito schrieb:
@Silver:
Da haste mich scheinbar missverstanden. Das ganze war theoretischer Natur und es bezog sich auf verrechen @encoden. Sagen wir nen paar Pixel im vid sind fehlerhaft durch einen Rechenfehler (1Bild mit 4-5 Pixelfehlern), das würdest du NIE sehen, höchstens mit Standbild und Lupe. :fresse:

nehmen wir mal an, deine theorie stimmt, das würde ja bedeuten, dass bei einem total instabilen rechner (z.b. mein 2.8er auf 3.8ghz) extreme viele pixelfehler zu sehen sein würden
 
genau so hab ich ihn auch verstanden... und ich würde dem auch zustimmen... is es anders ? oder warum fragste so seltsam ?
 
Mr.Mito schrieb:
Stimmt, ist Ansichtssache. Wir fahren ja beide, mit den verschiedenen Möglichkeiten, ganz gut und Prime95 zeigte mir halt oft genug die Grenzen :fresse:, dazu noch 3 Tage dauerzoggn und etliche 3D-Quark loops (wobei manche Gamez VIEL besser sind) und die Möhre fuppt. :) Ich verbinde Testprogramme die ich gut finde eben mit normalen Anwendungen --> :bigok: :)

Ich nehm halt Prime95/Memtestx86 für Prozi/Ram und du encodest irgendwelche vidz, stresst wohl beides sehr viel, aber mir gefällt Prime95 einfach besser, da es mir Fehler anhand einer Fehlermeldung anzeigt, was beim Filme rippen nicht passiert. Ich DENKE MIR halt das kleinere Rechenfehler beim encoden nix machen und das dat Prog nur bei "schwerwiegenden" Fehlern absemmelt. Ob es so ist, ka. ;)

Nimm doch einfach Prime95 UND vidz, dann isset 100%ig stable und hat auch keine Rechenfehler. :bigok:

mir gehts ja nicht darum, wessen variante nun die bessere ist, sondern ich will der sache wirklich auf den grund gehen:
welcher vorgang bzw. welches tool reizt den computer am meisten aus ? Warum ist das so ? Wie macht sich das bemerkbar ?

wir könnten noch tagelang darüber diskutieren, aber es wäre schön, wenn sich mal jemand zu wort meldet, der "wirklich" ahnung davon hat
nachher denken wir beide unser system ist 100% stabil und dann kommt jemand und zeigt uns erstmal das gegenteil :xmas:
 
Zuletzt bearbeitet:
naja wenn du mich fragst gibts nich das ultimative programm um stabilität zu testen... man muss einfach alles was richtig stresst drüber laufen lassen wenns das alles aushält dann is auch wirdklich stabil

video encoden
superpi
prime
dauerzoggen
3d mark loops

naja vielleicht gibts noch mehr aber das sind so die wichtigsten sachen... prime kann ja gar nich auslastender sein als video encoden weil prime lastet "nur" cpu und ram aus... video encoden auch die hdd und da fehlt jetz immernoch die graka... es kann ja auch sein dass hdd, cpu, ram, board, graka alles einwandfrei funzen wenns einzeln getestet wird... aber wenn alels zusammenläuft gibts probs... oder dann macht das netzteil schlapp oder so...
 
nehmen wir mal an, deine theorie stimmt, das würde ja bedeuten, dass bei einem total instabilen rechner (z.b. mein 2.8er auf 3.8ghz) extreme viele pixelfehler zu sehen sein würden
Neee, wenn er zuviele Rechenfehler macht semmelt das Prog vorher ab. :fresse:

naja wenn du mich fragst gibts nich das ultimative programm um stabilität zu testen...
Right, das wäre auch zu schön um war zu sein. Nen Progger könnte sich dem ja mal annehmen. Graka Tester ink Artefact Scanner + volle CPU Auslastung mit Prime Berechung + volle Speichernutzung + Fehleranzeige = :bigok:

HDD lass ich weg, denn die interresiert OC eigentlich gar net, außer man oced PCI mit.

prime kann ja gar nich auslastender sein als video encoden weil prime lastet "nur" cpu und ram aus...
Es ging mir net darum was "auslastender" ist, wobei die HDD eh shice egal ist. Es ging mir darum das Vidz encoden mir kleinere Rechenfehler NICHT anzeigt, was Prime aber macht, daher finde ich es besser. ;)

könnte man auch als Fazit stehen lassen
Tut mir leid, das musste noch raus. :fresse:

Jeder sollte einfach für sich die best mögliche Kombination heraus finden. Bei mir besteht das ganze eben aus langen Prime95 Sessions, kurzen Memtestx86 Test (~1h) und ewiger Zoggerei, gepaart mich gelegentlichen Vidz encoden. Damit fuhr ich bisher immer rock solid und z.B. mein KX-7 Sys lief ~4 Monate 24/7 durch (paar reboots, wegen Update, aber sonst nüscht *g*).
 
Zuletzt bearbeitet:
:btt: gibts das Problem mit der Wall evtl. auch bei den GeiL GD3200?? Ich komm nämlich nie stabil über 250MHz FSB...Teiler ist egal... :heul:
 
Firewheels schrieb:
@Ceylon lol kannste mir mal verraten in wievilen Foren du deine ergebnisse noch reingepostet hast?
LOL habs bei THG, CHIP und hier endeckt LMAO :xmas:

In allen Foren die ich kenne... :)

Sodele, nachdem das Abit Max3 nicht die erhofften besseren Ergebnisse gebracht hat habe ich es gegen eine P4C800 dlx Rev 2.0 getauscht.

3.2c@3.6GHz - 1.55v - 225FSB - 2.5_2_3_5 - 2.55v - PAT:enabled

Mehr schafft der Prozzi nicht stabil mit Lukü.

Mein höchster Wert den ich erreichen konnte lag bei 246FSB/3.94GHz aber absolut unstable.
 
mh könnt das bei mir auch klappen ? hab en p4 2,8 @ 3,44 ghz aber nur mit pc333er rams laufen (ohne Ocen usw..),die CPU läuft mit FSB 245 ! hab auch das Asus p4c800 deluxe-e. könnt ich mir auch bedenkenlos den mdt pc400 er holen und auf 2,8 oder 2,85 laufen lassen ?
 
Hab mir auch mal die MDT's geholt, laufen mit 225MHz Memtest stable, aber nur mit den SPT Timings (2.5 - 3- 3 - 8), reicht auch vollkommen, aber meine CPU bootet bei 250MHz (mit 5:4 Teiler) nicht mehr, kann das sein das die schon am Ende ist?

MfG DeepInTrouble
 
Herzlich willkommen - bin neu hier und gleich
eine Bescheidene Frage:
Laufen die MTD's, von denen hier die Rede ist, auch mit einem AMD64-System (Board Neo-Platinum von MSI) ?
Danke für die Antwort - habe alles gekauft - bis auf die RAMS
 
@ ceylon:

Kannst Du bitte mal deinen aktuellen Speicherdurchsatz posten?
 
also das Programm was am sensibelsten auf Übertaktung reagiert is meiner Meinung nach eindeutig Climateprediction.
Mein Rechner war Prime, Memtest und zock stabil aber CP is mir mit Rechenfehlermeldung abgesemmelt, was mir bei niedrigerer Taktung nicht passiert...
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh