Reprise du message précédent :
@Intouch :  

J'ai lancé un test avec un OC qui n'a encore rien prouvé du tout :
 
E4400@3,4ghz à 1,525v
 
J'ai lancé le test par défaut de 30min, OCCT ne me détecte aucune erreur pendant 20min, puis d'un coup il se ferme avec le charmant message :  
 
OCCT.exe has encountered a problem and needs to close.  We are sorry for the inconvenience.
 
Mmmh je suppose que ça veut dire que mon OC n'est pas stable ?    
Je n'ai aucun fichier d'erreur généré dans le dossier de la beta...
 
Ca veut dire quoi ça ?
 

et code 1, c'est quoi ?
 
vient d'avoir un code 1.

Robbb> Bug OCCT ou PC pas stable
T'avais le monitoring avec (au hasard Everest) ?
Si aux fréquences par défaut, tout va bien, alors tu connais la réponse

Ah oui oui tout va bien aux fréquences par défaut, mais je pensais que OCCT devait signaler les erreurs, je ne pensais pas qu'il allait lui-même être victime d'une erreur l'empêchant de faire son boulot ! !p

Et oui monitoring avec Everest 4.20 activé.

J'ai eu un code1 également cet aprèm !

Pourtant c'est possible. L'idéal serait que la partie qui contrôle les calculs tourne sur un autre PC (et stable lui)

Le code 1 fait son retour avec la b06 !!!
 

 
++

Hmmmmmmm

C'est normal: système très instable induisant des crash "graves". Même Orthos ou Prime peuvent les subir

chez moi si je pousse un peu trop le cpu : mon pc reboot au milieu du test ( alors que le reboot auto sur ecran bleu est desactivé )
 
la limite ets super nette :  
3.7Ghz rock stable
3.75Ghz : reboot

A mon avis 3,7GHz c'est pas du vrai Rock Stable.

ben tu as tord
stable 3D ( 3Dmark , UT3), occt ( 8heures cpu + 8H cpu et ram   ), double super pi 32M
 
et je tourne en H24 depuis 2 mois à cette frequence

8H d'affilé c'est pas non plus la mort.  
 
Perso j'ai plus de 150MHz entre rock stable et maxi je passe les 30 min d'occt.

Je passe en coup de cvent, j'ai pas le code sous les yeux, mais AMHA, code 1 = pas assez de ram dispo, bizarre qu'il affiche cela alors que OCCT a pas empêché de lancer le test.

Pas assez de ram dispo !!!!
J'ai 2Go installé et après démarrage, XP n'en prends qu'environ 300Mo donc reste 1.7Go.
Il faut que tu m'expliques
 
Edit:
Gestionnaire de tache après démarrage XP (Ram dispo : 1.7Go)

 
Gestionnaire de tache après démarrage OCCT (Ram dispo : 1.2Go)

Pareil pour moi, j'essayerai de reproduire, mais j'ai 2go de ram, et OCCT est loin de les utiliser en entier.

 
J'aimerais juste être éclairé comme je vois que les bug ou OCCT quitte sans generer de code valable continuent (en attente que je monte mon HR-05 recalcitrant pour retester OCCT)
 
OCCT lance un thread par core. Si un thread trouve une erreur de calcul ou RAM lors des verifications, un code est généré, là c'est tout ok
Maintenant, si en raison d'un OC instable, le thread crash/fermée: que fait OCCT, que génère -t il dans cette eventualité. Peut-être que c'est la le problème
 
Et puis l'expression AMHA (A Mon Humble Avis) signifie que tu ne sais pas ou est ce code 1?? Il doit bien être dans ton code source quant même    
 
Juste quelques questions pour essayer de comprendre ce debugging et les résultats qu'il peut generer
 
A bientot

comme il le dit, il n'a pas le code sous les yeux au moment de la reponse  
 
donc il y aura confirmation  
 
de toute maniere, une instabilité généralisé qui fait planter le coeur meme d'oct aura des effets de bord indésirable. OCCT / prime95 , .. .servent a tester les machines qui ont l'air stable, meme en charge "normale" : web, lecture divx,...

Moi quand c'est vraiment instable le PC reboot ou fait un écran bleu avec des messages variés
Bien diversifiés quoi comme symptomes, signe que les erreurs peuvent être multiples et que même OCCT n'échappe pas à ce qui se trouve devant lui : le hardware et l'OS
Rappel : il faut tester +ieurs programmes pour décrêter le 'rock stable' cher aux utopistes

