Reprise du message précédent :

Exactement, faut passer en strap 1333, cad à un fsb de 401 minimum au boot.
Ou alors augmenter le vNB pour atteindre les 400 de fsb mais avec le risque de passer en PCI-E X1 (avec la révision C1 du NB seulement)
c'est déjà pas mal 390 MHz avec 1.45v sur le NB, la mienne arrive à 380 MHz à cette tension.
 
Courage avec ta P5B, une fois que tu as passé le strap 1333 tu peux monter à 450 MHz en gardant le NB à 1.45v.
Désolé pour le hs

Juste pour dire merci a tetedeiench pour ce logiciel qui m'a aidé et fais gagner du temps dans mon o/C  

 
[Hors Sujet]
Merci de vos commentaires
J'ai un topic pour ce problème, si quelqu'un se sent de m'aider plus
http://forum.hardware.fr/hfr/Overc [...] 3630_1.htm
 
J'y avais pensé. Mon NB passe au strap 1333 exactement a 401 (bien visible sur Sisoft RAM Bandwidth). De 401 à 405, reboot lors de OCCT RAM. Dès 406, reboot au lancement windows. Rien n'y fait: timing 6-6-6-18, overvoltage RAM 2.25, vNB 1.7, vFSB 1.45, vICH et vSB augmentés, vcore 1.6, 2 barrettes de RAM au lieu de 4...
 
Le phénomène est exactement le même avec mon ancien Q6600 B3, exactement aux mêmes fréquences FSB au MHz près. Bizarre que ça soit le même FSB wall pour les deux CPU, d'où j'en ai conclut à un FSB wall de ma CM avec un Q6600.
 
ça m'étonne qu'on  puisse atteindre 450MHz de FSB sur une P5B deluxe quand je vois les tests de la maximus qui plafonnent avec un QX à 445 MHz. Overclocker un quad est plus délicat qu'un C2D. J'ai aussi peut être tiré le mauvais lot de CM.
 
Si jamais vous avez un conseil, passez voir le topic que j'ai créer, ça serait sympas
 
[Fin du Hors sujet]
ehh.. rien a dire dans le sujet    
 

Hors Sujet aussi
Là je suis full stable a 3.51GHz en 1.368 vcore, je teste 1.35... pour finir minimum full stable 1.384v
Je fume quand je pense que j'ai un CPU avec un potentiel si enorme et que je n'arrive pas plus haut...
Pleaaaase, aidez moi, venez tous ici
http://forum.hardware.fr/hfr/Overc [...] 3630_1.htm
 
HEEELP    
 
Pardon tetedehiench de spamer ton thread, plus jamais
  Aidez moiiiiii....

sun tzu > A ton service ! ca fait plaisir
 
jonny_ftm > Bah, fais toi plaisir, tu m'as toi même bien rendu service, donc c'est la moindre des choses
 
Jovial, Pinkfloyd > Je vais y regarder juste après le slider
 
Tout le monde > J'ai un emploi du temps de furieux (hier, taffé jusque 23h) et ca risque de continuer toute la semaine... peux pas taffer sur OCCT (je vous avouerai que ma copine a la priorité après 23h )... mais vous inquiétez pas, ca va arriver, je vous demande juste de la patience

Voilà, pour me faire pardonner de mes HS précédents, je poste le résumé de mes observations après des heures de OCCT pour stabiliser mon OC (voir ma galère avec ma CM plus haut)
 
En mode RAM
 
L'indicateur d'utilisation du CPU semble ok.
 

 
Là, je vois bien que ma DDR2 tient le 4-4-4-12 a prèsque DDR2-800    (mes instabilités venaient de mon FSB wall surement sur le P965)
 
Après une multitude de tests, le mode RAM c'est vraiment le plus sensible si le système NB-RAM-CPU foire, OCCT n'aime pas ça et ça ne dure pas plus de 30mn, voir 10-20mn en général, remarquable comparé à Prime95 small/large/blend. J'ai gagné un temps fou dans le tweaking de mon OC depuis cette beta.
 
