Reprise du message précédent :
Plus tu as de mémoire dispo pour le test et plus les données que tu envois à calculer peuvent être importante, il y a donc plus de possibilité pour que ton CPU/Mem renvoient une donnée erronée s'il sont instables.
Ce n'est pas qu'une question de dégagement de chaleur (dis moi si je me trompe )

D'où le fait qu'un test 25% est normalement moins "stressant" qu'un test à 50% et qu'un test à 90%....
En même temps, pour la fiabilité on est tous là pour échanger nos expériences

Ah ben ouai, je me disais bien que tu utilisais la dernière version !

@simsounet: Certains commentaires préconisent de lancer deux fois le test en même temps...

J'dit ça comme ça, mais y'a pas moyen d'utiliser l'Intel ML pour faire du Linpack (ou en fait toute autre lib qui fait du linpack, sans utiliser leur benchmark moisi (i.e le linpack.exe )

Ou alors, autre raisonnement : plus les données à traiter sont importantes, moins ça tiendra en cache, moins celui-ci sera stressé/utilisé, ce sera moins perf et donc moins d'opération/s par les unité de calcul du CPU, ce dernier sera moins stressé et chauffera moins. Il est possible qu'un Linktest 10% soit plus efficace qu'un 90% pour détecter l'instabilité du CPU, tandis que le 90% sera plus apte à détecter une instabilité mémoire (plus grande quantité utilisée, contrôleur RAM plus stressé).
Mais bon, difficile de savoir en fait, puisque ça dépend pas mal de l'algo et de sa façon de traiter toutes ces données. Il est aussi possible que ça n'ait que peu d'influence

Voici les images, j'avais lancé un test Linpack avant,réglé les sondes, j'ai redémarré l'ordi et voila ce que j'ai eu en relançant OCCT au niveau des sondes :
 

 

Montano5 > Non. Pour la simple et bonne raison que tu ne fais pas tenir 1Go dans un proco. Donc le dégagement de chaleur ne sera pas franchement beaucoup plus important avec 1.6Go de ram qu'avec 1.3. N'oublie pas qu'un accès RAM pour un proco est très pénalisant, lui aussi. Il arrivera juste plus vite au bout de son espace mémoire, et passera plus vite à le boucle suivante, c'est tout.
 
Franchement, 1.3 ou 1.6Go, en 32 bits, pour moi, même combat. Le 25/50/90 est arbitraire, et surtout, la différence est plus radicale. Honnêtement, hein.
 
De plus, je ne peux pas sortir ma baguette magique et faire tourner un programme dont je ne possède pas les sources (sic) pour le faire marcher avec 1.6Go de ram... partout... et détecter un cas d'erreur... indétectable. Sauf en me basant sur le % CPU, taux qui n'est pas fiable en soi (t'as un process qui se lance, qui bouffe le cpu,paf, je détecte une erreur là où il y en a pas).
 
Bref, pour conclure de mon coté :

• Jusqu'à preuve du contraire, linpack n'est pas franchement super efficace, loin s'en faut
• Pour plus de 1.3Go => OS 64 Bits
• Un linpack universel vaut mieux qu'un linpack supposé légèrement plus efficace (et franchement, j'en doute) mais qui foire sur des dizaines de configs, ce qui aboutira à des centaines de gens mécontents.

Quant à lancer deux linpacks en même temps, heu... de tous temps, on a vu ça (avec prime, avec OCCT,...), et franchement, je n'y crois pas un instant. Quand on a de l'HT, je veux bien, mais sinon...

Merci

Ce qu'il me faudrait, c'est un screenshot de la liste des sondes dans la page d'options (tu déroules les listes). "avant" et "après". A mon avis, il y a une sonde qui est détectée aléatoirement. Et comme OCCT se base sur la position de la sonde dans la liste pour sa config, ca décale tout.

A mon avis, si tu veux pas être emmerdé, tu fais un batch qui supprime le fichier ini à chaque redémarrage => redétection auto des sondes => pas de reconfig

Je pourrais me baser sur le nom de la sonde, certes, mais comment faire pour les sondes qui ont le même nom ?

De toutes facons pas sur par ex qu'en x64 avec 8Go utiliser le max de RAM (donc en gros 6,5Go) soit plus stressant pour le CPU qu'un jeu de RAM plus leger...
 
En fait ça depends si on veut avant tout stresser la RAM ou le CPU, comme d'habitude quoi.

 
Exactement
 
J'ai déjà essayé la compil, mais je me suis rendu compte que ce n'est pas le même linpack qu'ils mettent à dispo. En gros, tu as un truc non optimisé, qui chauffe pas bézef.

Y'a aussi l'effet ICL derniere version qui doit aider je pense.
 
Parce que si tu compiles sous VS2005/8 c'est pas pareil.

J'ai essayé sans succès

Bref, pa possib'

peut-être en se basant sur le vieux code fortran, ca par contre j'ai pas essayé (j'avoue).

