Reprise du message précédent :

tiens à ce sujet ,j'arrive en aout 2021 , et je vois un passage tres interessant sur le CO et les outils pour le tracer....
 
https://forum.hardware.fr/hfr/Overc [...] m#t2563879
 
c'est un échange entre toi et Oufouf84 ,  où tu lui demandes de refaire son test OCCT + Logviewer selon des indications précises pour OCCT ( physical only)
 
Oufouf84 a fait 2 tests , l'un avec Affinity sur le core testé , l'autre sans ; honnetement ça change pas grand chose sur la plage de variabilité ( max/min) , c'est normal qu'elle soit légerement différente entre 2 tests.
 
Donc prenons le graph le plus interessant à lire , celui qui pointe bien toutes les différences entre pas de CO et le CO -30  
 
Sur le principe c'est 150mV de 'fenetre de variabilité"  , ( au plus si 30*5mV  sinon 90mV si 30*3) ,je préfere ce terme plutot que "150mV en moins" car c'est pas le cas , c'est ce que nous montre entre autre ce screen .
 
 
le plus facile à exploiter , dans les chiffres,  c'est déjà en premier  la valeur moyenne ici : 1.434 sans CO, et 1.385 avec le CO -30 , ça fait 49mV en moins en moyenne .
 
Si on prend les valeurs respectives les plus basses ça fait  1.4 moins 1.331 , ça fait 69mV de différence
 
à l'inverse sur la valeur max ça donne 1.485 moins 1.438 , ça fait 47mV  (soit tres proche de la valeur moyenne au passage )
 
 
Bref , en premier, on n'observe PAS une baisse de 150mV sur ce CO -30 , premier enseignement
 
 
ON observe que le coeur opere désormais 49mV en dessous en moyenne  et que sur cette moyenne ça peut descendre encore de 54mV (1.385 moins 1.331 )  
 
En fait par rapport à la courbe sans CO on observe une plus grande variabilité possible   ( 75mV max d'amplitude sans CO , contre  107mV avec le CO -30 ), tout en operant plus bas en tension.
 
 
à observer la courbe avec CO,  ce qui me frappe c'est meme que ça ferait presque penser à un "LLC à l'envers" !    
   
coté conso ça fait 8% de moins , soit 2.99W  
 
 
je serais presque tenté de dire que derriere tous ces graph "serieux et impressionnants" on apprend quoi ? que le coeur sous CO -30 fonctionne ici 'normalement' avec 1.331 au plus bas...et c'est pas une grande surprise qu'il en soit ainsi !    
 
enfin si  c'est un peu une surprise, car de prime abord on pourrait penser que CO -30 mettrait le coeur dans une situation beaucoup plus difficile ... or 1.331 au plus bas c'est encore un velours , c'est meme presque haut en fait  
 
 
mais oui, ces graphs ont l'interet ojectif de détailler et montrer  pourquoi le CO -30 fonctionne ici ;  que ça descend finalement pas bien bas en tension malgré un CO à -30
 
je donne acte toutefois qu'il s'agit ici d'un test assez court qui peut donc se gater sur la durée, okay  
 
enfin méthode et travail tout à fait respectables , mais peut etre overkill quant au résultat démontré , et c'est pas de l'ironie  , juste une reflexion ....
 
 
https://i.ibb.co/0jr9hkt/C3-CO.png

C'est juste que les résultats à base de capture d'écran de HWiNFO, c'est peu utile voir trompeur. Par exemple (et je sais que ce n'est pas un message de toi) :

En fait, sur les captures, on ne voit rien. De quel effective-clock parle-t-on ici ?
 
Si tu log les valeurs toutes les 1s voire même 500ms, tu peux observer l'effective-clock sur la durée du bench et en faire une moyenne précise, l'outil permettant de "zoomer" et donc d'exclure le début du test ou la fin. Ca permet aussi de comparer précisément l'impact d'un réglage en superposant les courbes de deux benchs successifs, ce qui est pratiquement impossible avec une bête capture d'écran ou on ne voit que min, max et moyenne sur une période mal définie qui peut inclure le chargement des données et non pas du calcul (par exemple).
 
