Reprise du message précédent :
Ptet, mais tu le fais bien ..
Merci pour nous

 
Je peux le couper pour ce soir ?

Une version par jour, pas plus. Tu peux

Au niveau de l'ocupation cpu des droles de chose, il passe de 100% a 135% puis a 37% puis re 130% et hop 100%(synchro sur les 2 cores la plupart du temp)

J'étais étonné que ça n'arrive pas. Je faisais confiance à la régularité de mon timer (toutes les 1s). T'es la preuve que j'aurais pas dû. Dommage car ça me simplifait pas mal...

Idem ça fait des choses bizarres.

Essayez à nouveau, j'ai finalement trouvé une solution simple. Ca devrait etre bien + précis normalement.
http://olivier.fouge.free.fr/OCCT/CPU_Stress_0.05.zip
 
edit: j'ai également ajouté l'affichage de quelques informations dans la zone de log

 
Globablement OK pour moi. Cependant, j'ai constaté quelques fois (principalement lorsque d'autres gros accès cpu se font) que le compteur d'occupation montait à + de 100%.

 

 
en fait, il teste quoi ce log ?
 
parceque j'ai aucun accès ram et aucune requète sur le cache L2....
 
normal ?
 
sinon, c'est bon.
 
"Ce que vous devez tester :
- bonne détection du cache L2 : OK
- sur dualcore ou bi-CPU, vérifier dans le gestionnaire des tâches que les 2 CPU sont à 100% : NA
- vérifier que l'affichage du/des % CPU dans le logiciel est correct : OK
- vérifier à la fin du test que la fréquence processeur est la bonne : OK
 
@+
 
Pink.

Nouvelle Revision du 0.05
 
- bonne détection du cache L2= OK
- sur dualcore ou bi-CPU, vérifier dans le gestionnaire des tâches que les 2 CPU sont à 100%= OK
- vérifier que l'affichage du/des % CPU dans le logiciel est correct= OK
- vérifier à la fin du test que la fréquence processeur est la bonne= OK
 
Cool ça prend forme, ne pas relacher l'effort

salut,
 
Je suis en monocore, mais je donne mon avis.
   Ca vient bon    
 
L'utilisation 95/100% du CPU la T° grimpe vite.
Fin du test = Bonne fréquence

PinkFloyd31> Pour l'instant l'algo est provisoir et pas très efficace. Celui-ci cèdera sa place en temps voulu, et dès que tout le reste sera au point.
Tout tient dans le L1 d'où l'absence d'accès au L2 ni à la RAM.
 
lombric> Pourras-me faire un screenshot avec cette version quand t'as un % > 100 ? T'as le droit à quelques secondes de réaction, c'est le log qui m'interesse.
http://olivier.fouge.free.fr/OCCT/ [...] _debug.zip (mettre l'exe dans le même répertoire qu'une autre version)
 
metha> Nickel, les % sont donc OK.
 
edit: pour tout ceux qui ont des pb au niveau du %, faite comme pour lombric, testez cette version debug

Fouge> pour les % ça ne dépasse plus les 100%, les 2 core sont a 100% mais toutes les 15sec (vraiment toute les 15sec c très précis) un des 2 core passe a 98.4%(toujours 98.4%) mais cela ne dure qu'une petite seconde et retour a 100% et 15sec après un petit 98.4% puis retour a 100% et 15sec après  98.4% retour a 100% et 15sec après 98.4%.......
 
Pour les 98.4% dans le GDT cela n'apparaît pas, pour le GDT c toujours a 100% sur les 2 core.
Mise a part le petit problème des 98.4%(bizzard c toujours 98.4% et toute les 15 sec) ça roule.

Ce qui est indiqué c'est le % d'utilisation CPU par le thread alors que dans le GDT c'est le total de tous les processus.
Il suffit que toutes les 15s, il y en ait 1 (ou plusieurs) qui prenne 1.6% alors forcément, mon thread n'en prendra que 98.4%
En plus de ça, ça doit etre fiable à +/- 1%. Normalement ça doit tourner à 95-100% dans CPU Stress, et 100% constant dans le GDT.
 
