Reprise du message précédent :
Nickel, ça confirme que dans la beta 5 la détection est bonne

Normalement la fréquence est stable entre 20ppm et 50ppm : principe d'une fréquence pilotée par une PLL et un quartz.

Les différences sont surtout dues aux imprécisions de la mesure. Surtout quand 2 soft arrondissent au 1/10 près, il n'est pas étonnant de voir une différence de 0.1MHz

  Puis bon .1mhz kec on s'en fou

Fouge> Place ta routine de mesure de fréquence en ring0, tu vas avoir des surprises. La précision devient faramineuse, et sans forcer !

Le problème est que sur certains CPU (les C2D par ex) j'utilise une méthode alternative dont la mesure du temps n'est précis qu'à 1/1000. Donc ring0 ou non...
Pour la méthode "classique", je peux sortir une fréquence précis de +/- 0.001 mais ça m'interesse pas. Mais sur un C2D, il pourra se planter de plusieurs centaines de MHz si :
 - le FSB est modifié de manière logiciel sous Windows
 - le coef ne correspond pas au coef d'origine du CPU (ex un E6600 en 7*400).

Si tu connais une méthode fiable ET précise, je suis toute ouïe

Pour l'instant, j'ai passé ma méthode classique de mesure en RING0.
En seulement 1 essai, j'obtient la même précision qu'avec 10 essais.
 
Là je vais tenté une tout autre approche que j'avais tenté d'utiliser pour mesurer les décalages TSC entre les cores : Il s'agit de l'utilisation du canal 2 du 8254. En ring3, c'est inutilisable, mais en mode ring0, les appels i/o ne sont pas ralentis, c'est un gros avantage.
Mais pour éviter les problèmes d'erreurs de mesure, il faut s'assurer de la fréquence du 8254.
Historiquement, elle est fixée à 14,318MHz. Mais il faut en être certain, ou effectuer une mesure sur cette dernière.

christophe _d13> T'as déjà testé ta méthode de mesure de fréquence avec un C2D dans les 2 conditions que j'ai énnoncé dans mon post précédant ?
Hors hack, on est obligé de passer par un driver pour passer en ring0 ?

Oui et c'est très comique.
 
C'est pour cela que je change radicalement de méthode, elle n'est plus viable maintenant... Dommage... Après presque 10 ans de bons et loyaux services...
 

C'est le seul moyen d'accéder à une I/O sans latence. Sinon en Ring3 (en utilisant GiveIO par exemple), on a une latence trés importante (je crois que j'avais plus de 2000 cycles et que c'était pas stable pour les tests de synchro TSC).

Par contre pour de la simple mesure de fréquence c'est suffisant

Je ne sais pas encore. J'espère finir ce soir.

Je vais avoir besoin de vous. Si vous avez un OS autre que Windows XP 32bit (cad Win2k, WinXP64, Win2k3 32&64bit, Vista 32&64bit) alors j'aimerais que vous testiez ceci :
http://olivier.fouge.free.fr/CPUSt [...] ctSize.zip

Linux est toujours out je suppose pourtant c'est bien autre que ce que tu as cité

Teste sous Wine si ça t'amuse

Et mac au fait ?

Et wine ne deigne point t'accorder cette requête.

Vista 32 bits + e6320:
 

Fouge> Pour le test de la fréquence via MSR_E8, il me trouve bien 2550MHz alors que les autres tournent à 3825 et 3835 (cf nos MP).
 
Sous Windows XP x64>

Merci pour ces feedback