Reste que par moment le PC peut se figer en mode RAM avant de se "decoincer". Problème de priorité? En lowest, c'est dèjà beaucoup mieu. Mais après tout, quand on veut bencher pour la stabilité, je n'y vois pas d'inconvénient personellement, ça permet de pousser le système/OS dans ses derniers retranchements...
 
La température du CPU est un peu oscilloscopique en mode RAM comme dèjà mentionné par d'autres avant. Mais bon, les fluctuations sont dans une marge raisonnable. Les chutes correspondraient peut etre aux temps de transferts RAM-CPU pour les calculs, vu la taille des paquets?
 

[/IMG][/URL]
 
 
Mode CPU pur
 
Je n'ai pas beaucoup tester le mode CPU pur contrairement au mode RAM. Mais les courbes de température sont aussi oscilloscopiques (marge encore dans la norme je crois) et le CPU chauffe moins que Prime95 small FFT (4°C en moins après 20mn de test pour chaqu'un)
 
Courbe température après 20mn OCCT mode CPU:

 
 
Courbe température après 20mn Prime95 small FFT:

 
On voit aussi que les variations de température sont plus stables avec Prime95 qui utilise donc le CPU de manière plus soutenue en mode small FFT (variation au degrès près avec Prime95 et aux 4-5°C avec OCCT). Ceci est vrai même si je lance OCCT après Prime95 qui aura bien chauffé le processeur avant. Avec OCCT, il prend un petit coup de froid.
 
Au vu de ces résultats, j'ai toujour gardé Prime95 small FFT dans ma quête du vcore le plus bas. Il est vrai que je n'ai pas donné sa chance a OCCT mode CPU en comparaison. Par contre, en mode RAM, OCCT plantait plus vite que Prime large FFT et Prime Blend lorsqu'il y avait un problème mémoire ou sur le NB.
 
Bug de l'affichage de l'utilisation du CPU
Pas de bogue en mode custom RAM ou CPU pur. L'affichage semble correcte (98.45% après 10mn). J'ai essayé priorté normale/lowest/custom/auto... et je constate que c'est le mode AUTO qui bogue dans l'affichage de l'utilisation du CPU, les autres modes semblent ok chez moi
 
Voilà, j'èspère que le Iench va avancer la version finale avec ces infos qui je l'èspère seront utiles. Sinon, ce soir, je descend le vcore d'un poil et je regarde OCCT mode CPU ce que ça donne (Prime95 ne dure que quelque mn à 1.36 vcore)

Merci pour li'nfo concernant le mode auto, ca me fait gagner un temps fou... Je regarde aussi pourquoi y a les dents de scie, théoriquement, ca devrait être moins prononcé... maintenant entre la théorie et la pratique, y a toujours un monde (par ex, en théorie, le mode CPU devrait être un peu plus vilain et performant que ram, mais en pratique, RAM est bien bien mieux...).

La RAM c'est le talon d'Achille d'un ordi. 'tasson

Le mode CPU, du moins en prime95 small FFT, permet de tweaker le plus bas vcore avec très peu de marge d'erreur. Les modes RAM peuvent être influancés par le reste comme ils stressent a mort tout le relais CM-RAM-CPU et sont donc un meilleur reflet de la stabilité du système.
A mon sens, il faut toujour faire un test CPU et au moins un test Large FFT ou OCCT max RAM pour être quasi sur que si un jour ça plante, c'est le soft et pas le hardware qui peine
 
Sinon, c'est vrai que les dents de scie en mode CPU sont plus embétantes, du moins en théorie, comme tu dis (je ne suis pas le premier qui l'a remarqué mais c'est en comparant à prime95 que ça m'a choqué). Je vais tester avec mon vcore instable OCCT en mode CPU et voir s'il peine plus que Prime95 a trouver un bogue

Deux petites choses :  
 
- Je me demandais comment OCCT va chercher la fréquence BUS et CPU ? J'ai une mobo Abit, et lorsque je modifie le FSB via l'utilitaire µGuru, OCCT (même après redémarage) continue à détecter la fréquence à laquelle j'ai booté. Ceci-dit il en va de même pour Orthos par exemple. Orthos pousse même l'erreur un peu plus loin puisqu'il est incapable de détecter une baisse de coeff CPU...
Bref, c'est pas super important, mais je vois qu'un soft tel que Everest détecte les fréquences FSB, CPU, le coeff et leurs variations en direct. Je me demandais donc pourquoi ne pas en faire de même avec OCCT.
 
