Reprise du message précédent :
j'ai un 720BE a 3.6 en x4 sur une dfi 790gx, je te filerais quelques conseils quand j'aurais le temps ( cad ce we ).

J'en suis à 3866 MHz avec mon Phenom II X2 @ X4 et 1.50v de vcore
 
stable en jeux et encodage x264 pendant plusieurs heures !

 
Nice    
 
C'est stable avec OCCT ou pas ?

aucune idée j'ai pas encore essayé mais bon OCCT je m'en fout un peu je ne fais pratiquement que du jeu et de l'encodage et j'y ai déjà passé des heures ..... sans aucun plantage !

j'suis stable anything a 3.8
 
sauf occt

il martyrise les cpu

De même pour 3,8Ghz.
Cet OCCT il n'aime pas les PHENOM II  

moi perso j'ai le temps pour m'occuper de la bdd. (au moins jusqu'a fevrier), mais bon d'ici la... xD

Donc t'es pas stable.  

Stable en jeux/encodage ca veut rien dire ! Si tu crash pas ca veut pas dire que t'es stable... Une erreur de calcul en jeux c'est pas forcement grave, en encodage un peu plus... Avoir un pixels de la mauvaise couleur, ou un macroblock qui part en vrille c'est génant et ça ne se verifie qu'en regardant le film en entier, et encore...
 
C'est toujours le même débat, mais être stable c'est ne pas faire d'erreur de calcul, pas evité les BSOD... Idéalement même c'est pour tout les programmes, quelques soit les conditions...

déja, 60minutes de OCCT, ca ne garantie pas d'etre stable. j'ai souvent eux des bluescreen apres deux ou trois heures.

Bah en 1H on est déjà même pas forcement dans une zone de palier de T° donc forcement...
 
Faut mini viser une nuit de 8-10H pour commencer à être sur le temps que tout soit bien a T°.

 
si tu veux etre sure d'etre 100% stable, tu dois faire un furemark en mode burn, avec un occt en mode priorité low. Comme ca tu fais chauffer la carte graphique et le proco en meme temps (important de mettre en low pour permettre a furmark de tourner convenablement)

OCCT 3.1.0 fait deja ça... OCCT GPU (pire que furmark) + Linpack

et tu fais flamber le PC

Bah disons que faut pas avoir une alim noname.

Déjà que LinPack n'est utile que pour 4/5 passes
Car oui, il est inutile de stresser autant son CPU
Vu qu'on ne s'en sert jamais, de ce programme!
Programme qui au passage n'est pas un test de stabilité au sens détection d'erreur
Il sert juste à voir si l'alimentation tient la charge ...
 
EDIT:

Linpack fait un error check aussi...

Vois ça avec le iench
Ce sont ses paroles
Je peux rien pour toi

http://forum.hardware.fr/forum2.ph [...] 1#t1849809

ca va j'ai une bonne alim de marque ......... HEDEN !    
 
non je rigole j'ai une Hiper Type-R 470 Watts qui devra supporter :
 
- Phenom X2 550BE @ X4 et overclocké à 3866 MHz vcore 1.50v
- 2 DD de 640 & 500 Go SATA2
- 1 SSD Crucial M225 64 Go
- 1 Powercolor HD4870 1 Go stalker edition ou ma HD 4850 Vapor-X 512 Mo .......... ou alors les 2 en CF
- 1 graveur DVD SATA  
- 4 Go de RAM DDR2 PC8500 GSkill
 
voili voilà je crois que j'ai rien oublié

Tu sais pas lire en fait je pense C'est pas parce que ça detecte moins bien les erreurs que ça detecte rien.

Ce n'est pas un test de détection d'erreurs d'origine
OCCT, CSMT ou Prime, si
Il le fait mais moins bien qu'eux si tu préfères
Sa méthode est de "bourriner", ce qui fait qu'on ne sait pas facilement diagnostiquer si l'erreur détectée vient de la charge sur l'alimentation ou de la confiig
 
iench a notamment prouvé (Post à retrouver ), que bien qu'il accapare beaucoup la RAM, il ne la stresse pas outre mesure
Il s'en sert juste pour consommer au max. (+ de RAM utilisé = + de chauffe CPU)
 
Bref, si ça plante => étages (tous les) d'alim. insuffisant(s)
Demande-lui...

 
Linpaq ce n'est qu'un bench pour montrer les perf du module Linpaq de la bibliothèque Math d'Intel... Après que ça chauffe, c'est pas fait pour, c'est juste que c'est optimisé à mort, normal Intel la vends pour les perfs à la base einh.
La charge sur l'alimentation n'en est qu'une consequence.
 
Sinon la corrélation RAM utilisé => chauffe CPU c'est n'importe quoi. Tu peux tester sous 7-Zip par exemple, plus t'as un gros dico, plus t'utilise de RAM plus c'est lent et moins le CPU chauffe... (logique d'un côté vu que ca va être ralentie par les I/O en RAM vu que ça tiens plus en cache L2/L3...)  De ce côté c'est même a contre courant de trouver une application qui stress plus le CPU avec un gros jeu de donnée qu'avec un petit.
 