En fait, je viens découvrir (documents à l'appui) que le monitoring "Intel Core Temp" et "K8 Thermal Sensor" n'est compatible qu'avec :
Windows 2000 (toute version)
Windows XP 32bit (toute version)
Windows 2003 32bit (SP0 uniquement)

Pour les autres OS, ça ne marche pas. Il ne semble pas exister de "hack" pour lire/écrire les MSR en ring 3, ni pour passer en ring 0 (qui nécessite certaines opérations en ring 3 mais qui sont bloquées sur ces OS).

Bref, ce soir je valide la version 1.0.1 en version finale
Je verrai plus tard si je peux améliorer la compatiblité du monitoring intégré...

Fouge> C'est le problème de ZwDebug...

Jusqu'ici j'avais aucune info sur la compatibilité de ce "hack" (hormis le fait que ça marchait pas sous XP64 et Vista)... jusqu'à ce matin où j'ai trouvé tout ce qu'il me fallait.

Sortie de la version 1.0.1 finale
Liste des changements par rapport à la version 1.0.0 :
- passage de Code::Blocks à la build 3970
- amélioration de la mesure de la fréquence des CPU Intel
- modification et meilleur affichage des codes erreur de l'algo de test
- support du SSE4.1 (Intel Penryn), du SSE4.2 (Intel Nehalem) et SSE4a (AMD K10)
- ajout du monitoring "Intel Core Temp" (intégré à CSMT) : compatible avec les Intel Core 1&2
- ajout du monitoring "K8 Thermal Sensor" (intégré à CSMT) : compatible avec les AMD à archi K8
Rq: ces 2 nouveaux modules de monitoring ne sont compatible qu'avec Win2k, XP (32bit) et 2k3 (SP0 32bit)

Télécharger CPU Stress MT 1.0.1 : EXE RAR ZIP

Tests qu'il y a à faire :
- tester les 2 nouveaux modules de monitoring
- vérifier le fonctionnement général de cette version
- tester l'installation avec la version EXE

Rq : si vous avez installé la version 1.0.0 avec l'EXE, pensez à désinstaller avant d'installer la nouvelle version.
Cependant, à partir de la prochaine version, les upgrades se feront automatiquement sans désinstaller la version précédente.

Merci à tous

edit: ortho

Bon moi j'ai plus de pb de freeze tien. Par sécurité j'ai monté le vcore à 1.575v. Et 50° en full pc allumé depuis ce matin 9h et il fait plustôt chaud.
 
Donc au final je pense que le nétoyage à été bénéfique.

Plus la montée du VCore que le nettoyage je pense ...
 
Fouge => fonctionnement générale & précédente
 
Sinon l'EXE marche bien !
EDIT : la désinstallation z'aussi

Bah non, je l'ai juste remonté ce week end le vcore. ça faisait quelque temps que j'étais toujours à 1.55V
Je l'ai juste remonté vu que le log de fouge trouvait des erreur à 1.55V et pas à 1.575V donc par précaution
Mais depuis le netoyage c'est redevenu stable.

voila mon résultat :
 

 
 
suis content.
stable a 1.7v ça veut dire qu'il doit pouvoir passer les 2.4ghz avec un chouia + sans pour autant etre tres (trop) chaud!!

Bonsoir  
 
J'aurais besoin de quelqu'un avec Windows Vista (avec thème par défaut de Vista) pour faire quelques screenshot de CSMT 1.0.1
1) au 1er démarrage de CSMT, juste après l'install (prendre la version ZIP ou RAR, c'est plus simple) : faire un screenshot de la fenetre principale, ouvrir les fenetre Options et About, me dire s'il y a des défauts d'intégration dans le thème Vista, etc.
2) faire un screenshot de la fenetre principale avec chacun des 5 autres thèmes
3) me dire ce que ça fait quand, après avoir choisi un thème, vous revenez sur "Aucun"
 
Merci

1) Tu trouveras tout les screens sur mon FTP, je n'ai rien vu d'alarmant pour les fenêtres options et about, dans le doute je les ais screenées.
2) FTP.
3) On reviens au thème "par défaut", comme sur le premier screen.
 
 

Le thème par défaut (pas de thème en fait) correspond bien au thème que tu as sous Vista ?
Et tu me confirmes bien que lorsque tu passes d'un thème CSMT à Aucun (donc au thème par défaut de ton OS), tu y reviens bien. Tu ne reviens pas au thème Windows2000 ou celui d'XP?
 
Si c'est le cas, c'est cool. Je croyais qu'il y aurait un bug

Oui le thème par "défaut" est bien le thème "Vista", et oui lorsque je passe d'un thème a aucun je récupère le thème "Vista".

"Lancement de bug avorté"

Je voulais sortir une version 1.0.2 certifiée Vista car Qt 4.3.0 est sorti et apporte lui aussi cette certification. De plus j'avais flairé un bug au niveau de la gestion des thème (lorsqu'on repasse à "Aucun" sous Vista).
Mais rien de tout ça, donc pas de 1.0.2 pour l'instant...

Ca vous dirait une exportation des info de monitoring (T°/Vcore) dans un fichier texte ? Ca peut permettre des importation sous Excel par ex, et faire des stats ou des graphes.
Et intégrer une T° limite (arret du test lorsque celle-ci est dépassée) ?
Et un mini-bomberman en OpenGL ?

En fait je cherche quelques petites features pour sortir la 1.0.2

Température max pour stopper le test oui c'est primordial. tu pourrais même éteindre le pc automatiquementa vec un petit shutdown pour protéger le pc si la température ne baisse pas en idle aprés
 
Sinon pourquoi pas une option cornichon maillo plustôt que le mini bomberman.

Et un shutdown a la fin du test si on a donne une duree determinee aussi ...
Mais faut creer un rapport pour etre sur que c'est pas un plantage.

A la fermeture de CSMT, il créé un fichier Event.log qui reprend les infos présentes dans la zone en bas. Ainsi (sauf plantage grave) il est toujours possible de savoir ce qui s'est passé et pourquoi CSMT s'est arreté lors de la dernière session, même lorsque vous avez quitté CSMT ou coupé le PC.

Perso je veux le fichier texte. D'ailleurs je pensais justement le demander à tdi. Histoire de trouver facilement la température maxi ou le vcore moyen par exemple, surtout que ses graphes ont une échelle bizarroïde.

