Reprise du message précédent :
Je suis assez d'accord avec Bordel: tu t'y es pris à l'envers depuis le début  

en fait, j'ai beau tourner le truc dans tous les sens, ça revient au même.
 
si tu commence par le proco, tu va ensuite adapter ta ram aux réglages de ton proco.
 
si tu commence par la ram, tu va ensuite adapter ton proco à ta ram.
 
au final, ça revient au même, sauf que t'aura pas les mêmes réglages ram et proco.
 
dans le 1° cas, t'aura optimisé ton proco mais pas ta ram, dans le second, c'est l'inverse.
 
moi je pense que mon problème vient de l'override trop élevé, tout simplement

Remettre temporairement la RAM @ stock permet de s'assurer que ce n'est pas elle qui serait la source du problème, ça prend un reboot et au moins tu as éliminé une piste.
 
Mais au delà de ça, c'est par le CO que tu aurais dû commencer en fait, puisque c'est là que se trouvent les risques d'instabilité (la preuve s'il en est). Régler le PBO avant n'avait pas grand intérêt de mon point de vue.

je suis têtu comme une mule, mais je vais d'abord voir ce qu'il se passe en baissant l'override

Ce qui est bizarre c'est que l'override ne devrait pas modifier la stabilité en charge lourdes, ou alors la fréquence max est supérieure à 4650 en charge lourdes ?

ah beh en charge lourde, sous ycruncher donc, la fréquence max effective monte au delà de 4650 oui

ça monte jusqu'à 4750-4800

 
 
j'ai pas trop le temps de faire des manips avec LogViewer pour comparer entre ce que qu'affiche HWinfo (Max de début, Réel de fin, et moyenne calculée)  et les valeurs affichées par LOgViewer sur la meme séquence  ( peut etre semaine prochaine si je suis encore dans les affres du choix TDC final 95A versus 115A ! mais je sais pas en quoi Logviewer m'aiderait là dessus ...)
 
mais le plus simple serait de poser directement la question au developpeur !  en attendant cela  , comme re-calcul autonome sur data logs ne figure nulle part dans la description du soft,  alors affaire encore en cours en l'état
 
De plus le choix d'une fréquence moyenne est le moins informatif qui soit , il suffit d'une  interruption un peu forte pour produire une valeur globale moyenne "faussée" ,  qui ne correspondra en rien à la moyenne -hors incident- durant la majorité de la  séquence ! certes c'est le principe d'une moyenne    , mais quand ça informe en rien serieusement , ça sert donc ..à rien  
 
Pour rester sur les Effective dans CB, c'est dommage que Solstic3 ait choisi CB20 ( que je n'utilise plus ) pour sortir les courbes fréquences effective  un peu plus haut dans le fil .
 
car d'emblée on observe un comportement "yoyo" tres atypique quand meme , ça reprend presque 10Mhz vers 11sec par ex ; ça c'est quasiment exclus dans cb23 sauf gros incident transitoire taches de fond ;  j'ai plus en mémoire le comportement de CB20 depuis 3 ans , mais pourquoi serait-il différeent ?
 
Ceci étant, Il y a peut etre éffectivement  une explication assez simple, c'est un bench fait fissa, comme ça,  sans intention autre que sortir un log fréquences,  avec donc possiblement des trucs en taches de fond qui ont produit ce yoyo dans les fréquences (?)  ;  

ben oui ça sert à rien de rentrer une valeur qui ne sera pas éffectuée ; à contrario on observe le plus souvent une baisse perfs  ; l'équilibre dans le triangle PBO et le boost n'est pas simple et reste pour l'éssentiel ...empirique     , par suite  tu appliques la logique Shadok et ça fonctionne plutot bien    

Il n'y a pas plus simple que la preuve que j'ai posté, et tu peux ouvrir le fichier csv, je l'ai partagé, même pas besoin de lancer GLV.

Peux-tu reconnaître que tu t'es trompé ou pas du coup ?
C'est ça qui serait le plus simple en fait, pas besoin d'embêter le dev alors que la réponse est sous tes yeux.

si tu peux, toi meme, envisager que tu te trompes aussi, on sera alors deux, pas de souci    
 
Mais en l'état, seul le dev a la réponse , pas toi  , désolé  
 
tu ne sembles meme pas envisager que certaines choses puissent t'échapper ici et tu procedes donc par affirmations de ta seule approche  , c'est une vieille dialectique bien  connue  ....

Se tromper ça arrive à tous, l'essentiel étant de savoir reconnaitre et rectifier

Je n'ai jamais prétendu tout savoir ou je ne sais quoi, je recentre donc: il est certain que GLV procède à un calcul de moyenne, puisque cette valeur n'est pas présente dans le fichier log. Pas besoin d'aller demander au dev, la preuve a été donnée.