Après le iench peux dire ce qu'il veux, il a pas non plus tester sur des dizaine de config & co. Moi en pratique j'ai eu des problèmes d'incompatibilité RAM ni illustré par OCCT, ni illustré par Memtest, qui on été vaguement illustré par Linpaq. Alors effectivement Linpaq a plutot tendance à faire moins stresser la RAM en terme de quantité d'I/O. Mais au moins toutes la RAM est stresser, ce qu'OCCT est encore loin de faire. Et en plus le chipset en prends pas mal dans la tronche. Plus ou moins que dans OCCT dure à dire, mais ca le stress bien differement.
 
Quand au fait de savoir si les pbs dans Linpaq sont du au CPU ou a l'alim... Faut vraiment être à l'ouest pour ne pas voir la différence. En general quand t'as le 12V qui tombe bas et que tu fait un black screen/BSOD avec les HDD qui s'eteigne c'est clair que y'a BEAUCOUP plus de chance que ce soit un baisse de tension de l'alim que le CPU. En plus faut quand même voir qu'avant d'o/c & de tester la stabilité CPU on est quand même censé être sur du reste de la machine.    
 
Conclure en disant que Linpaq est moins stressant qu'OCCT c'est trop vite dit, car ca dépends de ce qui produit l'instabilité, et globalement de la configuration. (quantité de RAM, etc.) QUand t'as 8Go de RAM et qu'OCCT en utilise que 500Mo à la fois et Linpaq les 8Go, bah t'as quand même plus de chance de tomber sur la zone foireuse avec Linpaq qu'avec OCCT. Par contre effectivement avec 2Go ca se reduit.
 
Se faisant, si on tiens un nuit de Linpaq + OCCT:GPU on est quasi sur de tenir une nuit d'OCCT:CPU...

1ère partie => suis au courant, merci
 
2ème partie => on parle de LinPack, pas d'un programme de compression. EDIT: vas sur XS, balancer ta validation LinPack sous OS 32 bits, on t'expliquera pourquoi tu te plantes ^^
 
3ème partie => différemment, c'est ton mot... Complémentaire sera le mien !
 
4ème partie => situation extrême, loin de permettre ne serait-ce que de s'approcher de la stabilité. LinPack le fait bien, super, on est contents pour lui
 
5ème partie => OK
 
fin => pas nécessairement, sinon on n'utiliserait pas les 2

Si t'as un OS 32 bits avec 2Go de RAM on s'en fou...
 
En plus dans la cas de Windows, sauf pour ceux qu'on la chance d'avoir une mobo qui permet d'avoir 3,25 ou 3,5Go de RAM dispo, on peut addresser 3Go de RAM pour le process donc bon ce n'est pas un problème majeur.
 
 

Je disais ça car j'y ai lu certains témoignages parlant d'instabilités en 64 qu'ils n'avaient pas en 32
Avec 4Go+ ...

Y a encore des gens en 32b ?    
Tout geek qui se respect se doit d'avoir 4Go de RAM mini et un OS 64bits, même si pour lui ça serre à rien    
 
Sinon pour votre petit débat je suis surement moins connaisseur que vous, mais bon si on tient 1h d'OCCT c'est bon signe, si on tient 10h on peut fortement penser qu'on est rockstable....
Bien sûr il n'y a que le temps qui pourra nous dire si on c'est trompé, mais bon faut pas être parano, on peut jamais être sûr à 100%.
Il suffit que l'été suivant il fasse 45°c de temperature ambiante et ta validation d'OCCT que tu avais fait pendants 24h en hivers serre plus à rien    
 
