Reprise du message précédent :
Non... j'ai regardé la tete que ca avait en russe sympathique
 
Dommage sinon pour la mise a jour automatique mais d'un autre coté tu n'as pas tord... Les gens s'en servent pour overclocker (comme moi) puis arrete lorsqu'ils ont trouvé une fréquence qui leur convient (qui est donc stable). Après c'est toujours un plus si tu t'ennuis et que tu n'as plus rien a faire de tes journées. Comme ca si je veux tester mon proc 5 mois plus tard : pouff mise a jour automatique Et c'est quasiment sur que cela arrive. mon E6600 n'a pas encore tout dit

 
Bonjour,
 
Je proposerais 2 choses qui tournent autour des graphes :
   - possibilité de générer des graphes même en cas d'erreur.
   - avoir 1 graphe supplémentaire, "paramétrable" (choix du nom) par l'utilisateur pour pouvoir visualiser une autre tension ou une autre t° que celles proposées par défaut (Vram, t° chipset, …)
 
@+
 

 
1- Pourquoi pas
2- J'avais jamais abordé le problème sous cet angle. Vendu. 1.0.3 Powered. D'entrée.

Salut,
 
J'ai besoin d'une interprétation d'experts sur les résultats que j'obtiens avec OCCTPT. Je vais essayer d'être complet sans être trop long.
 
 
Config :
- CM Abit KN8 SLI -dernier bios.
- AMD X2 4400+ . SPD : FSB = 200 MHz ; coéf = 11 ; Vcore = 1,35V.
- 2 x 512 Mo de Corsair TwinX 3200XL (puces Samsung TCCD certifiées 2-2-2-5 à 200 MHz)
- Alim Seasonic S12 500W.
(logiciels utilisés : OCCTPT 1.0.1 ; CPUStress 0.45 ; Orthos beta)
 
 
Tests effectués :
- RAM : 265 MHz (2,5-3-3-8 1T) Vcore d'origine ; 12 heures MemTest 86+ => 0 erreur.
- Chipset : FSB = 265 MHz, mémoire désynchro, coef CPU à 6 ; 3 heures d'OCCTPT => pas d'erreur.
 
 
J'ai acheté le CPU cet été. Je me suis rendu compte que je n'étais pas tombé sur 1 super step   (du genre de certains qui tapent 2750 MHz au Vcore d'origine !) voire pas sur un bon step. Je commençais à être franchement déçu par mes résultats (j'veux bien être poissard, mais y'a des limites ) qd, ce week-end, je me suis rendu compte d'1 truc :
 
Tous les test ont été effectués à 10 x 245 MHz, chronologiquement :
 
Vcore = 1,47 V (réglage bios)
OCCTPT => erreur en moins d'une minute. Comme ça, je lance CPUStress de Fouge => 10 heures, 0 erreur.
 
Vcore = 1,45 V
CPUStress => 5 heures, 0 erreur.

Vcore = 1,43 V
CPUStress => 3 heures, o erreur.
Pour voir, je reprends OCCTPT mais je le paramètre sur "CPU" => 9 heures, 0 erreur !!!
 
Vcore = 1,41 V
CPUStress => 3 heures, 0 erreur
OCCTPT => 3 heures (sur "CPU" ), 0 erreur.
 
Vcore = 1,39 V
CPUStress => freeze du système au bout de 18 min. Obligé de relancer avec un le poussoir "reset".
OCCTPT => même symptôme au bout de 42 min
 
Vcore = 1,41 V
OCCTPT (sur "CPU" ) => 2 heures, 0 erreur.
OCCTPT (sur "CPU & RAM" ou sur "RAM" ), erreur au bout de 5 à 10 min.
CPUStress (cette nuit) => 1 erreur au bout de 3h41 de test.
 
Dans le même temps, à toutes ces tensions, ORTHOS m'annonce une erreur en moins de 10 min, quel que soit le réglage (CPU, blend,…). SuperPI, lui, achève le calcul 32M à chaque fois.
 
 
Pour info, je vous mets les graphs des tensions du test de 3 heures à 1,41 V. SpeedFan dit 11,43 V pour la ligne 12 V mais Everest et mon multimètre me disent 12,03 V .
 

 

 

 

 
 
Mes questions :
 
Est-ce que l'ensemble de ces résultats peuvent m'indiquer (ou, au moins, m'orienter) quel élt de mon PC provoque l'instabilté ?
Ne serait-ce pas la RAM ? Je dis ça parce que c'est le seul élt. que je n'ai pas changé de mon ancienne config. Et déjà, avec OCCT 0.91, j'avais des freeze système (que je retrouve ici en 1,39 V). Mais elle a passé 12h de MemTest sans erreur…
 
 
Voilà, si vous pouviez m'éclairer (désolé, j'ai pas fait court )
 
@+

Alors là, ton PC est un cas
 
Au vcore d'origine, l'erreur en moins d'une minute sur OCCT est systématique ?

Je trouve ça étonnant qu'Orthos te trouve systématiquement une erreur en moins de 10min :
1) quel que soit son réglage (Small, Large, Blend) qui offre des comportements bien différent en fonction du type d'instabilité
2) quel que soit le Vcore (idem, comportement différent si Vcore trop bas, ou trop haut)
3) comportement très différent de OOCTPT et surtout de CPU Stress car celui-ci intègre le même algo (Prime95 24.14)
 