Les résultats au doigt mouillé, ça fonctionne quand on travaille à la truelle. On a le droit de considérer que c'est overkill, mais on retombe sur une opinion. Sur ce forum, beaucoup de gens passent un temps fou à faire des tests à l'arrache et les résultats ont en général peu de valeur. Moi j'appelle ça perdre son temps, mais d'un autre côté, ça occupe  

Effective clock max.
Après j'ai toujours dit que justement ces valeurs importaient peu, et c'était le sens de ce message justement, le plus important étant le score.

Clairement, Cinebench est un benchmark. Si l'objectif est de savoir si on est plus performant sur ce benchmark, le score est la seule mesure à considérer.
 
Mais ce n'est pas forcément que l'effective-clock a peu d'importance, c'est surtout le fait de le regarder au travers d'un max qui n'est pas pertinent. Je pense que le score et l'effective-clock sont très bien corrélés, mais je n'ai jamais testé le clock-stretching pour confirmer ça.

-5 / -20 / -30 sur les autres
 

 
c'était bien le core 1 qui foutait la merde

On est d'accord, je pense que la valeur pertinente serait la moyenne de effective clock pendant la durée du test, ni la valeur max, ni la valeur sur la fin que kobaia pense à tort être pertinent, ni les effective clock avant/après le run.

Mais donc le second aussi ne tient pas -30.

L'intuition de kobaia n'est pas incorrecte, c'est juste imprécis.
 
Voilà par exemple ce que donnent les effective-clock chez moi sur CBr20 (deuxième run).

 
Je n'irai pas jusqu'à dire que c'est très intéressant, mais bon  

tu as tort mais c'est pas grave
 
tout comme cette autre affirmation " que un run de 10mn produira toujours une valeur score plus basse que un run solo" .  je t'ai démontré par deux fois déjà que tu te trompais là aussi ,  et c'est pas grave non plus  

j'ai pas testé encore (avec -5 et -30)

 
Hwinfo n'est  peut etre pas précis au millieme près ( ne serait ce que du fait de son polling rate ) mais l'imprécision de la colonne Effective "réel" doit etre peanuts sur un test comme CB23  ;  bien sur il ya les 'petites' interruptions systeme trop rapides pour etre prises perçues , mais ça compte pour peanuts.
 
les grosses interruptions , on le voit tout de suite sur le score !   et un score doit etre grosso merdo répétitif à l'erreur de précision près de CB ; quellle est-elle ? demi ou quart de % , c'est la surprise habituelle du score final par rapport à ce que l'on attend au vu justement des Effective , en cours, en colonne  temps "réel"  
 
mais bon, va pour "imprécis"  lorsque c'est si peu signifiant , ça me dérange pas
 
edit : au passage j'observe que ton screen montre bien les toutes dernieres fluctuations finales des Effective  , dans le dernier tiers,  qui sont de l'ordre de qq Mhz , 2 ou 3 ici,  exactement ce que j'observe moi aussi  avec HWinfo lors du run !
 
Bref si "l'imprécision" ici est de 1Mhz (?) par rapport à 4650 ,ça va hein , non ?

J'utilise HWiNFO aussi, donc le problème n'est pas là. Encore une fois, tant qu'on teste à la truelle, il n'y a aucun problème à mesurer à la louche.

Ici la variation en fréquence entre le début et la fin du run, c'est ~15MHz.
15MHz, c'est que dalle, c'est 0.3%. Sauf qu'en fait sur un score CBr20, ça peut faire 6100 ou 6120.
Chacun décidera de si cette variation est significative ou non.

Inspiré par Solstic3, j'ai fait un run CBR23 de 10 minutes en loggant les métriques HWiNFO64, ça donne des infos sur toutes la longueur du run et permet donc de mieux comprendre ce qui se passe.
 
 
 