- Ensuite, une petite idée de feature. Je reste toujours persuadé que l'idée utilisée dans CPU Stress ou on affiche les valeurs maximales et minimales des différents éléments sondés (temp° et voltages) lors du résumé du test est excellente. Les graphiques de OCCT sont super, mais ils ne permettent pas de voir les mesures minimales et maximales, étant trop impréçis pour peu que la durée du test soit un peu longue...
En parrallèle à ça, on est tous d'accord sur le fait qu'il est préférable d'utiliser plusieurs soft pour tester la stabilité d'un OC. Perso, j'aime Orthos, d'autres préfèrent CPU Stress ou Prime95. Malheureusement ces soft ne proposent pas les fonctions de monitoring avancées dont OCCT dispose. Je pense que OCCT prendrait une énorme valeur supplémentaire si il permettait d'enregistrer des sessions de monitoring sans mettre un burn-test en route.  
En pratique, j'imaginerais ça comme un mode de test supplémentaire sur notre petit slider, nommé "Monitoring". On clique sur le bouton ON comme d'habitude, mais celà ne fait qu'enregistrer les valeurs de monitoring pour les sortir sur graphique. A côté de celà, on lance notre application auxiliaire. De cette façon on peut monitorer à la sauce OCCT, avec n'importe quel autre soft de burn. Ca pourrait aussi permettre d'observer le comportement du système pendant les sessions de jeu, et autre utilisation pratiques.
 
Evidemment, je ne sais pas si celà est facilement réalisable, mais je trouvais ça bien sympa comme idée !  
Si ça peut inspirer notre OCCT-Gµru !

L'idee est plaisante en effet

+1
 
Sinon, j'ai une question:
Prime95 en small FFT parle d'utilisation 0MB de RAM et 64Kb maximium pour les unités de calcul FFT. OCCT parle de 128Mb RAM en mode CPU. C'est de la que vient le problème de charge CPU tu crois?
 
Mais bon, je verrais en pratique si ça change qquechose en testant sur un OC instable pour cause de vcore bas d'un mini poil

OCCT utilise le "driver" de CrystalCPUID. Donc les valeurs de fréquence/coef/FSB dépendent entièrement de lui.
CrystalCPUID est dispo ici :
http://crystalmark.info/download/i [...] ystalCPUID
Si celui-ci détecte bien coef/FSB, alors faut que Tetedeiench voit ça de plus près. Une simple MAJ corrigera p'tet le pb.
Sinon, il n'y a rien à faire

Plutôt pour même à cette heure-ci ...

Pour le record, on m'a déjà demandé, et j'étais pas réellement pour... je le suis toujours pas.
 
OCCT est un logiciel de test sde stabilité, pas un logiciel de graphe... je veux pas qu'il devienne ce dernier. A la rigueur, je pourrai faire un spinoff d'occt, style "occtgraph" pour cela... mais je suis pas chaud.

Salut Tetedeiench.
 
Une question rapide : OCCT teste-t-il bien le FSB seul ?  
Dans mon O/C, je commence par l'O/C de la RAM, puis du FSB, pour finir par le Proco. Avec des séries de test à chaque palier.
 
OCCT stresse-t-il donc à plein le FSB seul ?
 
Merci

Merde, va falloir attendre l'été

Comment tu fais pour OC ta ram sans OC ton FSB ? (sauf mode unlinked sur Nforce)
Et comment tu fais pour OC ton FSB sans OC ton CPU ?  

L'ordre "logique" si on peut dire qu'il y en a un, serait plutôt d'overlocker comme suit :

1) Le CPU : En laissant la RAM aux alentours de ses fréquences de base.
   a) Chercher le FSB max en diminuant le coeff si l'on désire utiliser le FSB max du combo CPU/Mobo.
   b) Monter le FSB pour atteindre la fréquence souhaitée.

2) La Ram : En utilisant un oc stable à 100%.
   a) Monter progressivement en fréquence avec les timing les plus agressifs possible
   b) Adoucir les timings pour monter plus haut si on veut avoir chaud en hiver.