Etant donné que des erreurs sont détectés meme en mode CPU (par OCCTPT et SP2004) c'est que c'est sûrement ton CPU qui est en cause

Il n'a pas fait de test au Vcore d'origine (1.35V). Ou alors j'suis mal réveillé  

 
Mea culpa, je parlais du premier vcore affiché.
 
C'est lundi matin hein

Si, j'ai fait un test au Vcore d'origine et en réglage bios par défaut (j'en avais pas parlé) => pas d'erreur. Ni sous OCCTPT, ni sous CPUStress, ni sous Orthos.
 
Je pense, mais je ne suis qu'1 utilisateur lambda, qu'à 1,41 V, je suis à la limite d'O/C à 2450 MHz de mon CPU. C'est pour ça que CPUStress détecte une erreur au bout de 3h41 de test. J'ai lancé ce matin un test infini d'OCCTPT (pour l'instant, je m'étais limité à 3h à 1,41 V), je vous dirai demain ce que ça a donné.
 
Mais pourquoi donc, nom d'un ch*** :
- Orthos plante systématiquement dès que j'O/C, quelque soit son réglage et quelque soit le Vcore
- Qu'OCCT tient (9h de test, j'pense que je peux dire "stable" ) en "CPU" à 1,43 V mais trouve assez rapidement une erreur en "CPU & RAM" et en "RAM" qcq soit le Vcore.
- Que CPUStress ne trouve aucune erreur jusqu'à 1,43 V
   ????????
 