OCCT PT 3.0.0.b22 OUT !
 
Au menu :

• Intégration de CudaMemTest v0.42 ! Progression en % dans l'interface OCCT. J'ai décidé de laisser la fenêtre DOS affichée pour cudamemtest.
• Linpack : en v32 bits, la ram max considérée est de 1.44Go. Ainsi, le mode 90% utilisera 90% de 1.44Go (soit 1.3Go), le mode 50% utilisera 50% de 1.44Go... etc.

Enjoy !
 
http://www.ocbase.com/download.php?fileext=beta
 
PS : je considère clairement cette release comme une quasi RC, il n'y aura plus de gros changements en dehors des traductions avant la stable, sauf si bug détecté bien entendu.

Je vais essayer de te faire les screens ce soir, je testerais en redémarrant l'ordi plusieurs fois pour voir si l'ordre des sondes change ou pas.
Pour le batch pourrais-tu m'éclaircir sur comment le faire? J'ai pas tout suivi  

Pour le test Linpack, quand il plante ça se passe comment sur OCCT? Sur IBT on observe la norme, sur ton logiciel c'est automatique? Il vérifie tout seul que la norme ne change pas?

Merci

Et encore un peu de HS Linpack/IBT : hier j'ai refait des tests pour voir jusqu'a combien je pouvais spécifier de ram à IBT pour qu'il lance le calcul, je ferme donc tous les process inutiles, il me détecte 2700Mo environ. Le 90% ne passe donc pas, mais j'ai essayé en fixant 1800, 1600; 1400, etc ., a chaque fois "Not Enough Memory". A 50% il ne marche plus, seul 25% passe ... Du coup je lance un OCCT Linpack dans la foulée, il marche avec un peu plus de 1300Mo de ram utilisé, quantité que je n'arrive pas à avoir sous IBT. Normal?

 
Et pour le bug de la non-detection quasi-systematique des sondes CPU en built-in monitoring ?

Ben un batch style :

Ca forcera la détection auto des sondes à chaque redémarrage de l'appli.

Pour linpack : oui, car OCCT utilise la version de novembre de linpack 32 bits, qui est plus tolérante tout en étant aussi efficace. La 64 bits est la toute dernière elle, car no soucy avec.

 
Ca a été réglé il y a quelques temps à priori

 
 
en b19 il etait toujours là    

 
Ah merde... t'as un screen ?

ah, je savais bien que je devais pas installer la 21.....
 
vu qu'une autre allait sortir.    
 
je prends    

 
 
Ce soir ou demain, because c'est sur ma P5E @home
Ici sur ma workstation XW sous Windows 7 ça marche

encore et toujours un grand bravo Tetedeiench pour ton travail

Pourquoi le test GPU m'affiche + d'FPS en 1440x900 (83) qu'en 1024x768 (64)
 
EDIT: 1680x1050 donne 64 aussi...
 
Test Power de pas moins de 6 minutes  
Par contre ça ne fait plus qu'une seule minute de test
 