L'OC de ram c'est quand même vachement optionnel au vu des perfs que ça à sur un système...

Sinon je ne comprend pas ta question...
OCCT teste ton ordinateur. C'est un ensemble...les composants les plus enclins à faire des erreurs une fois overclockés sont le CPU et la RAM. Du coup OCCT permet de tester ces composants plus ou moins fort. Il va sans dire que si tu surcadences ton FSB de trop, OCCT de le dira d'une façon ou d'une autre

Rien à rajouter au post de robbb

http://www.xsreviews.co.uk vient de m'envoyer un mail me demandant la version pro d'OCCT pour l'utiliser dans leurs tests...
 
Je devrais mieux expliquer ce que c'est que cette version, et peut-être que je la refasse vivre...
 
mais y a des trucs qui passeront avant (monitoring, quand tu nous tiens... fouge ).

Pour ceux qui se plaignent de la résolution des graphes, vous pensez que faire des graphes, en plus, en grosse résolution, type 800x600, serait utile, en plus des pitis ?
 
Ca peut se faire rapidement, et ca réglerait pas mal de soucis, nan ?
 
Donnez-moi votre avis

Et ça donnerait ..?

--> met direct le choix de la resolution de la sortie des graphs hautes resolutions, ça ira plus vite.
 
Sinon fenetret de visualisation en details du graph avec zoom & co. Apres ça depends le composant que t'utilise... mais ça peut allé tres vite...

 
C'est évident qu'il me faille monter le FSB pour O/C la RAM. Mais de façon moins importante, puisque j'ai utilisé le ratio 1:2. Les tests de RAM sont ensuite faits avec MemTest, qui ne stress pas, je suppose, le FSB (si ?)
Puis je repasse à un ratio 1:1 pour forcer le FSB, en mettant un coeff de 6 pour le proco (E6600). Et en mettant à ce dernier un voltage relativement élevé.
 
Puis lancement d'OCCT, pour espérer ne tester que le FSB.
M'enfin, il doit y avoir des notions sur lesquelles j'ai un peu de mal. Si, comme tu le dis, c'est un tout, le stress du FSB est autant celui de la RAM que celui du proc.
Je pense donc suivre ton conseil : une fois les 2.4GHz atteint, on cherche un O/C du proco à coeff 9, donc avec un FSB plus faible, et on baisse le coeff pour monter le FSB une fois que le proco est stable, ce qui permet alors de tester la valeur FSB.
Toujours sous OCCT
 
J'en termine avec mon HS
 

 
Les graphes ont une taille tout à fait suffisante, en faire des plus grand serait inutile à mon avis...

C'est parce que t'as pas vu ce que ça pouvais donner en 1680x1050.

Ben tu peux voir plus en détail tes pics, mais fondamentalement, ça apporte quoi comme info en plus ?

Justifier l'acquisition d'un 1680x1050 sous OCCT
Facile

Voir des pics invisible.
 
Eventuellement, suivant la precision des sondes, zoomer et avoir une possibilité de defilement pourrai nous permetre de s'assure plus precisement de la stabilité des tensions, etc.

Houla, la fenêtre de prévisualisation, quasi impossib' mei
 
Choisir la résolution de sortie, pourquoi pas. mais j'aime bien ne pas permettre des valeurs farfelues et "brider" à quelques valeurs connues pour justement arriver à unifier le bazar. Cela permet, en communiquant, de savoir sans trop réfléchir ce que l'on regarde... si y a que 2 ou 3 tailles dispos par exemple.

Bah je sais pas tu generes ça comment ? A la mano ou avec un composant de graphe ? Parce que ca ressemble pas mal a du TeeChart c'pour ça...

Composant effectivement. Mais bon, le zoom et co, mouaiffe

C'est facile. 3-4 evenement redefini et ça roule.

Perso les graphes me conviennent, je pense qu'il serait plus simple d'ajouter les valeurs max-min enregistrées dans le petit résumé au dessus, à côté du ripple en toute logique.
Enfin si l'agrandissement des graphs permet la même chose, pourquoi pas...