Ce qui m'interesse c'est d'avoir un retour sur une config qui aurait des % "étranges" (très bas, ou dépassant les 100%). Dans ce cas, utilisez la version debug :
http://olivier.fouge.free.fr/OCCT/ [...] _debug.zip

Bon ben ça avance!! C'est bien à tous

Ha ben tient, t'aurais le temps de tester sur ton P-M et ton Celeron Mobile ?

Les entrées en rouge dans le log correspondent à quoi?
 
A la fin d'un petite session d'environ deux minutes, j'ai eu des pointes à 101 et 105%, je vais essayer de te capturer le bon endroit du log.
 

En rouge c'est quand ça dépasse 100 % et théoriquement le timer est de 1000ms.
Avant je lui faisait confiance et basais mes calcul sur 1000, mais finalement je remesure le temps à chaque fois car c'est pas fiable.

Pour info, c'est arrivé environ 20x en deux minutes.

Bon je t'accorde Pentium M tout de suite, le céléron est rangé et je vais aller manger. Donc je vais lancer sur mon pentium M et le céléron dans l'aprem + P4B si tu veux

Bon sur mon pentium M, je suis en train de le lancer là, ça monte bien à 100% Mais les autres processus prennent le dessus sans problème, ça déssend souvent a 98.4 sans rien faire d'autre et le pc reste utilisable sans aucun problème ??? Bref ça rame pas du tout, c'est même pas génant, sinon sur le gestionnaire, ça reste bien tout à 100% mais pour moi le niveau de priorité n'est pas suffisant. Le log a du mal à maintenir le 100% avec firefox, et mes log d'idle... Reste à voir la fréquence moyenne aprés. En gros les autres processus prenent le dessus sur lui, il dessend même a 85%

Sinon, fréquence moyenne ok:
 

 
 

 
 
Mais je suis sur que si je lance un autre log il prend le dessus car juste en  maximisant réduisant firefox ça ne ram pas du tout et le processus perd en %

Ce niveau de priorité a été volontairement choisi. Je voulais que le PC soit utilisable mais qu'il prenne tout de même + de 90% des ressources, seuil minimum exigé pour que le test soit validé.
S'il descent parfois à 85% c'est pas grave du tout : meme en utilisation "bureautique" je suis sur que l'utilisation moyenne est de 95% ce que je considère suffisant.
 
Content que la fréquence en burn du PM ait bien été détecté

Pour les % "étranges" (très bas, ou dépassant les 100%), utilisez la nouvelle version de debug :
http://olivier.fouge.free.fr/OCCT/ [...] _debug.zip
 
Pour info, ligne rouge=problème (% > 100)

 
Si tu essaies OCCT ou Prime95, tu auras le même résultat, ils n'ont pas une priorité haute par rapport aux autres processus
 
@Fouge, c'est un très beau travail que tu effectues, si j'ai le temps je testerai ton programme sur mon A64 et mon PM (j'vais voir comment il s'en sort si je gère manuellement la fréquence du PM )

PinkFloyd31 (Pink Floyd !!), avec quoi tu vois l'utilisation du cache, etc. ?

PerfMonitor : http://www.cpuid.com/perfmon.php

Ce que je veux dire c'est qu'il dessend même a 78%, je suis sur que je si je lance un jeux ça reste fluide mais ton processus sera beaucoup moins utilisé, je ferais le test pour voir.Au fait, j'avais eu exactement la même idée que toi, faire un log dans ce genre, mais tout simplement genre cpu burn pour apprendre, mais je m'étais arrété beaucoup plus tôt et j'aurais jamais fait ce que tu as fait donc franchement chapeau!! Pour l'algo, que dirais tu de calculer PI? L'algo n'est pas propriétaire de super pi et le calcul est infini, donc pratique, reste à l'implémenter. T'en penses quoi? Ou alors une suite genre fibonachi, dans ce genre, puisque c'est exponentiel, mais reste à voir si ça utilises assez d'instruction?  
 