Je peux encore recommencer la démonstration avec une autre sonde au besoin, prenons la température CPU, moyenne 82,06 d'après GLV (valeur qui serait notée 82.06 dans le fichier log, la virgule étant le séparateur entre les valeurs).

Valeur introuvable:

La valeur mini est par-contre (logiquement) bien présente:

Tout comme la valeur max:

Tu comprends enfin que la valeur moyenne est forcément calculée par GLV ? ou tu penses toujours que seul le dev a la réponse ?

Il y a quelqu'un pour confirmer SVP ? ça me parait tellement évident en fait que je ne comprend pas pourquoi c'est si dur de comprendre.

On peut aussi procéder au raisonnement inverse: il serait très improbable que HWiNFO procède à un quelconque calcul de moyenne sur les valeurs écrites dans le log, ce n'est pas le but d'un fichier log, surtout que le fichier est écrit au fur et a mesure.

question conne.
ça a une incidence sur le résultat si je lance un Ycruncher même en utilisant le pc ?
là, j'ai lancé ycruncher, mais je me sers quand même de firefox en même temps.
ça peut empêcher de trouver une erreur ?
 

Je ne pense pas non. Il n'y a que sur les bench qu'il vaut mieux ne pas l'utiliser, sinon ça fausse les résultats.

ok  
5° passes en cours
6°

plantage au bout de 14 cycles.
j'ai mis l'override à +25
je vais laisser tourner la nuit, et tant pis pour les bb phoques  

Tu as essayé le boost à 0 ?

à +25 ça plante pendant le 1° cycle.
j'ai essayé 3 fois.
là, je suis repassé ram@3200 override +50, j'en suis au 2° cycle.
vous avez raison, ça à l'air d'être la ram.
me demande si j'ai pas trop baissé le Vsoc

remis ram@3733 avec Vsoc 1.0625 => 1.0875
Override +25
1 cycle Ycruncher de passé alors qu'il y a 20mn ça plantait en plein milieu du 1°
je tiens "peut-être" une piste....mais je vais éviter de m'avancer trop vite
edit : 3° cycle ok

3 fois quoi : à+25 ou à 0?

oui, @25.   j'suis têtu j'ai dit  
bon
ça vient de planter.....mais moins rapidement qu'avant.  

je recommence avec un petit boost supplémentaire sur le Vsoc

c'est bizarre comme plantage. c'est même pas un bsod.

c'est écran noir d'un coup et le pc qui redémarre

edit : si ça replante, je désactiverais le boost pour retester

Je trouve vraiment suspect que y-cruncher plante comme ça.

Vraiment, tu devrais remettre la RAM et le vsoc @stock, trouver le réglage CO/boost où le CPU est stable, puis ensuite O/C à nouveau la RAM. Le gain amené par l'O/C CPU est plus important.

Lundi ...Lut'  Umibozu,  déjà pas la peine de faire appel à l'instinct grégaire pour te soutenir  ,  c'est un procédé éculé, et j'ai l'habitude de répondre lorsque qqchose m'est objecté avec argument attenant    
 
Bref meme si il y a un "choix" d'une fréquence moyenne, hors de toute rationalité s'y rapportant concretement, oui je  dénie la "valeur" ( au sens figuré) de ce que tu présentes comme un calcul précis de moyenne  ; parceque il est déjà largement faux en plus, vois ci-dessous sur la courbe fr Effective présentée par solstic3
 
En cela je suis dans la suite de cette méthode qui consiste à relever la fréquence max début de run et suivre son parcours jusqu'à sa valeur mini juste à la fin de run. et boom screen !
 
Solstic3 dit que c'est "moins précis" que les courbes qu'il produit avec LogViewer , au motif ( je le suppose) que la période intiale , celle où le processeur monte en charge et en fréquences peut etre 'eliminée' sur une coube GLV ;déjà c'est spécieux sur le principe  et sur la pratique c'est faux aussi en ce que HWinfo affiche le MaX Effective aussi , lequel est quand meme atteint tres vite .
 

 
En somme combien de temps le pross a ici été à la "fréquence moyenne" annoncée ? peut etre 250ms ....super informatif    
 
Par delà cet exemple , et meme tout autre comme fréquences ou tensions CPU , c'est la pertinence de calculer "à la truelle" une valeur prétendue "moyenne" , sans interet informatif réel  dans les faits. Enfin le plus souvent , bref pas toujours selon le type de tests.
 
un exemple simple toujours sur un run CB23 de 10mn  , suivi d'une breve période idle du cpu en fin de run , quelle serait ici la fréquence "moyenne calculée" sur la durée ? mettons que le cpu mouline à 4600Mhz pendant le run puis donc idle vers 100Mhz.
 
