Reprise du message précédent :
PC Stable 30 minutes avec 4 fichiers Thread X.txt ayant Code : 2 dedant.

Alors,
 
1 h de test ram ok avec la b02.
Je lance la b03 et reposterais...
 
++

C'est vrai que c tellement mieu qu'avant, domage pour moi
Le test RAM passe tjr en timing 5-5-5-18, mais pas en 4-4-4-12 meme en 2.1v
Pourtant les autres programmes passent en ces timing
Donc voici la 1.2 b02 avec les bon timings, pas de crash
 

 
Je resteste la b03 avec 5-5-5-18 puis avec 4-4-4-12 et repost les screens
Mais bon, je m'oriente de plus en plus vers mes barrettes instables comme avait dit Bierman, aucun autre programme ne detectait d'erreurs pourtant

Stable 30 minutes avec la b03 en mode RAM.

EDIT: Toujours @ 3.6GHz @ 1.46V (pour être sûr d'être stable) et 800MHz en 4-4-4-12 pour la DDR2 à 2.10V.

J'avance sur le problème d'utilisation CPU, mais à mon avis, pas de fix avant ce soir

RECTIF : dimanche soir au mieux Essayez néanmoins le comportement de la b03 coté test, le % CPU est pas important pour les test, c'est que de l'affichage !

Erreur de detection des infos système sous Vista:
 

Oui j'ai le meme problème

Nickel sous Vista 32 bits chez moi (b03).

 
Moi aussi, tout bien détecté sous Vista 32 bits
 
Je ne vois que le bug d'affichage taux CPU
 
Alors voilà, lancé un 2ème test avec la 1.2b3 aux timing 5-5-5-18: 2h puis fini avec mention stable et 4 fichiers threads code 2 chaqu'un

En plus, cette v1.2 est mieux que les dernières beta 1.1.2: le PC est utilisable car les précédentes mobilisaient trops de ressources PC et meme surfer devenait penible
 
 
Je lance un test de la 1.2 b03 avec mes timings (instables) 4-4-4-12 pour voir

Je suis aussi sous Vista 32, allez comprendre  

Petit retour de mes tests de cette 1.2.0.b03
Les 3 modes ont été passés : CPU&RAM, CPU, RAM
Tous @2860MHz, ma fréquence qualifiée instable sur les anciennes beta...
Tous ont généré les 2 fichiers Thread0.txt et Thread1.txt dont le contenu était : "2"
/!\ en mode RAM, OCCT n'a JAMAIS dépassé 257Mo d'occupation !!!
/!\ notez que malgré la sélection dans les options de chaque mode, il apparaît que ce n'est que CPU&RAM qui ait été lancé
 

Par acquis de conscience, je vais quand même revérifier avec la 1.1.1b si mon o/c @2860MHz est bel et bien instable ou si par miracle, dû aux dernières betas il soit devenu (ou alors par magie ), STABLE

Sous Vista 32bit, il faut être en mode administrateur ou faire un "Run as administrator..." (accessible par bouton droit).
La signature du driver n'est nécessaire que pour Vista 64bit.

 
Bien vu    
Je dezipe jamais OCCT c'est donc pour ca  

Retour de mon test @2860MHz avec la 1.1.1b => bel et bien instable !!!
Code '3' dans "error.dat"
 

 
Notez qu'Everest a planté avant la fin mais j'ai laissé quand même tourner OCCT pour vous montrer ...
J'ai tout de suite après lancé en mode 'RAM' et le plantage n'a pas loupé mais après.., 17 secondes de test
 
Conclusion perso concernant la 1.2.0.b03 :
 

• bien + permissive que la dernière stable
• est bugguée sur la sélection des modes

En cours je taffais ce matin, très tôt

 

 
Vista 32b
Q6600 + 3.xxgo de ram (vive le 32b )
Mode Cpu&ram par défaut, 30min...

 
Pas chez moi
 
Et effectivement, le mode RAM passe ême a 4-4-4-12 maintenant, stable 2h

Bon chez moi aussi c'est l'hécatombe pour le logiciel du iench. Je fais tourner un test RAM actuellement, il ne prend pas plus de 128Mo de RAM et indique une utilisation de 0% de CPU contrairement au gestionnaire de taches qui indique 99

 
Pour moi non plus, no soucy (+900Mb de RAM utilisée)
 

 
Plus de problème en 4-4-4-12 @1.95 vDDR, 3 tests de 2h, stables
Pour moi, ainsi OCCT s'affile avec les autres outils de benchs, ce qui m'arrange bien: PC Stable
 
Bon, le Iench, courage à toi
 
J'attends les autres betas pour retester avec mon OC qui est dans la signature

 
+1 voir  
http://forum.hardware.fr/hfr/Overc [...] m#t1636896

 
Je vois ce que c'est: mode CPU=128Mb RAM environ, ce qui est normal...

 
Peut-être qu'elle est plus permissive si elle détecte les erreurs plus tard que les autres betas.
 
Perso, je pense que 30mn pour dire PC stable, c'est un peu gonflé. S'il est très instable, c'est vrai qu'en 10mn la plus part des erreurs surviennent.
 
Ce que je propose:
Mode Auto 30mn: Fast OC stability test (permet de tester rapidement un OC en cours)
Mode Auto 2h: Test stabilité intermédiaire (PC relativement stable)
Mode Auto 6-12h: Test final à effectuer pour valider un OC definitif
 
Beaucoup de gens vont sinon accuser OCCT de déconner car en 30mn il leur a promit un PC stable, ce qui est vraiment illusoir

 
Bon, comme je ne peux plus génerer d'erreurs pour l'instant (le code des threads semble bien marcher en tout cas) et vu que pas de betas jusqu'à demain soir, je vais démonter ma CM. Mes HR0x machins arrivent début sem prochaine. Vu le temps limité que j'ai, je vais démonter la CM en avance pour pouvoir les monter dès la réception.
 
Alors, bon debugging et je suis de retour milieu / fin semaine prochaine pour tester la version qui sera en cours alors
 
Bon travail, à tout bientôt
 

Tu n'étais surement pas présent mais un sondage avait été édicté (car la question s'est posée très vite...) par Tetedeiench concernant la durée que l'on estimait 'raisonnable' pour décréter un o/c stable sous OCCT
Les durées qu'OCCT propose actuellement sont issues de ce sondage
Cela n'empêche d'ailleurs absolument pas chacun de choisir une durée réglable dans les options si la durée maximum proposée par défaut lors du 1er lancement d'OCCT ne suffit pas (1 heure, choix de la majorité des Forumeurs et 30 minutes en 2nd choix, donc)