Quel composant(s) est plus sollicité par OCCTPT en "RAM" et "RAM & CPU" qu'en "CPU" ? A priori, je dirais... la RAM mais je suis pas sûr.
Et est-ce que les composants sollicité par CPUStress sont les mêmes que OCCTPT réglé sur "CPU" ?
 
 
Enfin, le fait que OCCT et CPUStress provoquent un freeze système à 1,39 V comme OCCT 0.91 pouvait le faire sur mon ancienne config (Asus A7N8X-E ; XP-M 2600+ 2,4 GHz @ 1,65 V) est-il révélateur de qcq chose ? Windows (mais j'ai ré-installé mon OS avec ma nouvelle config) ? la RAM (je dis ça parce que c'est le seul élt que je n'ai pas changé et un freeze système est souvent révélateur dun pb de RAM) ? autre chose ?
 
 
En tout cas, je sous d'accord avec Tetedeiench : mon PC est un cas !!!    
 
@+

En CPU&RAM, le test est assez bien réparti sur toute la chaine CPU <=> Chipset <=> RAM.
 
En CPU, y a quasiment que le CPU qui taffe.
 
En RAM, l'accent est mis sur le couple Chipset <=> Ram
 
Pour OCCT du moins...
 
Le coup du chipset qui tiens pas le choc peut être une piste.

reinel> Pour CPU Stress MT, c'est une sorte de "Very Large FFT". Il n'utilise pas la RAM comme le fait le Blend, mais des tailles de données un peu plus grosses que le mode Large afin de tester CPU + L1/L2. Forcément ça utilise la RAM mais en petite quantité (entre 8 et 32Mo par core). Donc si ça tombe pas sur la partie de RAM instable, ça détectera pas d'erreur.
 
Par contre, si Orthos est fiable sur ton PC, ce serait le CPU qui serait en cause puisqu'il détecte une erreur ême en mode CPU (Small FFT).

Fiable dans le sens ou il arrive à détecter une instabilité là ou les autres soft n'y arrivent pas (ou plus difficilement).
Si c'est un bug d'Orthos (peu probable je pense), alors les résultats ne sont pas fiables et il ne faut pas les exploiter.

autant pour moi. C'est plus clair comme ça effectivement

hello,  
 
je viens de faire un test comparatif entre OCCT PT, le log de fouge et prime sur mon rpescott 2.8@3.3. Tous les log le trouvent rock stable à FSB237 mais seul le log de fouge détecte une instabilité à 240 (où j'ai quelques écrans bleus). OCCT PT ne détecte l'instabilité que conjugué à prime95.
 
Tout ça pour dire que le test de l'unité physique te de l'unité virtuelle en même temps est nécessaire pour tester au mieux les CPU HT.

J'ai eu plusieurs feedback qui allaient dans ce sens. Mais Tetedeiench a également vu l'inverse (sur sa propre machine je crois bien). Faut bien faire un choix
C'est là l'intêret de varier les tests de stabilité CPU

 

 
Effectivement, j'ai eu l'inverse Je reste sur mon ignore du HT Enfin je crois

Et en ce qui concerne l'option style "case a cocher" de "fermer le log de monitoring si OCCT PT l'a lancé" ?
 
desolé j'ai pas trop suivi

 
Ca va être par défaut

ah cool

Trop bossé/couru au taff aujourd'hui... résultat : 3 heures de code en rentrant et chuis crevé

'lut,
 
Je reprends le cours de mon post d'hier...
 
Je pensais avoir lancé OCCTPT hier matin mais qd je suis rentré, je me suis rendu compte que c'était CPUStress qui tournait (j'suis pas du matin ). Par contre, alors que ds la nuit il avait détecté une erreur au bout de 3h, là avec les mêmes réglages (10 x 245 MHz @ 1,41 V), au bout de 13h il tournait tjs.
 
Avant de lancer OCCTPT, je me dis que je vais lancer un Orthos (réglé sur small Fft) pour vous faire un screen qd il aura détecté une erreur => ce matin, après 11h de test, tjs pas d'erreur.
      Comprends plus        
 
Avant que vous me posiez la question, je l'ai fait pour vous : "Suis-je sûr d'avoir réglé Orthos sur small Fft pour mes précédents tests où il a détecté une erreur en moins de 10 min ?" La réponse est "oui"... à 95 % ; maintenant, j'ai un doute  
 
Ce matin ,avant de partir, j'ai lancé OCCTPT -réglage "CPU" (rigolez pas) tjs à 1,41 V pour valider les 2 autres tests. Vais voir le résultat ce soir et faire d'autres tests;
 
 
@+

Re,
 
Sur les "améliorations" à apporter à OCCTPT, je proposerais une autre chose (tjs sur les graphes) :
homogènéïser les échelles des graphes "tensions" pour que, visuellement, ce soit + cohérent.
 
J'm'explique :
Si on reprend les 4 graphes que j'ai postés hier, celui où la courbe a le + d'amplitude, c'est le 5 V alors qu'il n'a un ripple que de 0,6 % alors que le Vcore, avec un ripple > 2 % est nettement plus plat : pas logique.
 
Ce que je propose :
- voir quelle tension à le ripple max
- arrondir ce ripple à l'entier supérieur
- appliquer ce % à la tension de départ de chaque mesure en + et en - (évite d'avoir une courbe qui rempli l'ensemble du graphe -> moins lisible) pour calculer l'échelle de l'ensemble des graphes.
 
Ainsi les amplitudes de courbe auront la même signification d'un graphe à l'autre. En plus, toutes les courbes partiront du milieu des graphes, ce qui améliore la lisibilité.
 
 
Pour donner un exemple, je reprends mes 4 graphes :
- le ripple max est sur le Vcore avec 2,13 %. Arrondi à l'entier supérieur => 3 %.
- je l'applique à l'ensemble des tensions de départ en + et en - :
=> Vcore 1,41 V : échelle du graphe de 1,37 V à 1,45 V
=> 3,3 V à 3,26 v : graphe de 3,20 V à 3,40 V
=> 5 V à 5V : graphe de 4,85 V à 5,15 V
=> 12 V à 11,43 V : graphe de 11, 09 V à 11,77 V
 
Comme ça, l'amplitude de la courbe sur un graphe aura la même signification que sur un autre.
 
 
L'objection principale c'est la disparition possible du trait bleu qui symbolise la tension théorique. Est-ce vraiment important ? Qd on connait la fiabilité des tensions données par les soft de monitoring, la donnée exploitable c'est le ripple. Exemple sur ma config : SpeedFan me donne le 12 V à 11,43 V quand Everest me confirme ce que je lis sur mon multimètre : 12,03 V (sur une molex, sur la prise 24 pins ou sur la prise CM carrée).
 
 
Maintenant je ne sais pas :
- Si ma perception est partagée.
- Si ce que je propose est réalisable techniquement
 
 
@+

 
Mais faut t'embaucher toi, t'es plein de super bonnes idées de la mort qui tue
 
Je vais modifier ton truc de la manière suivante :
-Prendre le Ripple Max
-Ajouter une marge avec marge de sécurité ( style si 2.95% de ripple je prends 3.55%, un truc du genre )
-Je prends la valeur moyenne et je prends le ripple haut/bas ( parfait ).
-Si l'intervalle max/min ne comprends pas la valeur de base (i.e. 3.3V ), j'agrandis l'échelle jusqu'à ce qu'elle grimpe pour l'inclure ( A voir d'ailleurs ).
 
Maintenant, le blem est que si une valeur a un riiple enorme, pour les petits ripple tu ne verras rien. A voir si ca arrive souvent...
 
Mais elle me plait beaucoup cette solution

Content que ça plaise    
 

A mon avis, tu retrouveras ce pb surtout si tu tiens à faire figurer absolument la tension théorique (le trait bleu) sur le graphe (cf ma tension 12 V )
 
@+

1, 2 et 3 ça me parait bien.
Pour le 4, par contre, j'aime moins (cf l'exemple du 12V qui reste à 11.4/11.5V) car on perd l'homogénéïté des variations inter-graphes.
Pour un éventuel graphe avec un gros ripple (>10% ?), utiliser cette méthode pour tous les graphes sauf celui-là.  

Les graphs, c'est OCCT qui les pond ?

Oui. Tu pensaient qu'ils sortaient d'où ?

Chais pas. Export des données, pois passage à la moulinette.
Bon, j'vais installer le soft pour voir si mon prb de stabilité vient pas de l'alim qui aurait mal vieilli d'un coup) et qui sort des tensions à la noix (pourtant c'était une bonne alim).
 
