Reprise du message précédent :

 
En un peu plus de mots, je vais dire que pour l'instant j'ai trouvé aucun soft de test fiable, depuis que je suis en dual core. Alors que tous me disaient stable (et je parle de tests genre 24h de double SP2004), j'avais des erreurs à SETI@home. J'ai augmenté le vcore, plus d'erreurs.

Lisez la dernière page : http://www.overclocking-masters.co [...] 783-p3.htm
 
asmomo> si t'as un compte là-bas, n'hésite pas à poster ce que tu viens de dire

 
Puisque que quasiment aucun n'est adapté au smp, les avais-tu correctement utilisé ?
 
SP2004, il faut régler, à chaque lancement, l'affinité. Un SP2004 par CPU logique.
Ensuite, un en test CPU seulement, et l'autre aussi, ou CPU+quantité de RAM si tu veux voir si la RAM foire. Si le 2e geule, tu refais les tests en inversant, etc.. pour te faire une idée si c'est le CPU ou la RAM.
 
Chez moi 2 SP2004 bien réglé, ça m'indique des erreurs (plus ou moins rapidement, ça peut gueuler au bout de 6-8 heures).

La RAM n'est pas en cause. Et pour SP2004, on m'a aussi dit exactement le contraire (qu'il ne fallait pas assigner les cores). Perso j'avais assigné.

Et pourtant, il faut
 
Quasi aucune efficacité en "libre", et si des erreurs sont detectée, tu ne sauras pas de quel CPU logique ça vient.

Groody> Avec tes réglages actuels, je suppose que SP2004 ne te détecte pas d'erreur. Comment savoir qu'il n'aurait pas dû en déteter une justement ?
J'avais déjà parlé de ça à asmomo, il a fait ça correctement (assigné à chaque CPU), et seul SETI@home pose problème. Sans ce soft, il aurait certainement fait confiance à SP2004 en croyant sa machine rock stable, prete à affronter n'importe quel logiciel aussi intensu soit-il. Perdu...

Je ne dis pas le contraire..
 
Je demandais juste si il avait correctement utilisé le soft (les principes du SMP/softs multithreads/etc. sont nouveaux pour le grand public, et je ne pense pas que tout le monde sache comment correctement exploiter/utiliser tout ça. Alors, je vérifiais.

En tout cas, une chose est sûre : il FAUT assigner chaque SP2004 à un CPU différent.
CPU Stress, en interne, créé un thread assigné à chaque CPU. Il ne faut pas faire autrement.

 
Je n'en suis pas aussi convaincu que toi. Car à l'usage courant, comme SETI, les processus sautent sans cesse d'un core à l'autre. Et du moins sur mon opteron, les 2 cores communiquent entre eux, et ce de façon interne (mon Presler c'est 2 cores Cedar Mill collés sur un package, qui communiquent par le chipset).

asmomo> C'est pas bête comme idée, mais 2 processus distinct, qu'aurait-il a se dire, à transmettre, à partager ?
Et comment ça se comporte au niveau du cache ? Le cache est transféré à l'autre core ou il y accède via le crossbar (sur les X2) ? Ou il refait un accès direct en RAM, recréant naturellement les variables utilisées dans le cache du core en cours ?
T'as déjà fait une comparaison de 2 SP2004, soit libres soit assignés ?

Interessant comme projet
 
C'est fait en quoi ?

 
je me demande si ce serrait possible de faire continuer le prog en ayant une erreur ? comme ca moins tu as d'erreurs + tu as des chances que ce soit stable , jusqu'au 0 error  
 
Le but etant de voir si en 10 min tu as 10 erreurs, de changer des parametres et d'en avoir + que 5 , etc ...... pour savoir ce qui jou le plus dans la stabilité

C++, un peu d'ASM, interface en QT4 et le tout sous VS2003.
 

Pas mal, le bug des 11h56 a été corrigé (j'avais vérifié, en trichant).
Continuer malgré les erreurs... mwè jusqu'à ce que ça plante carrément la machine ! J'suis pas super convincu, mais c'est pas techniquement impossible à faire, au contraire.
 
Personne n'a fait de test avec machine instable, voire une comparaison avec la 0.12 ? J'suis déçu

 
 
enfaites j'ai trouvé le prog, qui me fesait des +12ms toutes les secondes, firefox  

Demain normalement je pourrais te faire ça !

la_lootre> Avec la v0.13 il n'y a plus de correction de timer, donc finit les +1ms
shurl> Cool
 
Si je vous demande de tester sur de l'instable et de comparer avec la v0.12 c'est parce que l'algo de vérification (ne pas confondre avec l'algo de stress) est différent et bien plus rapide.
Donc théoriquement, ça devrait etre un poil plus stressant, mais faut voir si la détection en elle-même est aussi efficace.

Je télécharge et je me démerde a voir sur mon barton ce qui se passe! Résult demain ou dans l'aprem si possible. Et vu que j'ai un peu de temps je vais programmer un peu tien!  

Et c'est possible de faire un truc a la ati tools? Qui augmente la fréquence au fur et a mesure  jusqu'a ce que ca soit pas stable?

 
Non. Et franchement, je comprends mal comment ça fonctionne. Je suppose que si ça saute d'un core à l'autre, c'est que le "sous-calcul" en cours est fini. Mais même comme ça, ça nous paraissait complètement contre-productif, à moi et à d'autres, alors ThierryH a modifié BOINC pour assigner les WU aux cores => strictement aucun gain.
 
Sinon SETI, surtout avec les clients optimisés, utilise beaucoup de BP mémoire.

Lagger> Non. Ou alors en passant par l'intermédiaire de Clockgen (en ligne de commande) mais j'sais pas si c'est possible.

La dernière version de ClockGen ne permet les lignes de commandes. C'est marqué dans la doc.
C'est prévu depuis plusieurs semaines, mais toujours rien.
 
J'attends une nouvelle version pour enfin pouvoir OC en ligne de commande après le boot et le login sous XP (puisque SpeedFan est incapable de gerer la fréquence sur la CM Nforce4 en dynamique en fonction de la charge ;'( ).

asmomo> Je pourrais éventuellement faire une version (en mode console) de l'algo qui passe succesivement d'un CPU à l'autre avec le temps de chaque calcul. Ca permettrait de voir s'il y a ou non perte de perf et éventuellement déduire quelque chose
Tu serais partant ? J'ai pas de dualcore moi.

Pour ceux qui ont un dualcore (ça test le basculement d'un CPU à l'autre) :
http://olivier.fouge.free.fr/OCCT/CPU_Burn_alt.zip

Je teste sur mon Presler.

ProcessAffinity : 3 SystemAffinity : 3
Sur CPU 1 : calcul=2035ms verif=0.040ms
Sur CPU 1 : calcul=2005ms verif=0.015ms
Sur CPU 1 : calcul=2007ms verif=0.016ms
Sur CPU 1 : calcul=2011ms verif=0.015ms
Sur CPU 3 : calcul=1990ms verif=0.014ms
Sur CPU 3 : calcul=1990ms verif=0.014ms
Sur CPU 3 : calcul=1989ms verif=0.014ms
Sur CPU 3 : calcul=1995ms verif=0.022ms
Sur CPU 1 : calcul=2011ms verif=0.014ms
Sur CPU 1 : calcul=2097ms verif=0.014ms
Sur CPU 1 : calcul=2157ms verif=0.015ms
Sur CPU 1 : calcul=2134ms verif=0.015ms
Sur CPU 3 : calcul=1991ms verif=0.015ms
Sur CPU 3 : calcul=1989ms verif=0.014ms
Sur CPU 3 : calcul=1996ms verif=0.014ms
Sur CPU 3 : calcul=2016ms verif=0.013ms
Appuyez sur une touche...

Presler, c'est du Netburst ça
Quelqu'un d'autre pourrait tester sur un X2, pour voir si le comportement diffère ?

Opty 165:
 
ProcessAffinity : 3 SystemAffinity : 3
Sur CPU 1 : calcul=2089ms verif=0.472ms
Sur CPU 1 : calcul=2058ms verif=0.016ms
Sur CPU 1 : calcul=2060ms verif=0.016ms
Sur CPU 1 : calcul=2100ms verif=0.027ms
Sur CPU 3 : calcul=1952ms verif=0.016ms
Sur CPU 3 : calcul=1936ms verif=0.020ms
Sur CPU 3 : calcul=1944ms verif=0.015ms
Sur CPU 3 : calcul=1948ms verif=0.027ms
Sur CPU 1 : calcul=2065ms verif=0.015ms
Sur CPU 1 : calcul=2086ms verif=0.019ms
Sur CPU 1 : calcul=2048ms verif=0.016ms
Sur CPU 1 : calcul=2055ms verif=0.016ms
Sur CPU 3 : calcul=1940ms verif=0.017ms
Sur CPU 3 : calcul=1951ms verif=0.030ms
Sur CPU 3 : calcul=1951ms verif=0.020ms
Sur CPU 3 : calcul=1937ms verif=0.015ms
Appuyez sur une touche...

Chez moi :
ProcessAffinity : 1 SystemAffinity : 1
Sur CPU 1 : calcul=1982ms verif=0.054ms
Sur CPU 1 : calcul=1973ms verif=0.038ms
Sur CPU 1 : calcul=1980ms verif=0.037ms
Sur CPU 1 : calcul=1981ms verif=0.037ms
Set Affinity Mask Error Code: 87
 
En lançant plusieurs fois, j'obtien toujours les même résultats et la seule différence se situe au niveau de l'algo de vérif (la 1ère fois uniquement). Ensuite ça doit etre mis en cache et c'est accéléré.
 
asmomo> Sur ton Presler, meme comportement au niveau de la verif. Et meme en repassant à l'autre core ça repasse pas à 0.040
Par contre l'algo de calcul est plus rapide sur le 2ème core, que le 1er

Mon opteron :
 
ProcessAffinity : 3 SystemAffinity : 3
Sur CPU 1 : calcul=1687ms verif=0.419ms
Sur CPU 1 : calcul=1688ms verif=0.015ms
Sur CPU 1 : calcul=1678ms verif=0.014ms
Sur CPU 1 : calcul=1663ms verif=0.016ms
Sur CPU 3 : calcul=1661ms verif=0.014ms
Sur CPU 3 : calcul=1656ms verif=0.017ms
Sur CPU 3 : calcul=1670ms verif=0.014ms
Sur CPU 3 : calcul=1661ms verif=0.015ms
Sur CPU 1 : calcul=1658ms verif=0.014ms
Sur CPU 1 : calcul=1654ms verif=0.015ms
Sur CPU 1 : calcul=1656ms verif=0.014ms
Sur CPU 1 : calcul=1655ms verif=0.016ms
Sur CPU 3 : calcul=1658ms verif=0.014ms
Sur CPU 3 : calcul=1660ms verif=0.016ms
Sur CPU 3 : calcul=1671ms verif=0.015ms
Sur CPU 3 : calcul=1667ms verif=0.014ms
Appuyez sur une touche...

 
Le PC est utilisé (emule + BOINC).

lombric> Tient, toi aussi, ton 2ème core est un poil plus rapide. Phénomène identique avec l'algo de verif. Lent uniquement la première fois. Le changement de core n'a aucune influence.
 
Bref, les caches doivent se mettrent à jour (ou un truc dans le genre). Ca ne repasse pas en RAM, sinon on aurait les meme temps que le tout premier lancement.
 
Ha mais j'ai une idée pour la lenteur du 1er core : ça doit etre tous les processus "système" qui tournent dessus.
 
asmomo> ha ok.

Sortie de la version 0.13b
- correction de l'algo de vérification bugué : il n'est plus que 8% plus rapide mais au moins il marche bien
 
http://olivier.fouge.free.fr/OCCT/CPU_Stress_0.13b.zip
 
Ce qu'il y a à tester :
- comparer l'efficacité de la 0.12 et de la 0.13b
- tester la détection de fréquence (au lancement du logiciel) sur des processeurs Mobile

Fouge > tu dois savoir pourquoi je débarque mais justement je débarque c.à.d. que je ne sais pas trop bien ce qu'il faut tester finalement.
Cette 0.13b est la première que je teste et je suis un peu perdu
C'est lancé @2646 pour le moment voilà
 
EDIT : stable 3 minutes je dois y aller alors @+
 
Mais je vais te suivre dorénavant

Et bien tu tests la 0.13b : tu choisis la durée, la priorité et tu clic sur "Executer". Si ça détecte une erreur, il s'arretera tout seul.
Que dire d'autre ?

Que c'est bien et te remercier
Alors c'est bien et je te remercie... demain

Bon me voilà avecv mon test qu'en fait je n'ai pas pu faire!!! je viens de me rendre compte que j'ai un cpu qui vient de mars!!! Je m'explique: 200*11 1.55v Rox stable aucune erreur sur aucun log, aucun problème. Je me dis ok je baisse le vcore a 1.525 et je regarde les erreurs! Mais impossible, le pc fige ou reboot! Je me dis ok ben je monte le fsb de 5mhz, pareil Impossible de faire faire des erreurs à mon cpu; soit c'est stable soit un rien le fait merder ! Donc pour vérifier l'algo Moi pas comprendre là lol. Sinon j'ai codé un peu hier fouge si je peux te croiser sur msn...

Testé avec plusieurs logiciels ? Et quelle version de CPU Stress (0.12, 0.13, 0.13b) ?

Re
Je teste dans la soirée

Avec SP 2004, OCCT et ton log version 13. Dés que je met +5mhz sur le fsb ou -.25v paf freeze ou reboot lord du test.....  Et 1.55v Rox stable  

Si çà plante c'est que ce n'est PAS stabeul
Voir du côté dur refroidissement ou augmenter le Vcore il n'y a que çà de vrai !!!

En fait il esssaye d'etre "un peu" instable pour que les logiciels détecte les erreurs mais il passe direct du stade rock stable au stade très instable.
 
Burn2> Tu devrais essayer de changer le FSB MHZ par MHZ, 5 ça fait beaucoup.