Peut importe ta manière de tester il y aura toujours une condition qui pourra faire planter un PC. Pour les systèmes pro il assure en mettant des plus grosse marge de sécurité, les fréquences sont souvent moins poussé et surtout pas d'OC (ce qui nous intéresse sur ce topic).

 
tout a fait
 
je top a 3600 et qq sous occt.

Ouai mais là deux phénomènes :
- le CPU ne se comporte pas forcement pareil en x86 et en x64 (notamment les Core 2 qui n'ont pas le Macro-Ops Fusion en x64, ce qui change sans doute pas mal la donne)
- tester en x86 quand on a plus de 4Go de RAM c'est forcement fosser le test, que ce soit Linpaq ou pas. Entre le fait que ce change la charge chipset/CPU, ça laisse aussi un zone RAM finalement pas testé.
 
Encore une fois, quand on valide un o/c en refléchissant à moitié aux tests qu'on effectue, forcement la validation reste elle valable ?
 
Parce que à priori si c'est pour valider en x86 alors qu'en pratique on va utiliser le CPU en x64 c'est un peu débile. C'est comme ci on testait la résistance de pneus dans un terrain boueux avant de faire une course sur asphalte... Est-ce vraiment directement comparable ?

wizerty > mon cas: stable sous HiperPI32M, Prime95, CSMT, OCCT, LinPack (T° indécentes ) mais en utilisation, surtout jeux, pas stable
J'aurais juré que c'était ma carte graphique qui débloquait ...
Bah avec +0.00625 au VCPU, c'est rentré dans l'ordre
L'o/c n'est pas une science exacte toussa kÿdÿsaÿent ^^

 
Bah déjà faut partir dans une chose : on ne test pas "STABLE" ou "PAS STABLE", mais plutôt un degré de stabilité, une sorte de j'ai un chance de faire une erreur tout les n cycle d'horloge.
Pourquoi ? Parce que même @ stock aucune machine n'est stable à 100%, tout simplement parce que rien que la RAM ne garantie pas que la valeur lue soit identique a celle écrite auparavant. C'est pour ça que la mémoire ECC existe, car c'est le seul moyen de s'en assuré. Donc tant que tout les bus, tout les cache, et la RAM ne seront pas avec des mécanismes de correction d'erreur, on aura toujours un gros risque d'erreur de calcul.
 
Finalement donc, ce qu'on cherche c'est a avoir un taux de stabilité le plus haut possible, si possible très proche du taux @ stock. (mais comme c'est pas vraiment une mesure quantitative mais plutot qualitative, c'est bien là le problème, car quand savoir qu'on est "assez stable" )
 

Ouai mais ca se trouve aucun de test bench utilisait assez les unité SSE et c'était celle-ci qui faisaient défaut en jeux, etc. Ca on ne saura jamais. Mais c'est aussi pourquoi la diversité des programmes de tests est utilisé, pour avoir le plus de scenario possible et donc essayé de tester le CPU en entier, toutes unités confondus, etc.
 
En pus il ne faut pas oublié que même sur des bonnes mobos, le Vcore "réel" en load peut être un peu plus bas si on tire aussi sur le 12V (carte graphique donc) que sans.
 
Bref, d'où l'intérêt aussi de bench GPU + CPU en //.

Y'a les jeux pour ça
Car LinPack + GPU : OCCT =>

Bien d'accord avec toi.....Pour moi tant que le PC plante pas dans les utilisations des tous les jour c'est le principal.  
Au final OCCT pour moi c'est qu'un moyen de gagner du temps, il me permet en 30min de savoir la stabilité du système sans avoir à faire tourner des jeux ou des encodage pendant des mois.
Il permet aussi de comparer les OC, que tout le monde ai les même contrainte....Un max screen et du H24 c'est pas la même chose, OCCT permet de faire la difference...
 
Voiloù et ça sera tout pour moi....  
 
HS off

piouff.  
 
je viens de me refaire tout le topic pour refaire entierement la bdd!
 
donc a partir d'ici c'est ma derniere maj!

Elle est ou la bdd? celle de la 1er page?  
 
Sinon c'est cool que tu puisses reprendre le topic pour dépanner le proprio d'origine  

, c'est pas clair !

ben disons que pour moi elle a pas changé    
 
Ou alors il a seulement prit les notes et il a pas encore rentré les infos en lignes  

Il va les poster ici
sospc n'aura qu'à C/C