La plupart des retour négatif sur OCCT que j'ai lu ici et là était dû à cause de ça. Le test par défaut d'OCCT leur indiquait "PC stable" alors qu'Orthos par ex leur indiquait une instabilité au bout de 2h. Cela ne leur sautait pas aux yeux que comparer un test de 30min avec un autre de plusieurs heures, ce n'était pas équitable. D'autres cas aussi où il doutaient de la fiabilité d'OCCT puisque parfois le test passait, parfois non.
La valeur par défaut de 30min agit clairement en défaveur d'OCCT  
C'est pour ça qu'avec CSMT je met par défaut en mode "infini" et que la durée minimale pour afficher "PC stable" est d'1h.
 
BIERMAN> J'aimerais revoir les résultats du sondage car il me semble pas que Tetedeiench est modifié la durée du test par défaut en fonction du résultat.

Il n'avait pas duré, la discussion étant ultra polémique, Tetedeiench avait 'tranché' (de mémoire)
S'il n'a rien changé c'est pour laisser le libre arbitre aux utilisateurs
Un nouveau sondage créerait une polémique et c'est normal, nous n'avons pas tous la même opinion concernant la stabilité !
Avec certains prétendant que parce qu'ils ont eu des erreurs au bout de 8 heurs ou +, il FAUT que ce soit la durée minimum proposée par défaut
Et évidemment une durée aussi important ne saurait convenir au plus grand nombre
Actuellement 30 minutes et 1 heure vont bien pour se faire une idée si l'on sait régler sa machine !!!
Le public visé est bien celui des o/ceurs mais nous n'avons pas tous le même niveau ni le même matériel et plus que tout, les mêmes idéaux concernant l'utilisation que l'on en fait...
Sujet polémique que j'te dis

 
Pas si mal donc ma proposition... bien sur les durées que je propose peuvent faire l'objet d'un autre sondage    
 
Le hic c'est que depuis les C2D et les nouvelles CM, l'OC est devenu plus accessible
Regardez ici:
 
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
Le mec il a investi dans un QX6800 et un DOD, et il ne sait même pas ce qu'est un OC!!!!
 
Du coup, OCCT devrait s'adapter à ce nouveau public je pense.
 
Sur les forums anglais, c'est le principal reproche effectué à l'encontre de OCCT en tout cas. Moi, je n'ai jamais pensé l'utiliser non plus, car on m'en a tjr dissuadé...  
Si j'y suis dessus, c'est que mon OC n'était pas testable sous Prime95 vu températures de chipset, et je voulais voir ce qu'en pensait OCCT. Du coup il me trouve des erreurs RAM... et la passion est partie :-)
 
edit: bon, là je vais démonter la CM pour finir ce weekend en beauté

