Reprise du message précédent :
+1 pr le test precis  
 

 
ouai, bug connu et corrigé de la v0.514 . il faisait partie de la génération des graphes. Donc si graphes pas générés, appli qui quitte sans soucaille.
 
Ca devrait plus le faire dans la prochaine version.
 
Allez, je vais voir ske chpeux fer.
 
par contre, pour le bug des graphes zarbi, je vais faire de mon mieux mais g du mal a le localiser

 
Le bi CPU, je l'ai mis en attente, car c'est pas "ma" priorité du moment, et faut que je résolve ce probleme

j'imagine bien, c'est pas pour rien que je dépose pas de feedback concernant ca

 
Merci ^^
 
Par contre, je te promets de me pencher sur le souci des que possible à

Vous la voulez ce soir cette version ++ ?
 
Faudra un feedback cependant
 
Car meme si ca se voit pas, beaucoup de choses derrière auront changé, donc bugs potentiels

mieux vaut 1 ou 2 j de plus mais - de bug    
c'est tj vrai en info  

 
Le blem c'est que svt mon PC n'a pas ces bugs la.
 
J'ai jamais eu de blem a fermer l'appli par exemple.
 
Donc bon, c assez aléatoire

si tu veux je peux tester

fait paitai la release

lolo92 ne trouve plus de bug dans la fermeture de l'appli.
 
Vous allez rire : je vais etre en grande discussion avec monsieur MBM.
 
Y a un gros souci : en mode assez hard ( above normal), occt ralentit tellement MBM que j'ai plus qu'une update toutes les 5/6 secondes...
 

 
Donc ce sera du normal dans un premier temps, la, ca dépend pas de moi

question con, avec les CPU HT, il utilise 50 ou 100% des capacités CPU?
 
Je demande parce que j'ai noté que CPUBurn seul ou Prime95 seul ne prennent que 50% du CPU
 
Perso, mon stress test qui tue, c'est prime + cpu burn en simultané  
 
Certains overclockings stables avec CPUBurn seul ou prime seul ne l'étaient plus avec les deux en même temps.

 
Tu diminues leur efficacité en lancant les deux en meme temps...
 
Je vais pas refaire mon laius sur le HT Le HT invente rien, pas de resources. Il prends ce qui est pas utilisé. moi j'ai jamais de bulles dans mon prog, donc jamais de ressources utilisées.
 
Le 50% vient du fait que Win XP considère le HT comme un processeur a part entière, ce qui est une grosse hérésie.

ca ne répond pas à ma constatation... Des o/c stables avec cpu burn seul ou prime seul ne le sont plus avec les deux...
 
Et autre constatation : ça chauffe un peu plus quand tu lances les deux en simultanés que un seul.

 
Eh ben :
1- Des O/C non stables avec les deux le sont avec un seul aussi  ( eh oui )
2- ca chauffe un peu plus certes. mais ca ne veut pas dire que les tests sont + efficaces.
 
Une chose est sure : pour qu'un test de stabilité soit efficace, il faut que le cache, une grosse partie du CPU, soit mis a contribution.
 
Or, le fait d'avoir deux process dans le CPU en meme temps va augmenter les cache miss... ce qui va donner une baisse des performances en single thread, d'ou probleme pour la détection des erreurs.
 
Bref.

Je retarde la build a demain soir pour diverses raisons
 
Désolé

moi je fais des tests de chauffe pas de perfs en général... Donc plus ça chauffe pour moi, mieux c'est    
 
N'empêche que lors de ces tests en overclocking, ca permet de voir rapidement ce qui est stable et ce qui ne l'est pas.

 
Pas tellement, généralement, ca te dit qui tient mieux la temperature... et est moins précis pour les erreurs de signal. Tout dépend de ce a quoi tu t'attache.

dans l'affichage des graphs à la fin, il affiche ma fréquence de boot et non ma fréquence réelle (j'utilise clockgen pour o/c)  

tite question déjà posée: (50 pages ca dissuade)
 