Pour l'export du monitoring au format TXT, t'as absolument besoin d'avoir l'heure exacte de la mesure ou une simple numérotation de 1 à n est suffisante ?
Théoriquement, il y a une valeur prise toutes les secondes. Cependant, surtout en priorité haute, il arrive qu'il y ait plusieurs secondes entre 2 mesures consécutives. De plus, avec SpeedFan et surtout MBM5, il arrive que la valeur relevée soit incorrecte -> le relevé est donc zappé.
Avec une simple numérotation, l'inconvénient est que si vous faite un graphe, l'axe des abscisses ne correspondrait pas tout à fait au temps (bien que globalement correct). Sinon, si c'est juste pour faire des stats et/ou faire un graphe sans forcément avoir un respect très stricte de la vitesse d'écoulement du temps, ça n'est absolument pas nécessaire.
Ensuite reste à voir si j'écris dans le fichier au fur et à mesure pendant le test (ce qui me plait à moitié) ou tout générer à la fin (ce qui peut prendre 2 ou 3s si le test a duré très longtemps)...

Nan mais je sais pas si tu te rends compte de 'les Nords mités' de ce que tu viens de dire !!! ²
2 ou 3 secondes vont nous faire mal tu penses ?
Sur des procos o/c 'fondlesballons si ça ne prend pas moins ou même 10 secondes, si on a un fichier texte au final ça reste exploitable pour toi ou n'importe qui pour ensuite créer de la BDD sans problème (pour qui aime les BDD...)
Alors la feature EST à implémenter selon moi mais ne t'en fais pas pour ça, ce serait tellement un + par rapport à la base de départ qu'est ton programme à l'heure actuelle que ça vaut carrément le coup d'être tenté !
Sinon +1, pas de graphes si les échelles devaient être biaisées

Non mais la feature, je VAIS l'implémenter. Je me demande juste comment je vais la faire : numérotation ou heure exacte, au fur et à mesure ou tout d'un coup à la fin ?
- numérotation : 2 fois - de mémoire, 2 fois + rapide, axe du temps dans un graphe pas strictement respecté (mais pas visible à l'oeil nu)
- heure exacte : 2 fois + de mémoire, 2 fois - rapide, axe du temps strictement respecté (pas visible à l'oeil nu, mais peu éventuellement être utile dans certains calcul prenant en compte le temps)
- au fur et à mesure : écriture pendant le test ce qui peut le perturber un peu (moins intensif), mais pas de grosse écriture continue et possibilité d'une récupération partielle des infos lors d'un plantage du PC avant la fin du test.
- tout à la fin : test non perturbé, mais écriture qui peut être un peu longue (tout est relatif) et aucune info dispo en cas de plantage du PC avant la fin du test.
 
Rien à voir avec l'exportation, mais en plus du min/max, je vais sans doute ajouter l'affichage de la moyenne de la T°CPU et de celle du Vcore.

Dans les 2 cas (mesure de temps ou pointeur), tu n'auras pas de mesures fiables
Tu peux faire une BDD même sans avoir besoin de lier les "temps<=>mesures" aussi
Tout dépend quels sont les choix retenus et la façon d'afficher les résultats en graphique...
 
Pis tu vas bien nous trouver une 'pirouette' de programmation pour maîtriser ce décalage dans le temps
 
A mon avis il faut partir sur un compteur de l'équivalent d'une seconde (pas de compteur basé sur le temps réel quoi...), avec une mesure dans la foulée tous ces 'équivalents-secondes', quitte à interrompre ton calcul/burn à chaque fin de cycle (équivalent/seconde), pas trop gênant car régulier (prévisible) et non lié au temps qui passe VRAIMENT !??
Ça fait forcément perdre à chaque fois du temps de calcul/burn mais ce n'est pas grave :
- ni pour le test en lui-même (machines o/c, multi-tâches/thread toussa), le burn n'en sera pas trop entâché,
- ni pour l'extraction des mesures car, c'est sûr que ce ne sera pas 'propre' à notre temps à nous mais avec du calcul derrière tu dois pouvoir rapporter l'échelle (fixe et donc connue) à notre temps à nous, en te basant sur un indice de performances que tu lancerais au départ du calcul/burn  
 
   
 
EDIT : à terme et à l'extrême si tu l'intégrais au test CSMT, tu pourrais en faire une partie du burn...
Ensuite l'exportation, l'affichage, fichier texte ou carrément un site 'touletralala', ça te regarde pourvu que tu nous tiennes au courant de l'évolution mais je ne m'en fait pas pour ça, n'abandonnes pas les features nouvelles, il peut y en avoir d'autres si tu 'galères' sur celle-ci !!!
 
PS : les moyennes je n'ai jamais été pour

 
Pas besoin du temps exact. Par contre vaudrait pas mieux écrire genre toutes les 5 minutes ? Car si le PC plante...

+1