Avec GenericLogViewer on peut visualiser les logs sous forme de graphiques.
Lien direct Download - GenericLogViewer - Version 6.4
 
 
Je suis surpris du résultat, il s'avère que le système est plus chaud en début de run que sur la fin, je suppose que ça signifie que mon système de ventilation est efficace. De même, les fréquences sont plus élevées sur les dernières passes que sur les premières.
 
Voici le average effective clock (moyenne des 8 cœurs), ça ne saute pas aux yeux mais les fréquences sont plus élevées sur les dernières passes que sur les premières

 
Et de la même manière, les températures CPU baissent:

 
Et le ventilo CPU en fait logiquement de même:

 
Mais le mieux est encore de charger le fichier dans logViewer: les fréquences sont plus élevées sur les dernières passes que sur les premières
 
 
 

Ah c'est intéressant en effet  
 
Pour la température, je conseillerai plutôt la sonde CPU CCD1 (Tdie) ou CPU Die (average).
CPU (Tctl/Tdie) intègre un amortissement qui fausse très légèrement la mesure, mais c'est du détail  

Fiat Lux !  tout arrive à qui sait entendre , heu pardon attendre,   j'en suis heureux      

 
nan mais bien sur que les Effective vont varier de plus que 2 ou 3 Mhz ...et donc ici oui tu as 15Mhz sur 40 sec.
 
l'argument est une pirouette rhétorique ?   , je te faisais juste remarquer que sur les 15 dernieres secondes ,  en gros 1/3 du test, ça ne bougeait que de l'ordre de 2 ou 3 Mhz.
 
Exactement ce que j'observe moi meme avec HWinfo , le plus souvent,  lors d'un run de 60sec en gros ,  sur les trois dernieres rangées de rectangles à calculer
 
Bref que si erreur de fin de run il y a , comme tu l'évoques elle sera ridiculement petite  , 1Mhz ? et je t'accorde volontiers , tout comme 2Mhz peuvent representer 10 ou 20 points, exact.
 
Tu évoquais une seconde possibilité d'erreur qui serait celle en tout début de test ; là encore le polling rate de HWinfo "peut" occasionner un delta , oui tres possible mais  si tu peux le prouver ce serait meux bien sur.
 
