Reprise du message précédent :
IC:
--
http://rafb.net/paste/results/MxpzAG10.nln.html
 
MS:
---
http://rafb.net/paste/results/Bun6zt41.nln.html

T'as fait à des fréquences différentes ?
Essaye de me faire un p'tit tableau récapitulatif, ou alors tout simplement de me dire le quel des 2 (IC ou MS) te semble le plus efficace dnas la détection des erreures.

Effectué a la même fréquence, l'IC m'a semblé plus efficace par rapport au  MS.
Mais je vais essayé de faire ca plus rigoureusement (même protocole de test, effectué à intervalle de temps, histoire que la chaufferie de l'un, n'influe pas sur le test de l'autre

Je testerai l'IC en 1er alors

Merci les gars.  
J'vous dis bonne nuit et à demain  

L'ordre des tests a été fait de gauche à droite et de bas en haut (IC -> MS -> IC -> MS)
A gauche 2 essais pour l'IC, à droite 2 pour l'MS
 
EDIT : dans les même conditions, OCCTPTRC2 n'a détecté une instab qu'au bout de 22 minutes
Re-EDIT : on prend les mêmes et on recommence, Orthos mode "Large" tient 30 minutes, je l'ai arrêté sinon il aurait continué  
 
Voualou

En tout j'ai effectué 7 tests pour chacune des versions. J'ai éteins le pc et ouvert les fenêtres pour libérer la chaleur avant d'effectuer les tests sur l'autre version.
 
Intervalle de pause entre chaque test :
1 -> 2 : 10 minutes
2 -> 3 : 5 minutes
3 -> 4 : 2 minutes
4 -> 5 : 1 minutes
5 -> 6 : 30 secondes
6 -> 7 : 6 secondes
 

 
log IC   -   log MS

Antibug> C'est surtout pour comparer l'efficacité à trouver une erreur de calcul. Entre 1 version qui met 1min pour le trouver et l'autre qui tient 30min sans problème, on peut en déduire certaines choses
 
BIERMAN & doGus> Merci
Au vu des résultats j'ai pas l'impression qu'il y ait de différence significative entre les 2 versions. J'avais espéré que l'un détecte au bout d'une minute et l'autre rien du tout au bout de 5min...
Par contre petite différence de T° chez doGus, +2°C environ en faveur du MS.
 
BIERMAN> Peux-tu me faire un test (en stable) pour voir s'il y a une telle différence aussi ? Genre au bout de 5 ou 10 min de test de chaque version (en prenant soin de commencer avec une T° idle identique). Merci
 
Pour ce soir, je vais avoir besoin de quelqu'un qu'il fasse quelques tests sur un P4 HT. Je lui donnerai les instructions en MP

J'ai un p4b si tu veux...

C'est l'Hyper-Threading qui m'interesse

Ah pardon comme tu disais architecture netburst... Et les céléron ont toujours l'HT ?  

Si t'as des CPU Intel à tester, tu peux faire avec ça :
http://olivier.fouge.free.fr/CPUSt [...] tect38.zip
 
Pour l'HT, c'est un autre truc bien spécifique que je proposerai ce soir.
 
edit: aucun Celeron n'a l'HT, ya meme certains P4 Prescott qui ne l'ont pas.

 
BIZARRE
j'etais persuadé qu'avec le 0.32 il allait me detecter l'erreur que j'avais au bout de 20' avec la version 0.30 beaucoup plus vite
quenéni...
Je suis maintenant stable   avec les 2 versions  
 

 

 
en tous cas moi je suis content    
Et ça parait logique puisque je suis stable ave OCCT PT (CPU&RAM) et Orthos (large FFT)
 
Au niveau temp +1° pour MS

J'suis pas content puisque ça veut dire qu'il n'est pas plus efficace
 
Et je vais rappeler une chose : sur un PC instable, la durée avant que le 1er bug est aléatoire. Avec la 0.30 tu tenais que 20min, mais en insistant t'aurais finit pas réussir à passer une session de 30min... et d'en conclure (à tort!) que le PC est stable.
 
Retente la 0.30 (ou 0.31) pour voir
Sérieusement, car c'est la même chose (ou presque) que la version MS.
Et puis si ça tient pas 30min, ça tient pas 1h, j'en suis persuadé

J'ai vraiment eu l'impression de me faire engueuler alors que si je me tape ces tests c'est pour te rendre service à ta demande
sinon je me refais un 0.30 pour confirmer

T'inquiète je t'engueulais pas Les p'tit bonhomme rouge ne sont pas, à mes yeux, des smiley colèriques.
J'ai juste noté que t'étais content que les 2 versions 0.32 passent ce qui te parait plus logique (car + en accord avec CP2004 & OCCT). J'pense que t'as eu pas de chance avec la 0.30 en "plantant" en seulement 20min.
De plus, au contraire de toi, je ne suis pas content parce que ces 2 versions se révèlent chez toi pas meilleur (et meme moins bon). Et c'est pas de toi que je ne suis pas content, mais de mon propre travail

je relance un 0.30

pire qu'hier  
c'est plus 20' mais 7'59''
avec le 0.30
evidemment je n'ai rien changé entre hier et aujourd'hui

J'ai d'abord cru à une coïncidence (vu le caractère aléatoire de l'apparition des erreurs de calcul) mais là tu me mets le doute.
Je vais faire des tests plus poussés sur ma machine...
 
edit: normalement 0.30 = Pre-0.32 MS, et les fichiers StressTess.dll ont une taille identique à l'octet près

pourtant la 0.32 est passé super bien je l'ai fait 4 fois 30' alors que la 0.30 n'a jamais dépassé 20' ( 4 essais en tout )

Hum
 
J'ai fait un test pendant 2h avec la 0.30
 
Aucune Erreur , pourtant il me dit que le pourcentage moyen d'utilisation cpu est insuffisant, donc système non stable ?
 
Pourtant ça passe 4h de prime95 sans fautes ...

olitorre> C'est pour ça que je suis en train de faire des tests plus poussés, car cette différence me parait significative.
Quant à la DLL, la taille est strictement identique mais pas le contenu (je viens de le vérifier).
 
BiLOo> Quel pourcentage t'avais ? Si t'as aucune erreur alors c'est bon. Il s'agit simplement d'un message d'avertissement concernant le % CPU, c'est juste à titre informatif. Je considère que si c'est < à 95% alors cela n'a pas stressé sufisament le CPU et qu'il serait préférable de recommencer en enlevant certaines taches qui bouffaient un peu de CPU.

Le pourcentage moyen était de 94.5 %
 
Mais j'avais pas fait gaffe j'avais ***torrent qui tournait  
 
J'en relance un cette nuit pendant que je fais dodo

J'ai fait quelques tests supplémentaires chez moi, et je n'ai pas vu de différence significative entre les 3 (0.30, 0.32-MS et 0.32-IC). Dans le doute, je vais repasser avec les paramétrages du 0.30
Merci à vous pour tous ces tests
 
NB: je cherche toujours quelqu'un avec un P4 HT

ben alors ma proposition était normale comme tu as dis architecture net burst et que tu demande des célérons p4 et core duo2 je me suis dis il demande juste des netburst et nouveau core duo2 pas des ht Bref "je m'a pas gouré" Sinon je commence l'assembleur c'est simpas sauf qu'une question me vient à l'esprit tu fais comment pour adapter le code en fonction des architectures?  
 
 
Edit :  

Burn2>

J'ai plus que ça à finir pour sortir la 0.32
 
Et pour le code en fonction de l'archi, ou plutot des instructions, c'est géré justement grâce à la détections des instruction gérés par le CPU

J'avais vu la ligne du bas oui mais moi je répondais à celle du haut  
 
Ok c'set ce que je me disais Mais alors ça fait une multitude de code différent au vu des architectures non? Car les instructions sont totalement différentes en fonction des architectures (ex athlon 64 power g5 et p4) non?
 
Sinon ps  

En fait il faut distinguer architecture et instructions.
Un binaire ne marchera que sur une archi spécifique. Du X86 ne marchera que sur du X86 et pas sur un G5 par ex.
Mais à l'intérieur même d'une archi, les CPU n'ont pas tous les même instruction (MMX, 3DNow, SSEx...). Il y a 3 solutions :
1) faire un binaire "universel" qui tournera sur TOUS les CPU X86 qui n'utilisera donc aucune instruction spécifique
2) faire un binaire pour chaque type de CPU (binaire MMX, binaire SSE...)
3) faire un code avec des "path", cad qu'il appelera des fonctions utilisants des instructions spécifiques en fonction de la gestion ou non de ces instructions. Ex :