Voui, moi je fonctionne avec Orthos + OCCT (comme beaucoup) et il n'est pas rare que Orthos me déniche des erreurs après 1h, alors que je sors d'un OCCT de 8H. Ou l'inverse !  
 
Bon je viens de faire un OCCT de 18h en mode infini avec un OC jamais validé auparavant. Aucun problème. Là je recommence le même test, avec le même OC, mais en diminuant mon vcore. Je vais tenter de rendre toussa instable pour voir ce que la bête me donne comme code d'erreur.
 
J'utilise le mode par défaut (128mb data size).
 

Avec la 1.2.0.b06, j'ai souvent des codes 1,... avec 2Gb de ram (config par défaut).
Avec la version précédente, stable.  
 
Dans Everest Ultimate 2006, je n'ai pas trouvé le paramètre 'appli externe'. Peut-être est-ce une nouvelle version.
 
Je teste OccT sur un P4 3GHz hyper stable.

 
Ben plusieurs choses en fait

• OCCT est pas mon métier, j'ai une vie à coté... et justement, il m'arrive de répondre du taff. Donc sans le code source car je suis au boulot. OCCT, c'est plusieurs dizaines de milliers de lignes de code, et donc non, je n'ai pas en tête en permanence tous les codes d'erreur... surtout que je les ai modifiés très récemment. Comme je suis réactif, je réponds avec le AMHA car je n'ai pas le code sous les yeux, et je confirme quand je peux. Souvent le soir.