Merci

Je vois pas comment les obtenir

Ok, faut attendre la fin du test.
 
OCCT ne voit pas les OC dynamiques ? (d'façon, si ça sert à rien de le savoir pour le test ou les graphs...).

Tu fais un test de 30min ou un test perso, avec monitoring activé dans OCCT. Et ça les génère à la fin du test, s'il a réussi, dans un répertoire OCCT dans Mes Documents je crois.

 
Pas pour le moment non ( trop consommateur de CPU si je dois refaire le test de fréquence à chaque réapparition de la fenêtre )

ok
 
 
Au fait, prq dans CPU Stress et OCCT, pour le monitoring, y'a la temps que d'un seul CPU ?
 
En multi CPU vous pourriez pas utiliser la seconde sonde ?

 
groody, content que tu utilises OCCT
 
Pour la température d'un seul CPU, c'est une question d'interface : gérer ad vitam eternam X températures CPU et autres risque d'être difficile sur le long terme, surtout en termes d'interface.
 
J'ai envie d'y remédier dans la 1.0.3, qui va revoir pas mal de choses justement Et j'ai une idée pour le gérer Mais va falloir attendre

Rohhhhh hey, juste un second champ de temp c'est rien

Une petite idée pour les graphs.
 
Est-il possible de montrer clairement les périodes de tests ? Pour bien voir quand ça a tourné, et pouvoir comparer avec les courbes (changement de couleur du fond par exemple, même léger tant que c'est visible).

Salut,
 
Je continue mes tests pour savoir ce qui ne va pas ds mon PC. J'ai encore eu un imprévu hier soir => pas pu tester ce que je voulais   .
 
Comme j'étais pas très dispo, j'ai juste fait un essai en… montant mon O/C. De 10 x 245 MHz @ 1,41 V, je suis passé à 2 x 250 MHz (RAM synchro).
@ 1,41 V => passe pas.
@ 1,43 V => passe pas.
@ 1,45 V => 3 h de CPUStress: OK ; 5 h d'OCCTPT (réglé sur "RAM" ) : OK.
Ces résultats ne m'étonnent pas trop, je sais que je ne suis pas tombé sur un très bon step (qd je pense que certains montent à 2750 MHz @ 1,35 V ). A mon avis, mon proco risque de ne pas monter bcp + haut que 2600 MHz . Ce soir, je vais essayer Orthos en "small Fft" puis OCCTPT en "RAM" et/ou Orthos en "blend".
 
 
Par contre, qd je dis que le test "passe pas", ça signifie 4 fois sur 5 que tout le PC freeze (obligé au reboot) en cours de test que ce soit avec OCCT ou CPUStress .
Et j'avais exactement les mêmes symptômes avec mon ancienne config sous OCCT ou sous Prime95. J'ai tout changé (CM, CPU, CG, ventirad) sauf la RAM et les HDD (mais j'ai ré-installé tous l'OS) et ça continue...
 
 
Avec mes maigres connaissances, j'ai réfléchi (de tps en tps, ça m'arrive) aux causes possibles. D'habitude, un freeze du PC est assez symptomatique d'1 pb mémoire. Mais la RAM a passé 12 h de MemTest 86+ @ 265 MHz sans erreur !
Et si ça venait de la gestion de la RAM sous windows ?
Ca expliquerai qu'elle est stable au boot mais pose pb sous windows (je rappelle que les tests "CPU&RAM" et "RAM" d'OCCTPT ne passent absolument pas qd le test "CPU" tourne 12h sans pb).
J'ai ré-installé l'OS mais je l'ai reconfiguré pareil qu'avant et installé à peu près les mêmes programmes.
 