ça j'ai bien compris mais en fait ce que je dois mal avoir compris pour le moment c'est quand tu code en asm , les instructions pour commander en asm ne sont pas du tout les même selon les architectures donc tu fais plusieures fonctions? Ou alors je n'ai pas tout compris sur l'assembleur encore. Mais quand tu codes en assembleur t'es obligé de prendre en compte l'architecture vu que le par exemple pour faire une soustraction sur le power G5 c'est subf r3,r4,r3 par exemple, cette instruction change bien selon les processeurs non? Ou tu n'utilises que des instructions qui sont communes aux architectures genre x86 et qui donc passe partout même si c'est du sse x86? Bref je sais pas si j'arrive à bien m'expliquer et je n'ai surement pas du apprendre assez d'assembleur pour vraiment tout comprendre pour le moment.  

En ASM, t'es obligé de coder que sur une seule archi, en utilisant le langage ASM de l'archi correspondante. Dailleurs le compilateur sera différent.
ASM X86 -> compilateur ASM X86 -> Binaire X86 qui tournera que sur des CPU X86.
ASM PowerPC -> compilateur ASM PowerPC -> Binaire PowerPC qui tournera que sur des CPU PowerPC.
 
Là tout est différent : le code ASM + le compilo ASM + le binaire. Il n'est pas possible de faire un binaire compatible avec toutes les archis CPU qui existent. C'est la raison pour laquelle, par ex, les distributions Linux sont déclinées dans toutes les architectures.
Ex de Ubuntu (386, AMD64, PowerPC, Spark) :
ftp://ftp.proxad.net/mirrors/ftp. [...] eases/6.10
 