si on fait ce que semble faire  GLV ça donnera un simple bete et méchant  {4600 + 100) /2 = 2350Mhz de 'fréquence moyenne' , or ici --à aucun moment-- le cpu n'aura été à 2350Mhz PAS une seconde ou une minute .    
 
la meme objection s'applique à une moyenne automobile ! prenons le circuit de MOnza où de mmemoire il atait régulierement 'calculé' sur l'ancien tracé une vitesse moyenne de 240km/h , sur donc la durée de la course .  Quelle pertinence ? aucune !! je voudrais voir qqun rentrer à 240km/h dans une chicane ou  un virage serré , entre autre variétés du parcours...   c'est donc une pure abstraction d'aucun interet.
 
oui les valeurs 'moyenne' de HWinfo sont constamment érratiques, et à juste titre pour éviter ce genre d'erreurs de présentation  !
 
De meme HWinfo est incapable de rendre compte d'un bref et gros undershoot tension cpu qui fait planter, évenement trop rapide , trop bref, pour son polling rate ; il faut un oscillo pour voir ça ; par suite la courbe GLV tracée à partir des seuls logs ne montrera rien non plus.
 
Par contre oui c'est utile pour observer "à tete reposée" un comportement tension CPU dans ses grandes lignes et sur une durée x , entierement d'accord mais rien de plus en terme de précision . les valeurs HWinfo sont précises et ce sont celles utilisées par GLV pour faire ses graph.  
 
Bref il y a quelque ironie apres avoir dénié la pertinence d'observer les fréquences réelles sur la seule base de ce qui se passe entre MAX Effective et Réel Effective de fin , pour dire qu'un tracé GLV éffectué selon les logs de ces memes valeurs maxi/réel est "plus précis"  !!    
 
à nouveau, dois-je le répeter, l'observation temps réel des valeurs est suffisament enseignante , surtout à force de bien connaitre ce qui 'doit' arriver en principe, et donc immédiatement relever un comportement anormal.
 
et enfin si tu coches la bonne case ( tout enregistrer) tu devrais avoir une valeur 'moyenne' dans le fichier .CSV ( elles figure nominativement en tete de fichier dans la liste des valeurs possiblement 'loggées'  ) , sauf que comme la valeur est 'logiquement érratique' dans HWinfo , si tu rentres la valeur betement calculée (maxi+mini/2) , ben tu la retrouveras pas ! !p  indeed
 
 
 
 

sinon  pour refermer la boite et passer enfin à la video, je vais m'en tenir à une valeur haute de TDC , sans logique autre que les faits ; oui iles 115A ne sont PAS consommés selon HWinfo , mais OUI aussi cette valeur produit tres répétitivement une valeur bench élevée dans une 'fourchette' resserrée.
 
explications ? aucune précise, et je n'en trouve nulle part non plus et c'est bien dommage.    
 
Toutefois... je note que apres avor quand meme drastiquement abaissé la courbe V/F , je m'attendais à planter en tests divers...et non ! étonné du coup/
 
alors j'ose une approche qui serait que par delà l'absence de plus de TDC consommé selon les chiffres HWinfo , il se pourrait que l'apport soit trop bref pour y apparaitre . Ou pour reprnedre une analogie du plantage sur pic undershoot , la possibilité de monter meme tres brievement à plus de 95A TDC (par ex) pourrait ajouter juste ce qu'il faut de courant au budget puissance CPU pour que le Vcore ne soit pas trop sollicité drastiquement (?? )

 
Salut kobaia, tu fais un long message mais tu réponds à côté.
Sur le message que tu cites j'ai utilisé le graphique de température CPU (Tctl/Tdie), exprès pour te montrer que c'est valable pour tous les relevés, tu passes tout ton message à parler des effective clock...ce n'est pas le sujet !  
 
J'en suis arrivé à la conclusion que tu as des problèmes de logique et/ou de compréhension.
 
 
 
 

 
Une moyenne ce n'est pas (max+min)/2, mais toutes les valeur additionnées, puis on divise ce total par le nombre de valeurs, sur un truc aussi simple tu te trompes...
 
 
 
 
 
 

Non justement. As-tu ouvert le fichier csv que j'ai joint ?
 
Bref, j'arrête là, j'ai autre chose à faire.
 
 
 
 

toujours en cours
 

 
bof , j'ai les memes doutes depuis longtemps à ton sujet  , et c'est 'aggravé' par un coté péremptoire dont il faut s'accomoder sinon pas de discussion possible
 