Ca m'étonnerais qu'il descende sous les 0° avec un QX sous peltier
 
Et encore, on sait pas si ila  isolé sa mobale ou quoi... Ca me dégotue un peu, un QX déja, spas pour les noobies, alors avec un sli de 8800 et une striker...

L'o/c n'est pas plus accessible aujourd'hui qu'avant, enfin y'a pas eu de grosse nouveauté depuis 2-3 ans.
 
C'est juste que y'a plus de blaireau qu'avant. Et désolé, mais un outil pointu n'as pas a s'adapté au kéké qui vient de foutre 2000€ dans son CPU et qui l'o/c pour montrer qu'il a la plus grosse. Notament parce que ce genre de personne n'aura pas la volonté de s'en servir. A mon avis celui qui veut utilisé un outil comme OCCT et se lancé dans l'o/c il doit le faire en commençant par aprendre les "basics" comme on dirait en anglais plutot qu'etre pris par la mains. Trop simplifier ca veut dire perdre en fonctionnalité/possibilité souvent et ça c'est mauvais pour un outil qui à la vocation d'OCCT.
 

Accompagnons OCCT d'un pamphlet expliquant ce que vise le soft et ce que signifie le resultat et le pourquoi du comment un PC peut faire des erreurs et ça reglera la chose.
 
Deja sans RAM ECC, d'un point de vue theorique, il suffit d'attendre assez longtemps, mais il y a toujours un risque qu'un bit de RAM change tout seul, et sans correction forcement tot ou tard ca peut entrainer une erreur.

Deja le mec qui utilise un Peltier aujourd'hui il a pas compris, c'etait bon pour les P3/Athlon Socket A et encore, le peltier passé 50-60W à dissiper c'est tendu du slip, et avec un C2Q o/c qui va dissiper entre 150-200W faudrait un peltier de 250W pour etre sur, bien isolé et une alim pour peltier de dingue (et etre capable de dissiper 250W sans probleme), bref autant de contrainte pour au final si on les maitrise mal des perfs inferieur a s'il n'y avait pas de peltier.
 
Ceci dit un peltier pour une GF8800 WC par contre ça peut etre tantable. mais faut pas etre un noob.
 

J'ai du mal à suivre ton raisonnement là, une 8800 Oc ça consomme aussi dans les 150W voire +, donc pourquoi aurait-elle droit au peltier elle et pas le C2D ?

Une 8800 ca consomme 150W mais tout compris, le NV I/O, la RAM, etc. Le GPU il doit pas dissiper plus de 50-75W. Sinon le radiateur serai largement pas suffisant vu la "faible" ventilation.

 
Effectivement, un peltier sur un C2Q fortement overcklocké n'est pas recommandé. Le rendement est très faible passé 100W, et un peltier est moins performanr qu'un WC en dessus des 200W à dissiper
Je suis même très généreux la, car selon Swiftech, 130-150W et dèjà un Peltier sort la langue. Et on voit bien, que comme dit MEI, en dessus de 50W-70W, le rendement est minable
 
http://www.swiftech.com/assets/ima [...] -GRAPH.png

Les rapports sont plutot bons, c'est cool
 
J'espère avoir un fix pour l'utilisation CPU ce soir.
 
Pour bierman : tu es sûr pour le test RAM ?
 
Pour le problème de performance de l'algo : chauffer ne veut pas dire bien détecter une instabilité. Prenez TAT, il fait pas grand chose de ce coté là.
 
J'ai encore quelques doutes coté priorité, cela peut expliquer la différence de "sifflement" noté chez quelques uns... j'ai remarqué que OCCT tournait avec une priorité légèrement plus basse qu'habituellement (à vérifier encore).
 
Merci pour tous vos tests   Sans vous, OCCT n'en serait pas là !

 
Je suis toujours à la recherche de quelqu'un pour rédiger une aide rapide, un tutoriel, que j'incluerai avec OCCT (format hlp, html par exemple).
 
J'ai pas assez de temps pour m'y mettre
 
J'espère implémenter ton slider bientôt

 
 
 
Fallait que je passe pour poster car je me suis bien poilé avec OCCT ce WE   .
 
 
J'ai eu droits à 2-3 messages comme quoi j'avais pas lancé Everest avant OCCT et du coup que c'est à cause de moi que les programmateurs en bavaient   .
 
 
Pour être + sérieux, Orthos me donnait un OC stable pendant 1h30 alors que le test de 30min OCCT m'a révélé des problèmes de virgule flottante et donc j'ai du réajuster mon vcore pour stabiliser pour de bon   .

 
C'est ça que j'ai eu   . J'ai eu également une chute de tension   .