PS: faudrait avancer un peu sur les trads. !!

 
Ben faut demander à Nvidia, j'en sais rien.
 
Pour ca, je ne comprends pas ce que ca veut dire :

 
A part que le test perso power supply de 6 minute revient à faire un test d'une minute effective avec les minutes de monito... ce qui est normal.
 
Quant aux trads, c'est en cours.

OK
 
PS: je balance pas les graphs, c'est horrible ...

OCCT PT 3.0.0.b23 OUT !
 
Au menu :

• Fichiers de traducs enfin à jour
• Traduction française enfin terminée

Enjoy !
 
http://www.ocbase.com/download.php?fileext=beta

bis repetita.    
 

ah, je savais bien que je devais pas installer la 21.....
vu qu'une autre allait sortir.    
je prends    

• pourquoi un ? derrière 'Générer les graphes' (et pas pour 'Créer les fichiers CSV')
• pointeur sur les cases orange & bleue (dans la partie Options) donne les messages: "Démarre le test" & "Arrête le test"
• morceaux choisis: "des période d'IDLE" ; "test dédié aux alimentation" ; "lancant" ; "rafraichissement" ; point ou pas point à la fin d'une phrase (supporte la détection d'erreurs...)  
• last but not least hin inh
• c'est tout pour l'instant

!

 
 
Alors voilà:
 
