Reprise du message précédent :
 
 
 
c'est effectivement très simple a réaliser.....bien sur faut y
ajouter le petit piquant nommer silence sinon c'est pas drole.
 
   
 
 
 

Y'en a qu'on jamais testé Linpack quoi.
 
Bien sur que si ça stress le chipset/RAM. Quand t'utilise 6Go de RAM à la fois tu stresse potentiellement plus la RAM qu'OCCT avec ces quelques Mo. Parce que au moins t'as l'assurance que toutes la RAM sera utilisée. (t'es pas dépendant de ce que l'OS va t'allouer vu que tu prends tout).
 
 

Utilisée ne veut pas dire stressée, avec des cycles redondants/aléatoires de lecture/effacement/écriture

+1
Mais il a peut-être quand même raison
Faudrait voir avec un logiciel du type PerfMonitor si c'est bien le cas.

On reste branchés en attente de ton reportage ^^
!

Wow je pensais pas susciter tant de posts...
 
Bon pour info mon cheminement de Test perso c'est MemTest (DOS) -> IBT -> CineBench (avec render final modifié) -> x264 Benchmark -> OCCT...
 
La question que je me pose c'est en quoi OCCT (ou même CSMT hein) est plus représentatif de la charge que peut effectuer un PC que IBT ou autre...?
 
Jusque là il me semble que le Pc est bien plus stressé par ces 2 logs, que ce qu'il est possible de faire en temps normal non...?
 
Donc en se basant là dessus, y'a t'il vraiment une réelle utilité à se trouver stable sous OCCT, si c'est pour ne pas l'être avec IBT...?
 
Je veux dire, vaut il mieux rendre sa machine stable sous les applis utilisées habituellement et donc profiter de tout le potentiel de son matos (au risque de foirer OCCT et/ou autres) ou alors rendre sa machine stable sous OCCT/IBT et donc perdre une bonne partie de son potentiel, alors que cet état de stress ne se produira jamais...? (J'ai l'impression qu'on a tous plus ou moins le cul entre 2 chaises... )
 
Tetedeiench, merci de m'avoir répondu déjà, toi qui est à l'origine de OCCT, quelle est ta position vis à vis de l'habitude HFRienne qui dit plus ou moins "si tu tiens pas OCCT 4-8 heures t'es pas stable"...?

Je réponds à sa place ^^
Il a toujours expliqué qu'il faut mixer les tests, que ce soit le sien avec CSMT ou avec n'importe quel autre
Partant, une utilisation 'standard' ne peut se suffire si de tels tests ne passent pas stables!
& si tu veux tous les passer (IBT y compris ), libre à toi
Conclusion: il n'y a pas de méthodes clef
A part si tu cherches à stresser tel ou tel composant spécifique en tout connaissance de cause (quel programme teste quoi)
Enfin comme je l'ai écrit, IBT (ou LinPack ) ne stresse pas le chipset ou le contrôleur RAM embarqué et encore moins le reste de la machine...
Son seul but est de faire chauffer le CPU
Du coup, iench porte à caution son utilisation pour décrêter une machine stable.
Son CPU certes, mais pas toute la machine, avec laquelle tu devras passer d'autres tests pour décrêter stable toute la config.!
Sur XS par exemple, ils continuent à conseiller Prime95 pour la RAM (+ son contrôleur intégré au chipset ou au CPU)
Comme quoi

C'est pile poil ce que je voulais voir...  
 
On est donc d'accord pour dire qu'un seul test quel qu'il soit, ne suffit pas à pouvoir conscidérer une machine comme étant stable...
 
Et plus ou moins oK pour avouer qu'on stoppe les tests là où on le veut, et que donc la stabilité prouvée à 100% n'est présente chez quasiment personne...
 
Un type qui valide sa config avec des applications normales, sera conscideré comme probablement instable par les puristes des stress test, mais ne sont ils pas tout aussi probablement instables que lui en esquivant certains tests...?
 
Bon bah me reste plus qu'à tester OCCT v3 maintenant vu que Linpack se trouve dedans...

Kyosh1ro
 

 
Prouver sur Forum ça sert a rien du tout.
 
Rien que des Occt c'est bon pour ça.
 
 

occt et cpustress et pis c est tout...

Demandez-donc à un certain Pinto ce qu'il pense des validations OCCT & Co  
EDIT: retrouvé => http://forum.hardware.fr/forum2.ph [...] 1#t1696819

Bah franchement je multiplie les tests parce que j'ai pris l'habitude et surtout pour pouvoir "faire le tri" en cas de problème, mais sinon je pense un peu comme lui, les stress test servent à valider des situations qu'on atteindra jamais...

 
A partir du moment où la RAM n'est pas ECC le PC ne peut pas être garantie pour être stable.
 
Cependant les outils comme OCCT, CSMT & co permette de jaugé (de matière qualitative et non quantitive malheuresement) la stabilité du PC.

 
Non mais lui c'est un peu un comique. Faut pas non plus raconter n'importe quoi non plus. Un PC est stable quand il passe sans encombre l'utilisation qu'on est en droit de s'attendre d'un PC. Oui c'est con de faire tourner un PC des heures en cherchant a le faire planter. Mais c'est tout autant idiot de dire "moi je suis stable puis que ça fait pas de BSOD vu que je fait que du Word avec..."...
 
C'est comme dire qu'on est sportif en disant que notre niveau physique suffit pour les 5 minutes de marche à pieds que l'on fait dans la journée.

 
D'un autre coté dans la vrai vie on passe pas nos journée a burn, on bosse, on joue, on surfe, on fais du montage vidéo.... Si tout ce qu'on fait est stable, je suis d'accord que la valid OCCT ou autre est useless  
 
Me souviens de mon Q6600 totalement stable @3.6Ghz pds 10h d'OCCT, ou d'autres benchs, de 3D, de compression.... Par contre, fallait pas 30min pour me taper un méchant reboot si j'utilisais la virtualisation (vmware)... Au delà de 3Ghz la virtualisation ne passais pas...
 
Depuis, OCCT je l'utilise grand max 1h, si c'est stable, je passe a mes appli courantes les plus lourdes, voire plusieurs applis si 1 seule ne bouffe pas tout le système.

Alors là j'arretes tout de suite le raisonnement.
 
Dans la vie de tous les jours s'ils y a une erreurs, en fait, il est rare que le programme plante. Ce sont les données qui sont corrompus... Dans le cadre d'un encodage audio/video on aura un artefact, detectable ou non, dans le cadre d'un jeu peut etre un comportement etrange, dans le cadre d'une copie de fichier un fichier corrompu, etc.
 
Le fait est de OCCT/CSMT detecte si des erreurs arrivent. Les softs ne cherche pas a faire planter le PC mais simplement regarde si le PC fait des erreurs ou pas. Alors s'il en fait sur OCCT, rien ne nous garantie (bien au contraire) qu'il n'en fera pas dans un autre usage.
 
C'est comme ça qu'il faut raisonner, et non pas "si ça plante pas c'est que ça touren !" ... non ... trop d'erreur de protection windows de Win9x on été attribué à l'OS alros que c'etait simplement qu'a l'epoque on avait de la RAM de merde, des mobo pas tres tes evolué et globalement du matos loin d'etre fiable.

 
 
+1
 
 
c est bien pour ca que l on teste la stabilite, pour etre sur que le cpu calcule comme a stock...

Dommage de ne pas appliqué le principe " comme a stock " aux
températures.
 

http://www.xtremesystems.org/forum [...] count=1109

 
Non, les stress tests servent à faire en sortent que si ton PC est instable, l'erreur arrive rapidement.
 
Pour ça, il faut créer des conditions extrêmes.
 
Tout n'est qu'une question de probabilité. C'est une méthode très pragmatique, car on a rien de mieux, qui dit que si ton PC tiens le pire des cas, il tiendra le meilleur. Par contre, si ton PC ne tiens pas le pire des cas, il ne tiendra pas le meilleur. Pourquoi cette règle est valable ? Car on est dans un monde que l'on assimile à un monde scientifique. L'erreur se produit aléatoirement, donc on produit les pires conditions pour qu'elle arrive rapidement,k pour pas que tu poireaute comme un con devant ta bécane pendant 48h.
 
Je pourrais très bien faire un OCCT "Excel-like" à base de macro VB (bon, honnêtement, en rédigeant ces quelques mots, je me dis "sic, je vais me suicider" ) qui vérifie les résultats. Ca se rapprocherai plus de ton utilisation courante (admettons). Tu devrais alors attendre 1 mois que ton erreur arrive et soit détectée.
 
Et là tu me dirais "ton log sert à rien... j'aurai aimé le savoir vite, que mon PC était pas stable, qu'une erreur allait arriver quand je rédigeais mon mémoire, et que quand j'allais enregistrer, j'allais tout perdre !". Et tu aurais raison. Ce serait un logiciel, vraiment, vraiment merdique (ouf, j'ai réussi à le placer).
 
Ce que les gens perdent de vue, ce que si ton PC ne tiens pas le pire des cas, il ne tiendra pas le cas normal. Il mettra plus de temps à ne pas tenir le cas normal, mais ca foirera à un moment ou à un autre, fatalement.
 
Bref, OCCT force le trait sciemment, mais ca reste du pragmatisme à outrance, du tatillonnement, et honnêtement, je ne revendique rien d'autre.
 
Des fois, on a des surprises. Dans la v3, GPU:Memtest se révèle moins efficace que le test 3d à détecter... une mémoire instable. Pourtant, celui qui teste le plus la mémoire... c'est le 1er. Quand je te dis qu'on est pragmatique...
 
Multiplier les tests, sans forcer la dose, est une bonne chose.
 
A l'heure actuelle, CSMT, OCCT v3 en CPU:OCCT sont de très bon tests de stabilité pour moi. Prime 95, Orthos, des références vieillissantes.  
 
Memtest86 (+) est LA référence pour le test de la mémoire PC, point barre.
 
Linpack (et les Frontend qui en découlent : CPU:Linpack d'OCCT v3, IBT) : un test de burn (température). Tat : vieux et plus trop utilisable.
 
Furmark, GPU:3D, et ATITool, de très bons tests 3d. GPU:3d est surement le plus jeune et le moins abouti du lot, et ATITool souffre du manque d'update. Furmark est clairement le plus abouti (JegX est un dieu en 3d comparé à la quiche que je suis).
 
Bref, pioche, fais toi ton opinion, prends ce qui te plais, et fais ton petit test dans ton coin, honnêtement, tout ira bieng  
 
Personnellement, j'overclocke pas énormément (oui, je sais, je sais, c'est étrange, mais c'est comme ça...), donc un petit peu de CPU:OCCT pour valider mes 3 minables GigoHertz suffisent. De toute facon, je fais tellement de debug que si ca foirait, je le saurais forcément, le CPU s'en prends plein la gueule.

Pas cool...

Point de vue qui se défend, j'avoue être passé à côté de celui-ci...

Suis en train de finir le thread d'XS sur les Q9550 SLB6V (les E0)...
 
J'en sors au moins une info intéressante =>
 

Le mien est un L826B066
La fenêtre de tir était étroite mais j'ai réussi à passer

 
C'est quoi la moyenne en frequence ?
 

Comme tous les Quad 45nm (on je diraits...), de l'ordre de 4/4.1
Après, faut du VCore et la chauffe s'installe durablement
Puis faut du FSB mais les E0 prennent !

A 4 Ghz en moyenne, j'aurai pas pensé tout ça.
ça me parait beaucoup bien que je n'ai pas du
tout suivie Q9450 et 9550 tellement moisie au
début.
 

Globalement, ils chauffent beaucoup moins et acceptent un FSB bien supérieur
Cela est dû (apparemment) à leur VID, massivement @1.25V au lieu de - sur C1
 
Toujours en cours =>
 

 
Nota: légère baisse en fréquence
Tenterais un Linpack demain

avec 1.27 de vcore baisse pas la frequence monte le vcore plutot.
c'est pas du sucre.
 
1.3625 il me semble pour ce type de cpu.
 

N'oublie pas que je ne voulais pas + de 3.6 au départ
Alors j'ai déjà fait un pas, vais pas en faire 2, non + ^^
EDIT: en avant le pas  
 
Note que la fréquence a été baissée car j'ai diminué les sous-timings RAM mais ça passait très bien @3801 ...

 
Oui oui , je suis d'accord avec toi mais tes 1.27 me paraissent " leger " j'ai meme pas ça
sur un E8400 ( sécurité oblige hein on va pas planter betement au cas ou. )
 
85 degrès IBT 4Ghz.
 

Léger, c'est à dire
C'est en charge, faut compter l'offset einh après
 
Bon, c'est comme ça que je voulais mon York  
 

Du moment que tu es satisfait je le suis.
 

Je dirais que sur les quad non extreme on est surtout limité par la mobo et sa montée en FSB. Parce que a priori en C2D on fait ~4,5GHz stable en E0 pour le haut du panier. Alors qu'en 65nm les C2D et C2Q était finalement assez proche en o/c avec le G0.

1,450V sur le process 45nm Intel

LinPack ne passe pas
Trop de droop
Tant pis, le reste passe très bien
J'en reste là
C'est bien assez: 12Mo de cache et chauffe contenue, la consommation reste dans mes limites!
 
Wolfflyter > satisfait je  
!
 
MEI > le FSB sur 45nm apporte une autre limitation qui n'aurait pas pu être jugulée à cause de la 1ère - tasson le VCore nécessaire pour 4.1/4.2, qui est nettement en hausse !
De l'ordre de 1.38/1.42 environ (voire + einh )
& là, les consommations s'envolent et la chauffe, on n'en parle alors pas (plus)
En 65nm aussi, le problème c'était la consommation mais on montait moins en fréquence (ça compense )
Il y a eu et il y aura toujours sur Core2, une différence de 200/300MHz en moyenne entre Dual & Quad ...
Je dirais que c'est l'architecture avant même le process. de gravure qui est en cause
 
PS: l'histoire du VCore max., c'est 1.3625V conseillé et 1.45V 'toléré' (tout comme sur 65nm, 1.5V conseillé & 1.55V 'toléré')
Il ne faut pas voir ceci en charge par contre, sinon à avoir le 'Load Line Calibration' & autres 'Voltage Damper' etc.
Mais alors, gare à l'overshoot ...
C'est une histoire de norme de régulation INTEL je crois

C'est p'tet le NB Vcore qui chie sur Linpack aussi. A priori si OCCT "CPU" tiens et Linpack/OCCT RAM ne tiens pas vaut voir du coté FSB/NB.

& passer le FSB de 1.2>1.3 (j'ai que ça sur ma XFX ) et le NB de 1.45>1.5V
Tout ça rien que pour passer un test qui ne représente que 0.01% de l'utilisation de ma machine =>
C'est couru d'avance avec tous les tests que j'ai passés qui se sont révélés fiables...
LinPack = PowerVirus que même sur XS on ne reconnaît pas comme valide pour décrêter stable
Si je devais le stabiliser, ce serait pour revenir à mes settings actuels de toutes façons
Donc inutile de m'acharner là dessus
Je voulais une faible consommation pour du silence, je l'ai
Vais pas remettre en cause cette décision pour un test
 
PS: non, je pense que c'est le VCore qui descend toujours vers 1.26 qui le fait planter car trop de charge !

A partir du moment où un seul soft ne tiens pas le PC n'est pas stable c'est tout.
 
Faut arrêtez de se trouver une excuse quoi...
D'autant que comme déjà dit, le but de Linpack c'est pas de faire chauffer le PC mais de bencher l'Intel Math Library et essentiellement les fonctions Linpack de la bibliothèque.
 
Donc oui c'est intensif, mais non c'est pas synthétique, même si c'est plutôt réservé a des usages professionnels précis, l'Intel Math Library est utilisé dans la vrai vie.

Pas par moi ^^
 
EDIT: à propos de la différence entre C1/E0 (Quads), en température c'est facile -10°C, voire + qu'on 'peut' en attendre ...

 
Maxi
 
Et
 
http://processorfinder.intel.com/d [...] Spec=SLB8V
 
Normal