juste un point quand meme ...explique moi comment tu vas calculer une 'moyenne' pour un pross à 4600 pendant 10mn puis idle genre à 100Mhz que ce soit 2mn ou 10mn OSEF  ? tu vas additionner ta suite de 4600 et de 100 pour aboutir à une valeur moyenne que le pross n'aura pourtant jamais occupée sur la période , elle sera factice   et pourtant tu prétends en "calculer" une ....  okay
 
j'ai pas ouvert ton fichier mais le mien et ya bien une valeur moyenne qui traine qqpart ( c'est *précisé* dans l'en tete je te l'ai dit sauf si tu logges pas TOUT )  mais... faut la trouver , en tant que valeur érratique et qui ne peut que l'etre !
 
Bref perso itou je passe à autre chose , je suis tres en retard   , depuis l'assemblage de la machine en ..février.  
 
mais j'aime bien duscuter     meme avec les gens qui ont un flagrant tremendous ego problem  , ça me dérange pas tant que ça reste courtois , il y a  toujours des choses à apprendre  directement ou ...indirectement tout autant , voili ,  bien cdlt    
 
 
 
 

rhaaa
 
plus de 2h de test sans problème et vlam
 

kobaia, j'aime aussi discuter, mais au bout d'un moment quand la personne en face est incapable de comprendre que 2 et 2 font 4, je finis par perdre patience, et intérêt à la discussion, tu y vois un problème d'égo si tu veux, mais si tu relis nos derniers échanges peut-être que tu verras que je n'ai fait qu'essayer de te faire voir un truc simple: oui GLV calcule des valeurs moyennes, et extrait le min et le max sur chaque série de relevés. C'est tout. Tout le reste est HS.

Après ouais j'ai probablement tort d'insister autant, c'est vrai, mais j'aime bien aider les autres.

Tu testes avec la RAM O/C si j'ai bien suivi ? du coup comment savoir si c'est le CPU ou la mémoire.

j'suis en train de tester la ram, tout simplement
 

 
CO désactivé. Override désactivé
 
à partir de quand je dois me dire que ma ram n'est pas stable en fait ?
 
les emmerdes arrivent (en tous cas pour le moment), quand j'active le CO.

Les erreurs WHEA, c'est souvent quand lié au contrôleur mémoire non ?
 
Pourquoi ne veux-tu pas tester avec la RAM à 3200 en fait ?

parce que ma ram est stable et que le problème ne vient donc pas d'elle mais des réglages CO tout simplement.
ça serait une perte de temps de tout recommencer et j'en perds déjà beaucoup

mon proco ne doit tout simplement pas pouvoir tenir les -30 sur les mauvais cores.

il a sans doute besoin de +  

Mais si en testant avec la RAM à stock c'est stable, tu en déduis quoi ?

pour le moment, tout ce que je peux déduire, c'est que ma ram est stable comme elle est. je dois donc trouver les réglages CO stable qui correspondent à ma mémoire stable.
si je me mets @stock, je vais chercher des réglages CO qui correspondent à ma mémoire @stock (qui ne seront peut-être pas les mêmes), et ensuite, je vais me casser le q et recommencer à chercher ma ram stable avec le co stable ("proco o/c" ).

ça revient exactement au même de partir sur une ram stable, et de chercher le CO correspondant sauf que je perds pas de temps à recommencer sur la ram et je perds pas de temps à chercher un CO stable sur une ram@stock alors que je vais la bouger après.....et va savoir, retrouver le même problème à un moment.

je considère que c'est tourner en rond.

ma ram est stable, je dois chercher le CO qui y correspond.

et si je n'y arrive pas, et bien c'est pas grave, ça restera comme ça parce que j'ai pas envie de me recasser le q 2 fois  

edit : 20 cycles (4h), je pense que c'est bon. c'est comme si elle était @stock. elle est stable

je teste autre chose pour voir où ça va me mener.
 
CO désactivé ; Override +25    
 
je sais pas trop ce que ça peut faire, mais je dois le faire  

Tu crois que c'est important l'override?
Testé à 0 ou en auto pour voir si ce n'est pas lui qui fout le souk.

aucune idée si c'est important ou pas. en tous cas, c'est pas lui qui fout le bordel.
 

CO activé ; Override +25

edit :

CO activé ; Override +50

Hello  
 
Je vois que pas mal de monde augmente la fréquence infinity fabric de 1800mhz a 1900/2000...
 
Est-ce fonctionnel avec pbo et co ?
Quel sont les valeurs a ajusté au niveau de tension ect ?  
Quel moyen de test vous utilisez pour vérifier sa stabilité ?
 
Actuellement je suis en pbo/ci actif avec la RAM a 3600mhz cl 15
 
Merci

Le but c'est d'être synchro avec la RAM, donc avec de la 3600 il faut rester a 1800.