+1 à l'idee de Robbb.
Un simple resumé des min-max suffirait déja amplement

 
Je viens d'expliquer à quelqu'un sur XS forums/topic la Maximus, que OCCT n'était pas un test de 30mn. C'est fou, mais ça fait une sacrés mauvaise pub ce 30mn: PC stable. J'èspère que Iench va regler ça dans les prochaines betas, c'est juste un display de texte.
Un autre regret formulé c'est qu'on ne voit pas ou est l'erreure: du coup j'ai expliqué les codes et ou les trouver. Sur la version finale/prochaines betas, ça pourrait apparaitre le bon code + explication (car pour l'instant, c'est parfois le code 1 qui est affiché alors qu'il y a un code 4 derriere)
9
 
C'est fou, y avait un Gar sur ce topic qui aussi etait stable partout (Prime small/large/blend) sauf OCCT RAM qui reboot, comme moi. Ben il se posait la question si OCCT deconne. Pour finir, il a renvoyé sa CM en RMA. En gros, ce mode RAM de OCCT dans les versions betas (même que Gar utilisait la 1.1.1b) parait vraiment stresser à mort les hauts OC malgrès une utilisation CPU reduite
 
J'éspère confirmer l'efficassité du test CPU pur bientot comme promis. Peut-être que OCCT deviendra la reference ultime de stabilité :-)

 
Si comme speedfan, y a une fonction log qui genere un fichier base de donnée (texte pour ne pas trop investir), cette base de donnée est ecrite en temps reel, permet que même en cas de reboot, on peut aller voir les temperatures/voltages lors du crash sur le fichier base de données.
 
Dans un 2ème temps, si le Iench a la disponibilité, cette base de donnée peut generer le graphe voulu à tout moment, même après un reboot intempestif ou un ecran bleu.
 
perso, je log avec speedfan toujour pour voir l'état lors du crash. Ca m'a permis de deceler mon instabilité du vcore après 2h de load (chauffe de l'etage alim probable)

Perso je trouve que c'est niquel, mais ce qui serait bien dans le cas des multi-cores serait de pouvoir avoir un graphique unique avec les tensions des 4 cores, chacun d'une couleur différente, ou quelque chose dans le genre... Mais bon, c'est pas vraiment utile, mais juste un meilleur moyen de comparer les températures à un moment donné d'un core par rapport à l'autre par exemple
 
Et pluzun pour l'idée du mini / maxi

Si OCCT etait pas si secret on pourrai faire travailler la communauté sur certains point.
 
Le graph est bien mais pourrai etre amélioré, j'vois pas mal de chose possible qui sont tout a fait gerable, mais qui demande c'est sur de developpement. Mais qui pourrai etre appreciable surtout dans un optique d'utilisation "intensive".

Pour l'open source mei, occt est mon bébé et le restera, à la vie, à la mort
 
N'oubliez pas qu'il y a en fait deux choses à concilier :

• Avoir plein d'options pour contenter les furiosos que vous êtes
• Rester assez simple pour être facilement utilisable (vous souriez, mais rien que le dropdown avec le test perso est pas capté par tout le monde...)

OCCT restera dans une logique d'accessibilité maximum.
 
jonny > Je vais corriger ça dans les prochaines bétas. Je vais avoir du temps bientot à consacrer à OCCT : mes formations en boucle se terminent ce soir, y a les grèves SNCF qui arrivent... donc ca devrait redémarrer. Là, je peux pas. mais oui, je pense que la prochaine béta :

• Corrigera les codes d'erreur 1 et co ( et dira à quoi ca correspond !)
• Reverra le test auto pour le passer à 1h
• Aura un design pour le slider qui, du coup, soulignera la présence du test perso et customizable

et d'autres trucs (j'ai reçu 3 traductions ! Espagnol notamment).

Il fut une époque où tu expliquais (Tetedeiench) bien qu'OCCT n'était pas un programme de monitoring, mais tu en as besoin
Ces programmes évoluent aussi et toi tu te sers de l'essentiel pour le VRAI objectif que se fixe OCCT => burn/monito (certes ) & stab.
On peut imaginer beaucoup 'd'options' mais encore faut-il qu'OCCT reste :

On en est au fignolage là, pour ainsi dire...