Qd j'aurai un peu de tps, je ferai une image Ghost de C: (pas envie de me repayer toute l'instal si c'est pas ça), reformaterai la partition système et ré-installerai windows (sans rien y changer ni installer d'autres softs sf SpeedFan) pour relancer OCCTPT en "RAM", voir si ça vient de là.
 
Pensez-vous que ce soit une piste possible à suivre ?
Sinon, qu'est-ce que ça pourrait être ?
 
 
@+

 
Et les quad-cores ?

4 CPU, ok, quad-cores, c'est les nouveaux Intel ? Y'a une sonde par core ?
 
Si oui, je savais pas, j'imaginais une par CPU physique.

Nos soft ne gère pas que 2 cores (ou, de manière plus générale, 2 processeurs logiques). Soit on gère 1 seule T°, soit on les gère toute, qu'il y en ait 2, 4, 8 ou plus.
Et au niveau interface (configuration/affichage) c'est pas simple
 

+1
C'est pas bête je trouve, une barre verticale suffirait même
 

Le quadcore d'Intel c'est 2 die de Core2Duo, donc physiquement, il y a 4 sondes.
Et il me semble que Tetedeiench a testé sur un Quadri Xeon dualcore, donc 8 sondes potentielles.
Juste un champ suppllémentaire tu disais ?