et de quel ordre ? tu n'en as aucune idée et donc tu ne peux toi meme le déterminer que "à la louche"    , je t'en donne acte aussi ( heu de l'instrument utilisé) .
 
Pour la 'truelle' ce serait disons de passer à  coté que un "épouvantable" CO -30 , voué à la catastrophe bien sur,  a produit quand meme , au plus bas, 1.331V . Disons que là de bonnes lunettes seraient plus appropriées qu'une truelle pour bien lire des logs.    
 
la morale (que tu n'aimes pas je crois   )  serait que un bon outillage ne sert que si il fait mieux qu'un moins bon ,  ou plutot supposé tel ici, puisque à aucun moment tu n'es en mesure d'en apporter la preuve , mais vu le niveau d'erreur  supposé ou plutot opposé,  c'est plutot de l'ordre de la cuillere de dinette enfantine , bref aucun besoin d'approfondir , accordé aussi  !    
 
Du reste je ne t'apprendrais probablement rien en rappelant que Erathostene avait calculé la circonférence terrestre avec ...un baton , il y a plus de 2000 ans , avec une erreur de l'ordre de 1%.  on n'ose imaginer les prouesses qu'il aurait réalisées avec une louche et une truelle    

 
pour revenir au fil, tu noteras quand meme que toutes tes fréquences sont rapportées identiques (max,moyenne,mini) alors meme que  
on observe  que , par ex entre 20 et 25sec, les 3 premiers coeurs n'ont pas exactement les memes fréquences (affichées) que les 3 derniers par ex ; bref que ça arrondit ici aussi   , du coup c'est de la louche ou de la truelle ?    

Non non, mais tu te trompes de cible, je n'ai rien dis concernant le polling ou une affaire de 1.331V.
 
Je rappelle juste que HWiNFO permet de sauvegarder des logs et qu'il existe un outil qui permet de les exploiter. C'est en tout point supérieur à un coup d'oeil rapide "au bon moment" pour choper l'info. De plus, ça permet d'observer la dynamique, à tête reposée et de comparer avec des logs précédents. Bref, un truc en tout point supérieur.
 
Mais je ne suis pas en train d'essayer de t'imposer de l'utiliser.

Ne le prend pas mal, je ne dis pas non plus que tu testes à la truelle. Quand je dégrossis un overclock, j'ai pas besoin de 10min de logs avec un polling à 250ms.
 
Quand tu commences à comparer un CO de -20 avec un CO de -30 en revanche... Quel impact sur la fréquence effective, quel impact sur le VID, etc. On cherche à mesurer des pouillèmes, et là, à la louche ça devient compliqué (comprendre imprécis).
 
C'est un peu pareil entre MT et ST. Moi je n'ai jamais planté sur des tests MT. Du coup, je teste 16T, 8T, 6T, 4T, 2T et 1T. Mais c'est mon choix. Ne tester la stabilité que du 16T par exemple, je considère que c'est un test à la truelle  

Le plus important avec les fréquences effectives c'est qu'elles soient proches de celles demandées.
Si vous avez une fréquence de 4 600Mhz mais qu'en effective vous ne sortez que 4 400Mhz alors vous avez un certainement un soucis de performance.
 
Il est fort à parier que votre CO est bien trop agressif.
 
-30 en CO ne veut pas toujours dire que vous aurez les meilleures performances malheureusement.
Evidemment, tous les CPU ne seront pas identiques à la loterie mais vous seriez certainement très surpris de la différence en performances même avec un CO moins agressif...

C'est une citation d'un membre HFR, elle n'est pas de moi  

bah, il fallait juste lui offrir Friedrich pour les Nuls    
 
pour les CO je n'ai rien contre l'application d'une "méthode" x ou y , non bien sur,  sauf que comme rien n'est vraiment théorisé à l'appui  (à ma connaissance)   , c'est alors tout aussi empirique finalement non ?  

J'ai oublié de joindre le fichier à mon message précédent https://1fichier.com/?bbhgsxpyitvndjfx60xb

 
sans vouloir passer une éternité sur LogViewer ( que j'ai moi aussi un peu utilisé par le passé) , je ne vois pas trop ce que ça apporte -de plus- sur la connaissances des Effective lors d'un run CB23 .
 
les valeurs Max ( début en principe !) , Mini ( fin en principe) et donc Moyenne sont calculées par HWinfo et figurent pareillement donc dans les stats LogViewer.
 
 
Bref LogViewer ne fait que tracer des courbes , certes alors utiles si tu veux les revoir dans leurs détails de déroulement , au cas où qqchose t'aurais échappé lors de l'observation 'en temps réel' .  
 
 
Et , par ex, dans ton extrait de 45sec on visualise bien graphiquement ce qui peut se passer dans le continuum des variations , mais  qqun qui suit en temps réel ces valeurs le voit tout aussi bien ! sauf qu'il n'en consevera pas de trace.
 
je dirais que , ici, pour qqun qui a déjà surveillé visuellement moult fois un run (qui est quand meme assez court ) , et dont il connait un peu par avance la noermalité -ou pas- de deroulement, c'est surtout *ça* qu'il surveille ...est ce déjà conforme à ce que j'attends , ou est ce mieux-moins bien ? et c'est facile à suivre.  Voilà rien de plus à en dire
 
 
Apres pour des choses plus fines, plus complexes à suivre, comme l'évolution de pics de tension (par ex) , là oui LogViewer présente un réel interet , ne serait ce que comparer, superposer divers tests, etc... des évenements rapides et fugaces
 
Dans le cas de 50sec de CB, c'est nettement moins évident car en gros on s'interesse simplement à deux valeurs , la premiere MaX et la derniere Réel= mini !     "mini" car à ce jour ça ressemble à 'la fleche du temps' , enfin son concept,  un seul sens de lecture  (jamais vu plus en fin qu'au début )
 
en détail des arguments  avancés =>  
 
>>En fait, sur les captures, on ne voit rien. De quel effective-clock parle-t-on ici ?
 
la réponse est au dessus ; les deux valeurs qui comptent Max et Mini ; l'interet que tu sembles porter aux fluctuations n'a -en fait- aucun interet, pusique c'est lié aux diverses phases du rendu , dont tu dois etre bien en peine d'en percevoir la complexité réelle du momentum x ou y de rendu ! Maxon surement , mais pas nous    
 
>>Si tu log les valeurs toutes les 1s voire même 500ms, tu peux observer l'effective-clock sur la durée du bench et en faire une moyenne précise
 
"faire une moyenne précise" , ha bon 'faire ' et comment  ? et surtout pourquoi voudrais tu refaire ce qui a déjà été fait !  les chiffres stats dont tu disposes dans LogViewer sont les chiffes qui te sont fournis par HWinfo  
 
>>comparer précisément l'impact d'un réglage en superposant les courbes de deux benchs successifs
 
ça c'est exact, mais récusé pour CB23/ fr Effective , car de tres peu d'interet ;  par contre oui grand interet potentiel pour d'autres types de mesures  

test -25 sur le 2° core, ça passe pas
test -23, non plus
je reteste -20....ça passe plus
-18 non plus
je repasse à -15......que je dois retester

Sur sa capture :

• min = 0.1MHz
• max = 4800MHz
• moyenne = 2000MHz ? 3000MHz ?

Ces valeurs n'ont aucun intérêt. Mais en effet, on peut rester devant son écran a scruter une vingtaine de sondes en permanence    
 

 
LogViewer calcule un min, un max et une moyenne sur la période sélectionné. C'est ce qui est rapporté en haut à gauche de chaque graph.
 
Personne ne t'oblige à l'utiliser, mais ça reste supérieur en tout point à surveiller en temps réel.

Les joies des tests de CO    
 
Courage  

 
Ah un moment, tu fais autre chose que des tests???
 

je te rassure, je fais autre chose oui  

 
ooops, deux de chute  , désolé    
 
1) caricaturer ce que je dis sur la maniere de montrer les Effective Max, Réel, moyenne  c'est se montrer à court d'arguments   ;  il y a argumenter et argutier      là  t'es dans le seconde catégorie (momentanément j'ose croire) ; n'importe qui peut consulter les pages précédentes à ce sujet  
 
2) nope , Generic Log Viewer ne fait que de "l'illustration" des Logs data de divers softs, dont Hwinfo , GPU-Z , ... ;  il le fait tres bien toutefois ça d'accord ; mais il il ne "calcule" rien lui meme , et pourquoi ferait-il cela du reste vu qu'il dispose des calculs dans les logs !
 
 
 
 

Je pense que tu te trompes, GLV calcule bel et bien le min/max/avg sur la période sélectionnée, comme Solstic3 l'a dit.

si c'est averé , ça me surprend  , mais bon si c'est un fait (?) , il s'impose alors  ; j'espere alors qu'ils sont d'accord dans les ...memes calculs  

bordel.
15 tient plus non plus sur le core 2 (plantage au bout de 2 cycles d'ycruncher)
mais merde.
ça tenait 20 la semaine dernière.
c'est quoi s'bordel encore. chier !
je vais tester 10 du coup....pfff

Ah   .

Ah mon avis tu vas pouvoir reprendre tes timings ram, ça doit venir de là

 
hé non , au final  
 
Parceque à vous lire, Generic LOgViewer n'utilise pas les data des logs HWinfo mais opere de son coté en relisant les sondes de HWinfo ...mouai , élements de preuve ? doc par ex , ya RIEN chez le developpeur lui meme !  
 
il y aurait donc, je suppose alors, des relgages propres à LOgViewer sur le(s) temps de scan/polling ? ils sont où ?  et où choisit-on les sondes qui doivent etre lues ? entre autres questions ...
 
c'est quand meme bizarre que une demi douzaine de grands softs de tests (dont notre inter-national OOCT)  utilisent le  HWiNFO Engine (SDK) sauf  donc LOgViewer !
 
De plus si l'on se rend sur la page du developpeur  (TomWoB) de Generic LOgViewer dans le forum de HWinfo
 
https://www.hwinfo.com/forum/thread [...] lable.802/
 
il est nulle part question de recalculs autonomes : au contraire il présente bien son soft comme un add-on plutot simple et immédiat sur ses buts :
 
 I decided to implement a simple tool which shows diagrams of log files after "a few clicks":
 
   it allows to illustrate HWINFO log data in several diagrams and
    to compare multiple log-files side-by-side in one diagram !
 
 
Alors peut-etre veux tu dire que les data en provenance de HWinfo sont "adaptés" aux contingences d'une présentation en axes X/Y , ça c'est une possibilité oui, de là à parler de calculs autonomes, à toi de le prouver  
 
la liste  des 'new features' ajoutés au fil du temps, est purement liée à une "présentation/illustration" toujours plus sophistiquée , sur les logs data de HWinfo
 
la liste mentionne bien éffectivement les éfforts faits pour offir des modes de présentation  ,alternatifs disons , aux valeurs Max,moyenne,mini par exemple , mais rien de plus que de l'ordre de la présentation
 
la balle est dans votre camp    

Comment arrives-tu à cette conclusion ?
Comment pourrait-il faire autrement que lire les données contenues dans le fichier log ? (Données elles-mêmes issues des sondes).

Il y a un menu déroulant en haut à droite pour choisir quelles valeurs on veut afficher.

Il s'agit d'un simple calcul de moyenne et de l'affichage de la valeur min/max, évidemment qu'il utilise les relevés de chaque sonde...mais justement, un fichier journal ne fait pas de calculs lui, et se contente d’enregistrer les valeurs à fréquence régulière...pourquoi ne pas lancer le programme tout simplement ? ou ouvrir le fichier csv avec un éditeur de texte, pour mieux saisir ce qu'est un fichier log ?

Au cas où ça ne serait pas clair, on te parle des 3 valeurs affichées en haut à gauche, par exemple sur core effectice clock average que j'ai posté plus haut:

OK, c'est très simple, tu vois la moyenne calculée de 4516 au-dessus ?

Et bien cette valeur n'est pas présente dans le fichier csv:

bon......10 tient plus non plus (plantage au bout de 2 cycles).
j'ai testé 5, et ça tient pas non plus (plantage au bout de 5 cycles).
j'ai réduit l'override à +125 au lieu de +150 et je repars sur 5/20/30 sur les autres.....
ça me troue le q ce truc que ça puisse passer un jour et plus le lendemain.
 
 
 

Ça laisse quand-même penser que quelque-chose a changé sur ton système.
Juste pour être sûr, je testerais avec la RAM @stock comme on te l'a conseillé, juste histoire de voir si ça ne viendrait pas de là.

 
Il me semble que j'avais conseillé faire le contraire dés le début: ram stock, recherche du curve optimisé, puis passage aux timings de la ram, pas de redface ce coup-ci  

j'ai rien changé du tout, c'est ça l'truc.
au départ, je testais même pas avec ycruncher vu que j'avais pas compris.
j'ai validé des trucs sans tester en fait.
et quand j'ai commencé à utilisé ycruncher, je validais au bout de 5 cycles.
c'est tout simplement pas assez.
Hanako m'a bien dit de baisser l'override si j'arrivais pas.
bon, beh je vais d'abord faire ça et laisser plus que 5 cycles......disons 10

Je suis assez d'accord avec Bordel: tu t'y es pris à l'envers depuis le début