Pour le pentium M normal que tout roule, il monte trés vite en fréquence c'est sur le céléron que j'ai des doutes, on verra ça cet aprem. Quand à occt, chez moi il est toujours à 99.8% d'utilisatoin sur mon barton...  Et ne parlons pas de sp2004.
 
Mais en tout cas trés bon boulot fouge, vraiment respect et continue comme ça
 

SP2004 a une priorité varible (entre 1 et 10), mon logiciel est à 8.
 
Pour l'algo à utiliser, faire monter à 100% ou faire chauffer un max c'est facile. Implémenter un algo qui "pousse" le CPU à l'erreur ainsi qu'une détection des erreurs de calcul FIABLE et EFFICACE ça l'est beaucoup moins !
 
Concerant le % de conso CPU, je vérifirai qu'il soit à 90% mini. C'est pas fait pour etre utilisé en meme temps qu'un jeu ou qu'un autre processus "lourd". Par contre je veux permettre une utilisation "basique" du PC comme surfer par ex.
 
Petit rappel :

 
A ce soir

Oki, ben justement avec l'algo de pi, c'est facile de vérifier Pour la suite de fibonachi je ne sais pas trop. En tout cas Bravo pour tout et bon aprem.

Bon je test sur mon céléron cet aprem. En tout cas sur mon pentium M une fois lancé ton programme ne me géné en rien pour écouter la musique avec windows media player qui n'est pas un des plus légé+ surf avec antivirus avast. Pour moi le niveau me semblait bas .

 
Si je le lance alors que SETI@BOINC est en route, il n'utilise qu'un seul core, ton soft.

La priorité me semble trop faible pour un test. On s'en tamponne des autres process quand on test une machine.
La priorité qui laissait accaès au bouton stop est la meilleure pour moi (ça me gonfle terriblement de ne pas pouvoir arrêter un stress test ... )

Moi je pense pareil, si on test c'est pour tester la stabilité pas pour pouvoir surfer à côté, sinon le test ne serait pas assez fiable, moi dans tous tes premiers cpu stress je pouvais arréter facilement, juste 2 ou 3s de latence c'est tout. Donc pour moi soit tu montes la priorité ou mieux encore tu laisse le choix à l'utilisateur

Alors sur mon céléron 750:
 
Pareil les autres processus prennent le dessus et donc son % dessend à moins de 80% facilement et c'est ultra fluide.  
 
Screen bientôt, je laisse tourner un peu.

Bon ben tu avais raison, la détection de la fréquence marche sauf au tout début.  
 

 

Pour le HT transport sa me marque 980-1000 DW/s lorsque j'utilise Folding@home !!! c'est quoi les DW/s maxi d'un bus hypertransport à 1060MHz ?  

Fouge est-il de retour avec d'autre test à faire???

Je mettrai alors 2 niveaux de priorité : Normal (8) et Elevé (11) qui correcpondent aux version NN et HL de la v0.04
N'ayant qu'une seule machine, je trouve cela contraignant de ne rien pouvoir faire d'autre.
Dans tous les cas, quelque soit le niveau de priorité, le test ne sera valide qui si l'usage moyen du CPU dépasse 90% (voire 95%). Donc si une autre tâche fait trop baisser -> test non valide (comme OCCT)  

Dans tous les cas, il lancera 2 thread, meme si un core est déjà très occupé. Par contre le % d'utilisation risque d'etre faible, a moins que SETI ait un niveau faible de priorité.
T'as fait le test ? Screen ?
 
 
 

DW = DWORD = entier de 32bit, c'est tout ce que je sais.
 

De retour, mais j'attend surtout des screen révélant un problème au niveau du calcul du % d'utilisation. Version à utiliser :
http://olivier.fouge.free.fr/OCCT/ [...] _debug.zip

 
Ok Donc plus besoin de moi pour l'instant Bon aprés c'être regardé MI2, un peu de boulot now    
Pour la validité du test, s'il faut voir les erreurs, il me semble logique que ton thread soit prioritaire sur les autres sinon tu peux rater des erreurs non?

Tu as besoin d'un screen de ma part avec cette dernière version? J'en ai fait un où j'ai arrêté le test après 6 secondes (3 dépassements).