• Un PC instable est un PC instable. On ne peut pas prédire où l'erreur se produira. Si l'erreur se produit sur les calculs énormes lancés par OCCT ( ce qui arrive souvent), OCCT le détectera (résultat erroné) avec un code approprié. Si un thread crashe comme un con (i.e. erreur dans le flot d'instructions), OCCT interprêtera ça aussi comme une erreur de calcul. Par contre, si l'erreur arrive sur le process de surveillance, de monitoring, là, je peux rien faire, OCCT crashera totalement, et point. D'où le message d'erreur "OCCT doit fermer blabla". Donc oui, OCCT peut toujours crasher directement sans détecter d'erreur. La plupart du temps, voire 90% du temps, ca n'arrivera pas, ou le PC freezera avant. mais ca arrive...

Comme on est en phase de débug, il se peut qu'OCCT renvoie un "1" dans un cas imprévu (chuis pas infaillible). 1 est censé être le code d'erreur "j'ai pas réussi à allouer ma mémoire" (encore une fois, je suis au taff, je peux pas vérifier). Ici, ca n'a pas l'air d'être le cas. Il faut que je trouve ce qu'il se passe donc, et que je comprenne si cette erreur 1 est "normale".
 
Pour ceux à qui ca arrive, ce code 1, pouvez-vous me donner :

• Votre proco (notamment le nombre de coeurs)
• Combien ded RAM dispo avant de lancer le test
• Le contenu des fichiers threadX.txt  (pour chaque) juste après avoir eu l'erreur.

Merci d'avance

Salut iench,
 
Code 1 chez moi avec un E6750, 2Go Ram sous xp pro sp2.
Ram dispo avant après démarrage XP -> 1.7Go.
1.2 après lancement occt.
 
Code 1 dans le thread0.txt
Code 4 dans le thread1.txt
 
++

 
Code 1 : le thread s'est arrêté car un autre thread s'est arrêté
Code 2 : l'utilisateur a demandé l'arrêt global
Code 3 : Problème de mémoire
Code 4 : erreur de calcul
 
Donc en fait, un thread génère le code 4, donc s'arrête. Le second voit que son potos s'est arrêté, et s'arrête aussi. Par contre, le code final affiché par l'interface est le mauvais : elle devrait afficher 4 (qui est l'erreur principale) au lieu de 1 (qui doit être oublié ici).
 
Êtes-vous sûrs de la stabilité de votre paicai pour ceux qui ont ce code ? Vous dites que la b05 tient mieux que la 06

J'ai trouvé comment corriger la b06, par contre, j'ai pas le temps de le faire, release demain matin
 
Effectivement, les codes d'erreur sont mal combinés à la fin, par contre, ceux des fichiers txt sont bons

 
J'ai failli etouffé. Je comprends, je ne pensais pas autant. Je suis sidéré

Je peux faire le compte, mais bon, ca doit être ça...

Du coup, tu comprends mieux que tout avoir de tête c'est déjà po mal ? En fait, réussir à s'organiser pour trouver rapidement ce qu'on cherche, c'est déjà quelque chose... heureusement que c'est le cas (et c'est LA différence entre la v0 et perestroika, perestroika a une architecture relativement organisée).

Je file, je fais une bouffe avec mon pote d'amour préféré, je vous ferai probablement une release demain, au pire samedi

En meme temps ça va vite.
Surtout si c'est codé proprement.

Doit y avoir les 3/4 de commentaires

+ les sauts de lignes

Les espaaaaaaaaaces

 
Voila le logiciel qu'il faut au iench
 
Et interdiction de compter les librairies Qt ou autre qui n'aurait pas été le seul produit de ton dur labeur

12520 rien que pour l'interface/le monitoring et co.

Et sans compter les modules que j'ai créé d'ailleurs (ce sont des projets à part), c'est à dire les composants skinnés et mis en mode unicode, etc... fusion de jvcl et composants tnt à la mode iench.

 
   pour l'explication !
 
En ce qui me concerne, je savais que c'étais pas stable, je testais occt pas mon o/c

 
Ah d'accord
 
Donc ce n'était pas un "faux positif". Je vais corriger le bug de renvoi du code d'erreur demain, chuis crevé...
 
Bonne nuit à tous et merci encore !

25000 en total grosso merdo, pas mal.
 
Allez zou dodo

Au fait, c'est normal que l'indicateur de charge CPU soit maintenant divisé par deux sur la beta b06 par rapport a 1.1.1b ?
(meme si la charge CPU est bein a 100% dans le Task Manager)

 
Le bug a été déjà signalé, mais merci de me confirmer ce que je pensais : j'ai tout changé de ce coté là, et y a des soucis, la valeur est mal calculée...
 
Prochaine béta
 
Ce bug ne concerne que de l'affichage de toute facon

Dacodac  

Bon je suspectais un peu la dernière béta d'être vachement tolérante avec mes derniers OC "osés". Du coup je me suis lancé dans une petite procédure de tests/comparatifs entre la 1.1.1 et la 1.2.0.B06.

Configuration de test :

E4400@3,3ghz à 1,750vcore

Il y a quelques temps, j'avais tenté de passer cet OC, et ne pouvant atteindre la stabilité avec un vcore (in Bios) de 1,475, j'avais abandonné et je m'étais rabattu sur mon petit 10*320mhz stable à 1,445v, parfait pour une utilisation courante. A l'époque c'est OCCT et Orthos qui m'avaient bien fait comprendre que l'oc n'était pas stable...

Depuis le pc a tourné, et l'hiver étant déjà fort présent, la température ambiante de ma pièce à pas mal baissé, avec les conséquences que l'on connait sur les températures des CPU !  Du coup hop je me suis dit que j'allais retester quelques petits OC avec vcore de marcassin histoire de...

C'est comme ça que j'en suis arrivé à stabiliser mon E4400 à 3,4ghz avec un vcore de 1,535, et que j'en suis arrivé à chercher le voltage minimum que je pouvais utiliser pour un oc à 3,3ghz. En utilisant la beta06 donc, je suis parti de 1,505, et j'ai descendu les échelons : 1,495 (stable), 1,485 (stable) puis enfin j'ai testé le fameux 1,475 que je me rappellais avoir testé infructueusement il y a quelques temps... Et à ma grande suprise le résultat était clair : stable pendant 8h en mode CPU (very small data size). Au début j'ai simplement cru que mon CPU s'était peut-être rôdé un peu, mais j'étais quand même sceptique !  
Alors dans le doute, ce matin j'ai testé :

Ce même oc sous Orthos : Blue Screen radical après 2minutes de test.
Ce même oc sous OCCT 1.1.1 : Erreur détectée après quelques petites minutes.

Je relance un test CPU avec la beta06, et ça repart comme en 40 sans donner signe d'instabilité. Alors quoi ? Cette dernière beta serait-elle un peu trop tolérante ? En tout cas dans son mode CPU only... J'en sais rien, mais je me suis dit que ça valait le coup de signaler cette incohérence

Essaie en mode CPU&RAM ou supérieur, tu verras...

Je pense que le test CPU de la 1.1.1 passe aussi, donc compare sur les mêmes bases

Merci pour les tests, mais le test CPU a toujours été moins performant que les autres, il stresse moins de composants en fait