quesque qui détermine si le cpu fait une erreur? il m'a sorti ca pour mon tbird alors que du burn/jeux/app gourmandes je n'ai pas de crash ni rien (et ca fait 2 mois que je suis dans cette config d'oc )

 
A mon avis , il y a des algorithme de calcul, secondé d''un algorithme de verification des resultats. Si OCCT s'arrete, alors ton cpu s'est gourré klks part.
 

+1 pour le test sauvage    
 
pour info je pense que c le chipset de la mobo qui déconne a 200 de fsb  

Dis donc, tu as posté ça dans mon dos ou quoi.

 
Je calcule la fréquence en temps réel, je la récupère nulle part en fait ( RDTSC timers).
 
Donc a priori, si je dis ca, c'est que c'est vrai a +/- 2%

 à tous
 
tetedeiench, j'viens de mettre un peu le boxon dans le prog (déjà eu le tour une fois mais je pensais que c'etait pas important)
 
- 1ère fois c'était suite à un freeze du pc en torture et là un reboot(trop OC    )
 
Voilà les méssages que je n'avais pas noter l'autre fois:
 
-Demarage OCCT :  cannot create file C:\program files\OCCT\~tmp001.tmp , là je ferme cette fenêtre ,le prog ne se charge pas mais la fenêtre OCCT s'ouvre avec tous les compteurs à zéro (ce qui je pense est normal vu le méssage d'avant)
 
-Pour quitter le prog exit et là ce message:
 
acces violation at address 004E4F6C in module OCCT.exe read of address 00000014.
 
OCCT reste dans le processus et on ne peut le "killer" qu'avec terminer le processus.
 
Donc obligation d'une reinstall.(un peu chi... pour ceux qui auront des plantages)
 
Désolé pour le roman.

 
Merci pour le feedback
 
Pour la petite histoire, le bug que tu cites a été détecté et corrigé entretemps ( désolé), donc ca ne devrait plus jamais arriver.
 

j'ai exactement les memes erreurs, mais en killant le processus et en relançant occt ça marche.
 
pour la fréquence ça m'étonne qu'à moitié : les modifs créées par clockgen ne sont détectées que par la derniere version de cpu-z (la 1.19) et les autres softs ne la détectent pas, pourtant l'o/C a bien lieu (instabilité si fsb réglé trop haut, augmentation significative des perfs 2.4 --> 3.6), je sais pas trop comment cpu-z identifie la fréquence, mais toujours est-il qu'il est le seul, peut etre qu'en demandant à l'auteur on pourrait savoir comment s'y prendre

Bon aller tetedeiench on l'a ce soir la 0.52
Retourne a travailler sur occt toute suite en tout cas  

 
Je vois mal un soft qui change la frequence du CPU en ignorant les RDTSC timers !

Bon ca approche, ca va venir

je n'ai absolument aucune connaissance en programmation (flash excepté), donc je comprends pas tout, mais si tu veux, essaye clockgen, ou demande à cpull, on a le meme probleme de reconnaissance de la fréquence en utilisant clockgen (seul dispo pour les P4C800/IC7), l'augmentation est réelle, on la voit bien aux perfs, mais elle n'est pas vue par les différents logiciels

Ma methode a moi :
 
-Je prends un chronomètre ultra haute definition
-Je le lance et j'attends exactement 1000 ticks d'horloge CPU ( 1000 tours de piste pour un coureur quoi).
 
Si je sais combien de temps il a mis pour faire 1000 tours, je peux calculer sa vitesse.
 
Et vala, basiquement, comment je fais
 
Donc impossible de se tromper sur la frequence
( Or erreur de chrono qui est tjs possible... y a un petit itnervalle a considérer)

effectivement, ça semble implacable comme mesure, je comprends pas pourquoi les logiciels dont le tien (qui je suppose utilisent tous cette méthode) ne parviennent pas a detecter le changement de frequence, alors que Cpu-Z 1.19 le voit    
est-ce possible de ne pas compter le bon nombre de cycles d'horloge ? tu comptabilise ça comment ?

 
Euh, l'algorithme vient du site de monsieur intel
 
http://www.intel.com/design/Xeon/applnots/24161823.pdf pour ceux que cela intéresse.
 

ya un bug sur la derniere version,
a 5% ça me dit pas stable !! il ch le del ton log  

 
+1  mais en insistant je monte  à 8%-10%

super la puissance du pross qui s'inscrit sur les graphes    
 
pile ma frequence 2181  

bon dernier petit bug puis release