Reprise du message précédent :
Fougue pas de nouveauté sur la version linux en préparation???

salut tout le monde
je suis actuellement a 9*400 1/1 1.47v sous bios, ça tient 2 heures et 30mn occt, juste pour confirmé, plus les jeux ça tient bien, mais en attendant, de recevoir le kit de retention pour mon prochain vandetta2, je suis avec le rad ocz vanquisher auquel je lui est adjoint un un ventialteur avec 130cfm, ça doit faire dans 50/60db a moins de 1m, juste pour le teste.
 
SVP, j'ai besoin d'un coup de main pour complété le tableau, je sais pas ce que c'est ?
 
VIN1   1.65 V      1.65 V      1.66 V  ?
VIN3   1.22 V      1.22 V      1.22 V  ?
           Temperatures
SYSTIN   22 °C      21 °C      22 °C   c'est la carte mère
CPUTIN   57 °C      28 °C      57 °C   logiquement la temp intérieur du core
AUXTIN   30 °C      30 °C      30 °C   ?

Joyeux noël

Noyeux joël aussi.
PS tu peux mettre le lien vers le livecd en page1 avec les infos qui vont bien?

C'est fait
Je pourrai à nouveau bosser dessus à partir du 29 décembre pour sortir la RC1 corrigeant les problèmes de mesure de fréquence. Si c'est bon => version 1.1.0 stable, et on pourra définitivement oublier cette vieille version 1.0.4
Je donnerai aussi les modifs prévues pour la version 1.1.1

Ensuite t'enchaine sur la version mimux???

Une version Linux 0.10 qui sera basée sur la version stable pour Windows. Mais elle n'apportera pas réellement de fonctionnalités supplémentaires.
Je regarderai cependant cette histoire de fichier so/DLL.