Ensuite à l'intérieur même d'une archi, tu peux tomber sur des instructions qui sont spécifiques à certains CPU. Et là tu tombes dans les 3 cas expliqués dans mon post précédant.

CPU_Detect38 :

cpu-z : 2595.4 MHz ~ 2595.5 MHz.
c'est un F33.

2595MHz correspond-t-il à la fréquence de boot ou est-ce modifié par logiciel ?
Peux-tu tester avec CPU Stress 0.31 ?
1) fréquence détectée au démarrage
2) fréquence au bout d'1min de test
 
Merci

fréquence règlée au boot.
Ok,je teste ca.

1) 2616.17 MHz
2) 2609.76 MHz

Il retombe toujours sur cette fréquence de 2609MHz. Bizarre qu'elle soit différente de celle de CPUZ (2595MHz). Que donne les autres logiciels ?
Cette différence n'est pas bien grave, mais d'habitude elle est inférieur à 1MHz

oué,surement parce que c'est un F33.
CrystalCPUID 4.8.3.313 : 2609.50 MHz puis refresh WT (F6) -> 2596.86 MHz
F7,F8 et F9 donnent ~ 2609 MHz.

Tous les Netburst >= F30 ont un TSC fixe, ce qui a certaines conséquences sur les techniques habituelles de mesure de fréquence.
Serait-il possible que tu fasses un Detect38 avec ton P4 mais avec la fréquence modifée par SetFSB, ClockGen ou autre ? Bref une mesure à une fréquence différente de celle du boot (2550 ou 2650MHz par ex).
Merci

 
Pas possible du moins pour le moment (mobo en bois).
Mais,dès que j'en ai la possibilité,je te le ferai.

Ok donc j'avais compris. Mais donc les cpu amd sont aussi architecture X86, car sinon te faudrait deux log pour amd et intel non? Pour les instructions c'était bien entendu évident Tu vas pas utiliser du sse2 sur du p1

Effectivement les CPU Intel et AMD ont la même architecture, ou plutot, les 2 même architecture (X86 et X86-64). C'est la raison pour laquelle on n'a pas besoin de faire de logiciel "spécial AMD" ou "spécial Intel".