Reprise du message précédent :
Ce que je remarque c'est qu'il met plus de temps à détecter les erreurs que le précédent au niveau de la vRAM (en fait après 400s il n'avait toujours pas détecté d'erreur là ou la 0.52 en détecte en 3s ), et ceci s'explique certainement par le fait qu'elle travaille moins dans la v0.62 que dans la v0.52 car j'ai 4° d'écart en faveur de la 0.52 (58°C contre 54°C pour la 0.62). La chauffe du GPU est à 1° max d'écart (45° v0.52 contre 46°C v0.62).

Dans tous les cas, pour le GPU ces erreurs ne seront pas détectées par OCCT GPU ça crashera directement le pilote, je pense que c'est surtout sur ce plan là qu'on saura s'il est meilleur pour créer une instabilité que le précédent.

EDIT: Test fait en auto, pas à 10fps, mais 7.2fps.

Essaie de réduire la valeur Shader Loops pour obtenir non plus 10fps, mais 30 ou 40, pour voir ce que ca donne...

Donc selon toi, la ram travaille moins dans la v0.62 que dans la v0.52, par contre, le GPU chauffe plus. J'ai bon ?

Pour le 7.2fps, oubliez pas que le 10fps est une "cible", et que je m'arrête quand j'arrive "en dessous". C'est une approximation donc, au mieux.

Je crois que j'ai trouvé un truc les gars...

Oh putain, on peut travailler avec plus d'unités de texture que ce qui est renvoyé par MaxSimultaneousTextures

Aaaargh, j'en reviens pas. J'y comprends rieng.

Bon, OK, j'ai merdé sur ce point là, il est castré pour le moment OCCT GPU Carrément. Je fais travailler 8 unités de textures sur 32

Encore un truc qui ne va pas marcher sur les ATI

Si. Théoriquement. Chuis con. Très con. Je prenais la limite du pipeline "fixe" alors que je suis dans un environnement programmable.
 
Ca va chauffer sec.
 
Par contre, je me demande si ca chaufferait pas encore plus en mode DirectX 10 pour le coup.

Oki doki. Là c'est à 0, je peux la mettre en négatif...?

Sinon, oui, pour la RAM, c'est ce que pense après constatation de la différence de t°.

Crysis plante plus vite en DX10 qu'en DX9 chez moi.

OCCT GPU v0.63 OUT !

Au menu :

• Utilisation de 16 textures au lieu de 8 précédemment. Ca devrait chauffer bien plus dans les chaumières

Enjoy !

http://www.ocbase.com/download.php?fileext=gpu

PS : l'algo est bien plus méchant, du coup. Ma GTX285 est à genoux avec une valeur de Shader Loops à 1685 (elle tourne alors à 9fps).

Yoyo_5, tu peux confirmer que ca tape plus dans la ram ?

Bah euh oui sauf que c'est en multipass c'est pas ça ?

C'est 16, mea culpa, en PS3.0.
 
Sans pixel shader, tu es limité à 8 textures en multitexturing, avec pixel shaders, tu peux aller jusqu'à 16 sans souci.

C'est moins chaud de 2°C par rapport à la 0.62...
 
PS: Plus dispo ce soir.

la beta actuelle chauffe bien moins que la précédente,
mon fan ne se met meme pas à 100%.
(paramètre à zero, 700x700)
Screenshoot ci-dessous.
 

 
 

AAAAAaaaaaaaaallons bon. Rigolo, ça.

Je refais des modifs, et je reviens en arrière, du coup.

OCCT GPU v0.64 OUT !

Au menu :

• Retour à 8 textures. Marrant que ca soit plus efficace.
• Optimisation du travail GPU

Enjoy !

http://www.ocbase.com/download.php?fileext=gpu

PS : va falloir que je me creuse la cervelle pour savoir comment faire pour détecter les erreurs plus rapidement... si j'y arrive pas, je sais pas si cet algo va survivre.

lol, c'était déjà la version 0.63 ^^

TU sais à son age il ne faut pas trop lui en vouloir, la mémoire ne dure pas plus de quelques minutes voir secondes. Alors si en plus c'est un informaticien de métiers, je vous racontes même pas....
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Pas tapäy.

Un informaticien a la moitié de sa RAM mémoire (en neurones ) dans ses machines !
& quand on voit la capacité de stockage de certains parcs, on se dit que la marge reste conséquente ...

corrigé

shader loop a 2000 => ca chauffe un max !!

je tente de tester ma AB9 avec Occt 3.01, mais il semble y avoir un conflit entre Abit uguru et OCCT, puisque uguru se bloque qd OCCT tourne (meme en idle). Est ce un pb connu? Sinon, il est aussi possible que mon windows soit cassé ("vieux" xp sp2...)
PS: j ai 4 Go de RAM DDR2 "820" 4-4-4-10 en 2.1V qui passent bien un memtest+; le PAE est activé sous XP. Y a t il sinon des pb connus avec PAE et uguru ou PAE et OCCT?

Eric B > il semble évident que c'est µGuru qui bloque
 