Je lance OCCT sur ma petite P5E  => le built-in monitoring ne liste aucune sonde pour aucun core de mon brave petit E8200

 
Entretemps, je change le built-in monitoring par un monitoring Everest (qui au passage fonctionne sans bleme), puis je referme OCCT, je le relance et remet le built-in monitoring => les sondes des core réapparaissent dans la liste

 
Mais - autre petit bug - lorsque je vais refermer puis relancer OCCT, meme si les sondes des cores sont toujours selectionnables, OCCT ne garde pas les preferences et s'obstine à me proposer la sonde du CORE1 pour la ligne du 1er core et ... celle du GPU core pour le second core !    
Je suis alors obligé de reselectionner les bonnes sondes (core#0 et core#1) et de faire OK pour avoir les bons graphes lors d'un stresstest du cpu (sinon ça donne l'impression que le second core s'est tourné les pouces... normal puisque ce sera la mesure de la sonde GPU qui aura passé tout le stresstest à gentiment buller autour des 50-55 degrés, à m'afficher le bureau Windows ou un pauvre screensaver    )

 
 
Evidemment, l'ancien OCCT 2.01 ne me fait pas ça: le built-in monitoring (et notamment cpu) fonctionne toujours en toutes circonstances:

 
C'est vraiment lié à qqchose dans les dernières beta.
Peut etre un truc du coté de la librairie HWMonitor (qu'exploite OCCT ?)
Je ne sais pas trop car HWMonitor semble toujours marcher et afficher tout ce qu'il est capable d'afficher :

 
Ca ne me gene pas outremesure car j'arrive à troubleshooter le pb, mais si je n'y fais pas attention, ca peut m'enduire dans de l'erreur    
Et peut etre que ca pourrait le faire aussi chez d'autres victimes de ce bug
 
 

 
@ben ouai olivier, mais j'aimerai comprendre !!
 
@tetedeiench: Je ne suis pas programmeur, sinon j'aurais déjà bidouiller quelques trucs à ma sauce, donc désolé pour les questions "connes"
 
D'ailleurs tetedeiench, je ne remets pas du tout en cause ton travail qui est impressionant et pour lequel on te remercie tous ! J'essaie juste de faire avancer le chmilblick
 
Je veux bien tester tout ce que tu veux dans les conditions que tu veux (on parle d'informatique, hein ) et essayer d'aider à trouver une solution; c'est juste dommage de sortir des tests (CUDAmemtest et Linpack) qui doivent être bridés et dont on ne connait enfin de compte pas la fiabilité.
 
Et pour le dégagement de chaleur, ça n'ai pas un des critères de stabilité pour moi. ATITools fait chauffer le processeur graphique bien moins que Furmark ou OCCT:GPU et pourtant semble plus fiable...

Voila moi aussi mes screens du bug des sondes :

Quand ça marche bien :

Quand ça marche moins bien   :

Apparemment la sonde CPUTIN vient jouer les troubles fêtes

Pour faire que ça marche pas j'ai du lancer HWmonitor avant, par défaut ça marchait cette fois  

Montano5 > ATITools n'est plus mis à jour depuis 2 ans
Je doute de sa fiabilité sur les cartes récentes...

J'ai essayé un batch, ça marche bien mais du coup j'ai le message "Cudamemtest will be disable blabla" à chaque fois, un peu lourd mais sinon nickel

Bonjour à tous désolé si mon post est un peu HS (je n'aime pas trop faire cela mais bon   )
 
Voilà je suis à la recherche d'un soft pour tester la stabilité d'un overclocking de manière réaliste. J'entends par là que OCCT pousse vraiment le CPU à fond et dans ses retranchements, hors je n'en viendrais jamais à cela, le pire que je puisse faire, c'est jouer à un jeu video (comme GRID, FEAR ou stalker) et encoder un film en X264 à côté (et cela est très très rare ).
 
Donc OCCT est-il capable de réduire sa charge excessive par rapport à un usage traditionnel ? Sinon connaissez-vous un autre soft qui en est capable Prime95 ... .
 
Merci beaucoup

CPU stress MT (la derniere version beta) détecte les erreurs CPU plus rapidement que OCCT...

J'ai fait un test CPU stress, il m'as trouvé une erreur au bout de 18 min et 58 min sous OCCT...

En fait c'est vraiment variable d'un PC à l'autre. Parfois c'est l'un parfois c'est l'autre. Sans compter qu'OCCT propose plus que que de tester le CPU.
C'est pourquoi il est conseillé de tester les 2, n'est-ce pas Tetedeiench ?    Vive les programmeurs français !

 
 
Avec OCCT tu peux stresser CPU/Ram/northbridge et maintenant aussi ton systeme vidéo. De plus, ton alim va elle aussi bosser pas mal.
Ce qui est deja enorme !
Toutes choses que tu feras egalement - et FORTEMENT - en lançant une session jeu + encodage.
En gros, par rapport à cette session, il manquera juste un peu de "stress" sur la partie sollicitations du disque dur, de la carte son, de la partie reseau (si jeu en reseau) ainsi que toute la partie entrées/sorties de l'ensemble clavier/souris.
Il est rare que ce soit des instabilités hardware à ce niveau qui peuvent provoquer des plantages en cas d'overclocking (sauf peut etre le cas typique où l'o/c est réalisé avec trop d'optimisme sur le FSB sans prendre soin de garder les frequences de bus pci/pci-e à des valeurs raisonnables : à ce moment là, des peripheriques comme la carte son ou le disque dur peuvent perdre les pedales). Il est par contre beaucoup plus frequent que ce soit des dysfonctionnements logiciels qui les fassent planter (les API ou les drivers de carte son ou reseau sont parfois codés un peu ... leger on va dire. Ca depend du constructeur .... )
Idem pour les codecs de codage.
 
Pour resumer, si ton PC tient le choc sur un soft style OCCT, il a toutes les chances de tenir une session jeu + codage.
Cependant il existe des softs dediés plus specifiquement à un test complet du PC.
Par exemple PassMark BurninTest qui permet de tester simultanement cpu/ram/disque/carte son/carte video etc... suivant ce que tu lui demandes de tester.
Mais d'une part il est payant, et d'autre part certains de ses tests sont quand meme assez "legers" pour valider correctement la stabilité d'un systeme. Je pense par ex que la partie test du systeme graphique est bien trop legere et ne rend pas compte de la complexité et du stress imposé aux cartes graphiques dans les jeux gourmands d'aujourd'hui.
 
Sinon tu peux te faire des "toolboxes" personnalisées avec des soft ou des fonctions que tu as forcement déjà avec ton systeme: par exemple lecture de fichiers son en tache de fond (avec de preference une playlist allant chercher des fichiers sur le disque dur, la clef usb, le lecteur dvd et pourquoi pas le reseau ou l'internet), pendant que tu lances un encodage et quelques passes de 3dMark en boucle. Si deja ça passe comme ça, tu as une idée de la stabilité de ta machine "en situation"
 
Voilou  

 
C'est vrai qu'il n'est plus mis à jour, il y a plein de logiciels qui n'ont pas de mise à jour plus récentes et qui sont tout de même excellent.
De plus Ray Adams a repris à sa façon ATITool avec AtiTrayTools. Ray a gardé le moteur de détection qui est exactement le même qu'ATITool (mis à part l'objet 3D) C'est devenue une référence dans la communauté ATI.
 
D'expérience, ATITool n'a pas un comportement erratique: tant que tu ne dépasses pas une certaines fréquence il ne détecte pas d'erreur et à partir du moment où tu la franchis il te détectera toujours des erreurs. C'est déjà rassurant par rapport à sa fiabilité.
Ensuite, lors de mes tests entre ATITool, Furmark et OCCT:GPU, j'ai pu par la suite vérifier en jeu les erreurs données par ATITool (sauf à 976Mhz)
ce qui, pour moi, valide ses résultats.
 
Même comportement pour IBT. Là où il faut 8h à ORTHOS et quelques heures à OCCT et CPUStressMT pour détecter une erreur, il faut 10mns à IBT pour la trouvé. Et quand ORTHOS, OCCT et CPUStressMT ne signalent plus d'erreur, IBT n'en signale plus non plus. Donc IBT (et le test Linpack) me semble fiable puisqu'il a le même comportement que les autres, sauf qu'il est bien plus rapide.
 
J'aime bien OCCT et je trouve que c'est une bonne idée de tout intégrer. Mais ce serait cool que quelques personnes prennent le temps de tester Linpack et CUDAMemtest en situation d'overclocking parceque, toujours à mon avis, CUDAMemtest n'est pas fiable (en overclocking) puisqu'il est le seul à ne m'avoir trouvé aucune erreur. Et je vais tester à fond le test Linpack de ce pas...

Osef pourquoi il est connu, le fait est que ATI Tool detecterais apparemment mieux les erreurs que OCCT, en faisant moins chauffer le GPU

 
Je veux bien que Ray Adams suive le sens du vent et qu'il soit passé de Nvidia à ATI.
Le programme est très complet et fournit non seulement des options non disponibles par les catalyst effectivement et d'une façon bien plus légère que les CCC, mais il fournit aussi des options d'overclocking directement repris d'ATITool (et le même moteur d'analyse d'erreur).
Même si ATT ne fait pas que de l'overclocking (et heureusement) tu ne peux pas nier que le moteur qu'utilise ATITool pour analyser les artefacts soit entièrement intégré à ATT et ce dès le départ de sa programmation.  
ATT propose d'ailleurs en plus de faire un bench avec ce même moteur, chose qui n'est pas proposé par ATITool.

Il y avait donc bien incompréhension.

Perdez pas non plus de vue que OCCT GPU, même si il est sorti deux ans après ATITool, n'est qu'à sa première version, fait par un dévelo qui a eu 4 mois pour apprendre la programmation 3d (donc, on peut le dire, carrément merdique), et qu'il ne peut qu'être amélioré... car je suis encore vivant et tout.

C'est clairement mon but une fois la v3.0.0 sortie : ne plus trop trop toucher à l'interface et me focaliser sur les tests...

La stabilité de ton PC n'est pas fonction de son utilisation.
Si OCCT dit qu'il n'est pas stable, il n'est pas stable.
 
Sauf si tu veut des artefact dans tes fichiers x264, tu réduis ton o/c et c'est tout.