Ouep, enfait, c'est tout c**, c'est juste que le linkage sur le .so est faite du genre ./ma_dll.so . (le message d'erreur affiché concerne windows (je suppose que tu n'as pas fait de spécificité linux pour le message d'erreur ), mais bon c'est bien le .so qu'il ne trouve pas...)
Mais bon je pense pas que tu puisses faire grand chose. C'est pas grave avec un cd en ligne de commande pour s'y placer dedans ça marche, donc en exécutant un script qui fait un cd puis l'éxécute ben c'est bon (ou j'aurais pu mettre le contenu de cpustressmt à l'arrache dans le home et c'était bon aussi sans cd du coup). Mais si on fait un lancement directe, ça ne marche pas, logique le pwd ne pointe pas dans le répertoire de cpustressmt...

Il te reste à inclure les sondes si possible (tu veux que je me plonge dessus pour te faire un module qui se base sur sensors?) et la charge système au niveau de cpustressmt.
Mais bon si tu rattrapes les fonctionnalités de la version windows ça sera un progrès énorme du côté de la version linux.

EDIT: pour la charge système voici un script qui te la donnera toutes les secondes:

Donc te suffit de récupérer les infos de /proc/stat et de faire de même en c++ et tu auras la charge totale.

le support des phenoms II sera de la partie sur la 1.1.0 stable ?

Burn2> Avec Tetedeiench, on a créé une interface afin que chacun puisse développer son propre plugin de monitoring.
Dans la version 0.10, je vérifierai que cette interface sera bien active. Ensuite libre à chacun de faire ses plugin, qui fonctionneront donc aussi bien avec CSMT qu'avec OCCT.
Pour plus d'infos, je te conseille de chercher dans nos 2 topics

neodam> 1.1.0 stable résultera du débugage des versions 1.1.0 beta, donc pas de support "officiel" des Phenom II et Core i7.
Mais je ne suis pas persuadé que le Phenom II soit très différent du 1. A mon avis il sera bien détecté, y compris la quantité de L3.
Cependant, Phenom II et COre i7 ne seront supportés officiellement que sur la version suivante (1.1.1).
Attention, quand je parle de support, il s'agit plutôt de "reconnaissance" des infos CPU : la validité du test de stabilité CPU n'est pas touchée. Même la version 1.0.4 marche parfaitement sur un Core i7.

L'interface est compatible linux?     Sinon m'en rappelle bien d'avoir croisé ça. Même que c'était dans un langage tout pourris tellement que je l'aimais pas.
Non sans blague, il me semble me souvenir que c'était du delphi ou quelque chose comme ça, m'enfin je verrais bien.

Non, non, c'est dans le langage que tu veux. Il faut simplement que la DLL soit dans un certain format, avec les bons nom de fonction et les bon types d'arguments.
Tetedeiench a dû les faire en Delphi et moi en C++. Mais rien n'empêcherait de faire ça dans un autre langage.
D'autre part, je vérifierai justement que cet interface/API est bien exploitable sous Linux (via un fichier SO).

Bonjour Fouge, j'ai une question. Tu dis en première page

Mais je ne comprend pas trop : si l'algorithme est identique d'un logiciel à l'autre (au hasard prime, orthos et CPU Stress MT donc, il me semble qu'occt utilise un autre algo), le résultat ne devrait pas être identique (au moins en théorie) ? Comment une interface pourrait-elle changer le résultats des calculs ?

Et pour répondre au sondage : un plugin intégré avec le VCore serait pas mal (mais pas indispensable non plus).

Bonsoir,
 
Petit retour sur CPU Stress MT 1.1.0 b9 et 1.0.4
 
CSMT semble moins apprécier ma machine que OCCT. Des séances de 3heures, ainsi que plusieurs séances de 1H et 30 minutes sur OCCT n'ont retourné aucun erreur avec un Vcore de 1.352V sur Q6600@3.6GHz. OCCT 2.0.1 était configuré en test mixte (CPU et RAM). En revanche, CMST retourne des erreurs après 13 à 31 minutes, toujours sur le coeur n°2, et ce jusqu'à 1.368V. Je teste avec 1.376V (actuellement en cours). Il y aurait les réglages RAM, puisqu'il me semble que CMST est proche du test Blend ou large FFTs de Prime95.
 
Les erreurs se produisent avec les deux versions de CMST. Par ailleurs, sous OCCT comme sous CMST, je continue une activité légère sur la machine (musique, vidéo ou lecture web). Avec de la musique ou de la lecture, CMST arrive à garder plus de 90% des ressources.
 
Avez-vous connaissance de retours similaires ? Une instabilité rapide sur un test, et une bonne stabilité sur un autre test (+test maison : OCCT+Mental Ray) ?

En fait l'algo de Prime95 existe en plusieurs modes (Small FFT, Large FFT, Blend) mais également dans un mode personnalisable. Selon les configs et le type d'instabilité, un paramétrage pourra détecter ou non (ou +/- rapidement) une erreur de calcul.
CSMT utilise un paramétrage spécifique non présent dans Prime95 (c'est le Large FFT qui s'en rapproche le plus) et qui s'adapte au CPU (caches L2&L3).
D'autre part, j'ai utilisé mon propre compilateur avec ses propres options de compilation, ce qui influe sur le binaire de sortie et potentiellement sur la capacité à +/- détecter les instabilités. CSMT n'est donc pas simplement une interface.
Mais là ou tu peux avoir raison, c'est qu'il est sans doute mieux d'utiliser 2 logiciels utilisant 2 algos bien différents, que basés sur le même algo.

Il est assez courant d'avoir des résultats différents selon les logiciels de tests. Le type d'instabilité fera qu'un logiciel saura détecter plus tôt qu'un autre une erreur de calcul. C'est donc très variable.
C'est pourquoi il est conseillé d'en utiliser plusieurs : si 1 seul d'entre eux affirme avoir détecté un problème c'est qu'il y en a 1.
Quand un logiciel affirme que tout va bien, c'est pas nécessairement vrai, cela veut juste dire qu'il n'a pas été capable d'avoir révélé l'instabilité. Seul l'allongement de la duré du test, et l'utilisation de 2 (ou plus) logiciels de tests permet d'avoir une plus grande garantie de la stabilité du PC.

D'accord merci bien pour ces explications très claires .

Je trouve le thème intéressant, d'un point de vue physique, la détection 'd'erreur', le temps de test comme ressource, etc.
Par ailleurs, sur ma machine, les températures en load sous CMST ou Prime95 sont inférieures de ~2°C à celles obtenues sous OCCT.

J'ai aussi une question d'ordre plus général sur les outils qui testent la stabilité du cpu : est-ce qu'un test de 2 fois X minutes est équivalent à 2 tests de X minutes ? Par exemple enchainer 4 tests d'1h ou faire un seul test de 4 heures revient-il au même en théorie ? (sans prendre en compte l'éventuel temps de pause entre les tests)

Ca dépend des algo? (calcul reprenant des résultats antérieurs par exemple, ce qui impliquerait des calculs de plus en plus complexes et/ou long).
Si oui où se situe cpu stress mt/prime/orthos (pour occt j'irai demander sur son topic).

Sur ce bonne nuit .

Ok j'essaierais de te développer ça pour linux (si j'ai le temps ), et voir si sur le livecd j'ai moyen d'automatiser la détection des sondes qui va bien.
Bref wait and see.

4 test d'une heure ne reviennent pas à 1test de 4h pour moi. Tout simplement car le facteur température et stabilité à la longue entre en jeu sur le test de 4h.
Sur 4h t'as une probabilité plus grande d'avoir une erreur que sur 4 test séparés, qui ne seront pas totalement consécutif (sinon moins tu laisses d'espace entre chaque test plus tu t'approches d'un test unique donc...). Cela dit normalement l'arrivée d'une erreur est aléatoire donc...

 
Effectivement, c'est du delphi pour mes dlls. Ca change pas bézef

 
Pour compléter la réponse de burn2 (avec qui je suis d'accord, donc je reviendrai pas dessus) : la plupart des tests utilisent une liste d'opérandes, nu jeu de test si tu préfère, fixe. l'idée étant d'avoir ceux qui sont le plus à même de détecter une instabilité au début. L'ordre est généralement fixe (cela apporte deux choses : les plus violents sont au début = plus d'efficacité, l'ordre est identique = grandes chances en pratique d'avoir l'erreur à un temps donné, moins aléatoire = plus d'impression de professionnalisme). Quand tu fas 4 tests de 1h, tu testes 4 fois le même jeu de test. Quand tu fais 1 test de 4h, tu fais 1 fois le jeu de test.
 
Personnellement, je pencherai pour le test de 4h

D'accord merci de vos explications .

Bon sinon là c'est pour Fouge : j'ai lancé un cpu stress mt hier soir, et il s'est arrêté au bout de 02:00:40

Le logiciel détecte une instabilité autrement que par erreur de calcul ? Comment ?

(oui j'arrête pas les questions en ce moment ).

edit : lire les messages d'erreur quand on est pas réveillé, c'est pas une bonne idée (j'avais lu "0 erreur de calcul" au lieu du "processeur 0" )  

edit 2 : 4h d'occt (en medium data set) ok, 4 heures d'orthos (small fft) ok, mais cpu stress mt me détecte une erreur en 1h30 ou 2h. On va dire que c'est pas 110% rockstable mais ça me va.

Bonne année 2009 !
 

Ah oui tiens, 2009 déjà

Bonne année à tous et toutes.

Y a pas beaucoup de retour sur la version livecd
Pour le pluggin de monitoring j'ai peur que ça s'approche du néant niveau retour.

J'ai pris le livecd dés sa dispo, mais j'ai manqué de temps pour tester .
Est-ce qu'il y a de quoi avoir les températures sur ce livecd ? Je ne sais pas à quoi me fier pour une config amd (en c2d il faut ajouter les 15° "habituels" à sensors).

Pas encore de quoi lire les temps sur le livecd, mais c'est en préparation.
Je penser me baser sur sensors justement. ça c'est le premier pluggin rapide à faire en préparation. Maintenant si tu connais d'autres logiciels pour lire la temps sous linux facilement, je suis preneur!
Notamment car chez moi sensors sous linux c'est des températures un peu à l'arrache pour mon X2. Et l'auteur répond que c'est un bug du X2 et pas de son logiciel. (plausible mais sous windows il ne me semble jamais avoir vu d'utilisateur raler à cause de mauvaises temps détectées...)

Bonne année 2009!
 
Serait-il possible de rappeler sur la première page ou sur le site les pré-requis nécessaires à CPUStressMT en environnement linux?
Je ne suis pas un pro de cet OS et à chaque fois que je fais des tests, CPUStressMT ne se lance pas car il manque des librairies, mais je ne me souviens jamais desquelles...
 
Pour le live CD, il me semble que je l'avais testé sous VirtualBox et que ça fonctionnait bien chez moi.
 
Edit : la dernière fois, CPUStressMT ne se lançait malgré le rajout des librairies QT, mais aujourd'hui ça fonctionne... tant mieux...

"Normalement" il lui faut simplement les librairies Qt4 (je ne sais plus quelle version au minimum mais n'importe quelle distrib à jour conviendra). Pour le reste, rien de particulier il me semble.

ya d'la concurence à OCCT ici

Ils sont complémentaires .

hum, 218w pour OCCT contre 215 pour CPU stresse

3W c'est rien
Teste l'algo Linpack et tu verras que c'est bien plus que le test CPU de CSMT/OCCT (qui ont une dissipation similaire).
D'autre part, chauffer plus ne signifie pas que la détection d'erreur sera plus efficace. Pour CSMT, je me suis basé sur l'algo de Prime95 pour son efficacité, pourtant il existe de nombreux algo qui chauffent plus que lui.

Est-ce qu'une erreur détectée par cpu stress mt est forcément causée par le processeur ? Ca pourrait être le chipset par exemple ? Car avec mon E4400 @3GHz j'ai des erreurs et je suis obligé de changer la fréquence du pci-e car le chipset est pas génial et je suis pas sur qu'il aime beaucoup ça (j'ai du trifouiller les paramètres bios pour que ça soit stable -hormis dans cpu stress mt donc)

La plupart du temps c'est CPU voire RAM. Le chipset (NB) c'est moins probable mais pas impossible.

C'est normalement libQT4-gui et libQT4-core.
Cela dit je viens de voir que j'ai un pb sur la suse en 64bit. Même avec cette lib d'installé ça me met toujours le même message d'erreur que libQTGui pas installé alors que si.
Concrètement:

EDIT: et c'est la 4.4.0 que j'ai d'installé, j'essaye avec la 4.4.3 mais je penche plus pour un problème due au 64bit...

De mon expérience perso, sur ma P5N-E SLI, c'était plus souvent le chipset que le proco (il est refroidi avec les pieds). Une fois le refroidissement du chipset changé, plus de problème...

Maintenant, c'était une carte mère très spécifique hein, en général, je suis d'accord avec michel et michel, c'est dans les moins probables

Bon j'ai trouvé le problème... En fait pour les version 64bit, il faut libQT4gui 64bit et 32bit (nommé libQT4-X11(64bit) et libQT4-X11-32bit sous OpenSuse) ainsi que libQT4core et libQT4Core-32bit (nommé libQT4 et lib QT4-32bit sous OpenSuse)
Le nom des lib en question nécessaires normalement c'est:
libQtGui.so.4
 libQtCore.so.4

Donc ces deux lib en version 4.0 suffisent.

EDIt: Ah ben non ça veut pas...

Va faloir que tu compiles une version 64 bit car là c'est clairement problématique. Je ne vois rien qui bloque. Cela dit un de mes programmes compilé en QT aussi me sors la même chose, je vais le recompiler sur cette machine voir si ça change si c'est le cas ça implique d'avoir deux versions, une 32 et l'autre 64 bit.

EDIT: c'est ça après recompilation sur une machine 64bit ça passe... Il te faudra donc compiler à la fois sur une machine 32bit pour du 32bit et une machine 64bit pour pouvoir couvrir tout le monde sinon y a risque de conflit. Peut-être un flag à mettre lors de la compilation vu que j'ai le même problème sur mes logs aussi.