Sinon: "Just like with Intel Core 2 Quad/Duo, the highest processor load is created by Linpack algorithm. OCCT program may have an error (or may be using a different Linpack version), because it heats the CPU less than LinX."
 

> source <

En même temps sur un Core i7 je crois que OCCT ne calcul que pour 4 core et pas 8...
 
En plus bon faire du Linpack 32 sur un Core i7 ça rime pas a grand chose...

Sera corrigé dans la prochaine build tasson !
Mais c'était pour attirer l'attention au iench que son programme sert dorénavant comme programme de référence dans des reviews sérieuses

Effectivement Xbit labs c'est du lourd.
 

MEI > preuve que si
C'est tout de même lui qui fait chauffer le +
20°C entre lui et un pauv' ( ) jeu einh

question: votre compte principal est il avec les droits admin?
Pour ma part, depuis des années (en fait depuis Win2000), je préfére utiliser un compte "power user" et lancer 1 app qui requiert les droits admin avec "run as"
c est donc le cas aussi pour OCCT puisque le monitoring requiert les droits admin. Or, le rep de log semble fixe, et OCCT renvoie une erreur "repertoire non présent" (sous admin doc\occt\...) bien qu'il écrive correctement les fichiers (mais qui ne sont pas accessible avec mon compte power user)
Serait il possible de configurer dans les options le repertoire de log? Merci!

Non mais j'veut dire, faut utiliser Linpack 64 l'histoire de faire vraiment mal au bestiaux.

Désoler iench je peux pas test, je suis malade ^^

bien vu pour xbitlabs ... Je vais essayer de releaser la beta ce soir meme si je suis naze et de les prevenir par email

OCCT PT 3.0.2.b02 OUT !
 
Au menu :

• Support de l'HT pour le test Linpack (cochez la case HT et zou).
• La case Hyperthreading as Dual core est maintenant renommée Hyperthreading (tout bêtement)
• La case Hyperthreading est cochée par défaut pour les tests OCCT et Linpack au premier lancement d'OCCT

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

c'est dans la poche

Hoplà, dommage, mais xbitlabs peut pas mettre à jour son article
 
Enfin spa grave.

Oh ils feront un commentaire dans leur prochain article, t'en fait pas pour ça.

Je me pose à l'instant une question, existe-t-il des cas ou occt ne detecte aucune erreur et un memtest fait à partir d'un cd de boot OUI? (je sais que occt ne peut pas tester la ram dans le kernel land mais je me demande si concrètement et pas théoriquement ca se produit)

Oui, chez moi ça se produisait sur ma précédente CM...enfin seulement sur une heure de OCCT, pas plus.
Memetest86+ détectait les erreurs dès la première passe, mais OCCT ne les "voyait" jamais au bout d'une heure, mais au delà je pense qu'il les aurait détectées puisque ces erreurs me causaient parfois des BSOD sans que je ne fasse quoi que ce soit de bien stressant pour le système.
Ma CM cramait les RAM dès qu'on les connectait dessus.

Ah ok, donc je suis fixé , je savais que souvent memtest n'indiquait pas d'erreur et qu'ensuite occt indiquait lui des véritables erreurs, mais je n'avais jamais constaté l'inverse. Je ne sais pas pourquoi techniquement cela se produit, et j'aimerais bien le savoir mais au moins j'ai une réponse.merci

Honnêtement je ne sais pas non plus. J'ai émis l'hypothèse que l'OS pouvait corriger ses erreurs là, mais j'en doute fortement maintenant, surtout que tu as vu le phénomène inverse.

Load Line Calibration; Voltage Damper etc.
Tous ces systèmes sont connus pour provoquer des instabilités 'inconnues' ou aléatoires
Certes, ils font de beaux graphes de VCore, bien linéaires toussa mais en contrepartie ils peuvent engendrer ce type de comportement
Souvent au moment du passage de Load>Idle d'ailleurs ...

Memtest peut tester la ram avant le boot ce qui est largement plus efficace, pour etre sur et certain dde la stabilité de mon oc je fais jamais un test occt de 1 heure, c'est bien pour se donner une idée de la stabilité mais un test plus poussé pendant une nuit complete est plus que conseillé pour valider un gros oc.
 
 
Merci beaucoup Tetedeiench pour le travail que tu fait, ton soft est devenu au fil du temps une pure merveille, et maintenant je peut enfin me debarasser de furmark que j'associait en meme temps a occt pour tester ma stabilité en burn cpu + gpux
 
 
     

Bah peut etre aussi qu'occt ne pouvait pas découvrir les problèmes de mémoire car il y a d'autres accès mémoires fait par d'autre process, qui coupent les bursts ou ralentissent les actions, non ?
Peut etre aussi que les drivers (hal) limitent aussi la vitesse des accès.
Et enfin, peut etre qu'un process ralentit le fsb mémoire...

Je ne vois pas en quoi le LLC pourrait cramer les RAM ou causer des erreurs RAM sous Memtest86+ et pas dans OCCT...