Salut,
 
J'étais sur un autre forum et je me suis orienté vers Hardware.fr.
 
Je ne veux pas faire d'éloges gratuitement mais je pense que la présence de boblemagnifique et de Fouge accordera dans la tonalité un peu plus de sérieux aux remarques que je veux faire sur l'overclocking des procos AMD puisqu'ils ont leurs lettres de noblesse désormais.
 
Alors voilà je suis le banni    de l'expertise de cpuid qui en février 2008 a toutefois validé un joli 4851,xx MHz sur AMD 64x2 5000+ Black Edition sans recourir au refroidissement extrême sous azote liquide.
 
J'ai ensuite validé sous cpu-z et Everest et Super ( de e-RightSoft ) de nombreuses mesures entre 3,8GHz et 4,xxGHz
Et j'aimerais que l'on puisse en discuter un tantinet entre gens rigoureux ET discuter de la méthode que j'utilise sans que l'on hurle au fake.
 
Je fais de l'overclocking depuis 2/3 ans. J'ai beaucoup d'admiration pour ses représentants.
 
J'espère que vous ne me jetterez pas ( 'serait dommage ), que vous serez intéressés et que vous comprenez d'entrée que je suis très conscient qu'il y a une grosse différence entre une OC stable prête à bencher très en dessous de 0°C et un "suicide run" de quelques secondes à 4GHz en AirCooling comme ce que je pratique.
 
Mais si tout le monde conteste et que n'importe quel instrument de mesure valide je crois qu'il y a à dire tout de même.
 
Je ne vise pas de record OC je vise l'intérêt pour ma méthode ( et éventuellement les conclusions ensuivies ).
 
Donc le sujet est lancé ... ça va pas être facile   , mais on ne sait jamais ...

Commençons par la vérité.
 

 
Ceci est l'écran du validateur de cpu-z lorsque j'ai vérifié sur le validateur de cpu-z si mon OC était valide.
J'ai pris soin d'en faire une copie.  
 
Je place ce screen dans la mesure où quelques jours après l'adresse de ma validation précisait "rejected by cpu-z" et non plus "validated by cpu-z".
 
Il n'y a aucun fake ( graphique ).
Je suis complètement incapable de changer en quoi que ce soit le fichier de validation ( qui est notre traditionnel fichier .cvf que l'on upload sur le site du cpu-z validator après une OC ).

Bon, la "hauteur" de CoreSpeed atteinte est gigantesque.
 
J'ai précisé 'commençons par la vérité' parce que c'est la vérité, il n'y a aucun fake ( contrairement à ce que la presse Internet a jugé bon de conclure ).
 
J'appelle ces bonds de la fréquence CPU des "bounces".
 
Voici un effet "bounce" mesuré sous Everest :
 
cliquez ici
 
Les 2 images sont sous la forme d'un album hébergé chez Hiboox.  
La 1ère image est la fréquence définie par les réglages du Bios,  
la 2ième image est la mesure CoreSpeed, RAM, ... effectuée par Everest lorsque j'atteins un "bounce".
 
Le proco est un AMD Athlon 64x2 5000+ Black Edition ( avec un multiplicateur débrayé Black Edition ). 3709,xx MHz est très très difficile à atteindre en règle générale en Air Cooling.
 

Tu aimes parler tout seul ?

Du tout    
 
C'était du teasing.    
 
J'essaye d'attirer l'attention    pour savoir ce que les Clockers pensent de ça. Dans la mesure où planter 4GHz en AirCooling sur des AMD 5000+, 5200+, 5600+ c'est pas toujours quoi.    
 
Rockstable et prêt à bencher 3D Mark ou SuperPI ce n'est pas la même chose qu'un MaxScreen.
 
J'ai pensé d'abord à une présentation du sujet... et pis, puisque ça peut intéresser je vais dire comment on peut faire ça (  ).
 
Je me prends un peu au sérieux    mais... je vais tenter de l'expliquer "entre nous" ( c'est-à-dire pas en entier ). J'espère qu'il n'y aura que les vrais overclockers qui sauront compléter les parties que je n'expliquerai pas, de façon à éviter que la Base de ripping.org soit faussée.

Pour moi un o/c digne de ce nom ce n'est pas une screen cpuz, mais des preuves de bench de plusieures heures.
OCCT cpu & linpack , LinX et j'en passe.

ca depent, c'est comme en course auto y a des categorie  
et chacune a ces adeptes  
 
 
max stable (stable et utilisable pour bench/jeux ect sans limite de temps )  
max benchable ( asses stable pour lancer un bench ou deux mais guerre plus, ca plante, sort un BSOD ou reboot n'importe quand )
max screen ( stable a peine asses longtemps pour lancer CPUZ, passer la valide et sauvegarder un screen avant de planter )

Entièrement d'accord, même si pour moi la seule catégorie valable et intéressante est le max stable.
 
Après bien sur, il y a les records, de chaque catégories.

ben max bench c'est l'equivalent de la F1 et le max screen c'est le dragster de l'informatique ...ca plus grand chose avec ce qu'on peut voir tous les jours, mais ca permet de faire progresser le domaine en general et ca fini toujours par se retrouver en grand public

Un MaxScreen AMD, que ce soit sur 5000+ ou 5200+ cela signifie 3,5GHz à 3,6GHz en AirCooling. Il n'est pas possible d'aller plus haut.
 
Je n'utilise l'overclocking que pour tirer parti de matériel un peu "haut de gamme" dans la répartition du marché commercial ( par exemple une CM de chez DFI, profitant de la présence comme sur les CM Asus de 3 slots PCI ) pour avoir à disposition :
1) une bonne carte son PCI
2) une carte Tuner TV/TNT/sat
3) un vieux modem K56
Ceci signifie donc que je cherche plutôt le max stable en soignant la composition de mon système. Il y a coïncidence matériel et qualité matériel.
 
Max stable@3,3GHz tout juste est une bonne base pour l'utilisation quotidienne des 5200+/5600+.
 
Les vrais "pros" du réglage RAM sont les Intellistes. Les procos AMD comportent, eux, un contrôleur RAM. ( bien que le nouveau Corei7 d'Intel l'ajoute désormais )
 
Puisque j'aimerais en placer 2 tirades la technologie AMD comporte aussi le Cool'n'Quiet. Les processeurs AMD aiment et connaissent bien la prise CPU Fan   .
 

1) procos AMD : contrôleur mémoire ( dans le proco )
2) Cool'n'Quiet : le proco peut provoquer une variation de la vitesse des ventilos CPU
 
Avec un gros, gros, gros bizz' de la Ram ( encodage vidéo sous Windows Movie Maker ) le processeur peut rencontrer une information Ram qui sollicite la liaison processeur-Ram sur le socket AM2.
 
Si pendant ce travail d'encodage vidéo on retourne dans le processeur avec une prise CPU-Fan dédoublée ( un push/pull à 2 ventilateurs ) alors le processeur est accaparé par le calage de 2 fois plus d'instructions chaque seconde au niveau de l'information de vitesse de la prise CPU-Fan ( la PCB renvoie au processeur 2 fois plus souvent un re-réglage de la vitesse envoyée à la prise CPU-Fan ).
 
Toutes les sondes de l'instrument de mesure ( par exemple CPU-Z ) sont à plusieurs endroits de la PCB. L'instrument de mesure a une cohérence globale. A force d'avoir trop de choses à faire, d'après les autres endroits de la PCB, l'instrument de mesure en déduit par re-calcul que le processeur devrait être à une fréquence de traitement d'instructions correspondant à beaucoup, beaucoup plus de choses en même temps ( re-calage CPU fan, liaison processeur/Ram ).
 l'instrument de mesure en déduit par cohérence de ses routines de calcul que le processeur est à une vitesse complètement folle.
 
à mes admirateurs

En bref j'effectue un "jogging MMX" avec le système.
 
Je lance en même temps plusieurs applications vidéo, notamment Windows Movie Maker ( sous XP ça marche mieux ), en important un gros fichier .avi sous Windows Movie Maker pour que l'appli' MOvie Maker intègre le fichier 600 Mo dans l'ensemble des éléments nécessaires à la constitution d'une vidéo.
 
Je branche une caméra USB en temps réel.
 
J'effectue au même moment une conversion de fichier MPEG4 sous une appli' de conversion de fichiers.
 
La charge processeur se trouve entre 2/3 et 99% et le processeur chauffe énormément.
 
Plus le voltage NB ( VCore NB ) est haut, plus le principe bounce fort.
 
Plus le voltage HT est haut, plus le principe bounce souvent pendant la conversion sous Windows Movie Maker.
 
Je pense qu'alors le système est saturé et que la hiérarchie ordinale des différentes prises d'informations du logiciel de mesure ( cpu-z, everest, super, ... ) reste comme en suspend.
 
Je fais aussi remarquer que pendant cela le voltage VCore bouge beaucoup sous cpu-z.
 
Enfin, ce principe ne se manifeste plus si l'un des slots PCI est sollicité ( carte son en même temps qui dispatche de la zik', TV tuner en marche en même temps ) ... la transaction PCI interrompt ce petit phénomène sympatoche.
 
Si quelqu'un a une idée là-dessus    

oO  
 
(désolé c'est pas constructif)

 
 
( Pas constructif non plus mais en attente d'information )

voici ce à quoi cela ressemble

je connais bien ce phénomène : ça s'appel du "bit-looping" ou encore "super-calc", c'est selon si on en connais la provenance ou pas . c'est un phénomène aléatoire et récurent d'erreur d'interprétation, à l'échelle des octets, de bit sans syntaxe (sans table de commande [ table command term] ou code d'execution [ access execution code]) entre le hardware et le software.
Comprenez :
les bits seuls ne veulent rien dire, pour cela il sont regroupés en bytes (octet) afin d'être interprétable par un système de commande [TCT] ou par un système de compilation [AEC], Leurs rôles étant de définir tout les paramètres concilié autour de ce ou ces bytes et donc de savoir :
-Qui l'a créé (programme vers matériel ou inversement) ?
-Pourquoi (alerte, avertissement, information, commande, question, requête)?
-Quel est son langage (code machine [bin, rom vous connaissez nan ?], code logiciel [C, C++, etc...] ?
-Quelle est sa fonction (Action, rapport, report, copie, bloquage, autonome)?
-Quelle est son chemin (CPU par NB pour GPU, ou juste CPU/GPU) ?
-Quelles sont ses conséquences (interaction hardware, software ou même interactivité dans le cas de bytes provoqué) ?
-Qui suit sont parcours (sonde, ECC, parity bit checker, CPU, instructions vectorielles simple [PtoQL-C, C-mov, B+] qui raffole de ce genre de délire)?
Et enfin    :
-Quel est son degrés de transmissibilité (aller simple, redondant, aller retour, boucle)?
 
Et on ne va s'intéresser qu'a "Qui suit sont parcours", car :
-Qui l'a créé  -> le programme "sonde" que vous avez lancé;
-Pourquoi      -> Pour connaitre une valeur une fois compilé;
-Son langage -> Code machine Bin pour être précis;
-Sa fonction  -> Report;
-Chemin        -> évident !!  mhm bon : mem->NB->CPU->NB-> mem... bien que le retour par le NB n'est plus pertinent depuis K8 et i7 (quoique i7 )
 
Donc ici c'est un code d'exécution et d'accès que nous avons [AEC]. pour faire court :
leur fiabilité dépendrai de leur chemin et de leur transmissibilité, s'il n'était pas suivi ! Mais pour parer à cela un cycle de 'question', 'requête' et 'report' a été mise en place pour lisser les valeur obtenus entre chaque compile. Et c'est la que ça devient drôle : si deux logiciels utilisant le même procédé d'interprétation des données, sont lancés pour la même tache (CPU refresh time) ou sur le même ID d'execution processeur (ce qui est pas si rare, mais tend à disparaitre avec le x64 et le multitask comme dit bill), ils se basent sur leurs temps de 'suivi' pour évaluer : 'valeur', 'compile' et 'report' ... En gros il arrive qu'ils se retrouvent à interpréter des fragments de données de plusieurs 'suivi', en les compilant, leurs permettant ainsi de continuer a fonctionner. L'erreur peut s'exprime d'avantage quand le processeur centrale est fortement sollicité.  
 
Dans notre cas, cela peut être du "super-calc" du au fait de mauvais timing de 'suivi' permettant l'interprétation des résultats, les faisant ainsi se fragmenter dans le pipe de compilation (ça marche aussi sur sandra je vous le confirme 27,73Gips pour un 2800+ au lieu de 5,76 ), mais cela peut aussi être du "Bit-looping" du au fait des 'suivi' des octets de 'report', les faisant ainsi ralentir à cause du poid de cette méthode de transmission ou les faisant au contraire accélérer ainsi du à un excès de latence qui libère par-à-coup les octets de 'report' faisant grimper les chiffres !
Tout cela pour dire que ces "bounces", sont en réalité des erreurs d'interprétations de simple octet a l'echelle materiel

Je vais apporter de l'eau à ton moulin, puisque tu témoignes ici, "enfin !" ( dirais-je ), d'une grande précision d'explication ainsi que d'un intérêt qui n'est finalement pas journalistique.
 
Le Web m'a jeté, Nordic Hardware en l'occurrence en premier, ... purement et simplement, à la corbeille.
 
Je valide mes Suicide-Runs. Ils sont acceptés par le logiciel CPU-Z. Ces poussées allant jusqu'à 5000MHz pour un AMD Athlon 64 double core passent sans tricherie le crible de la validation CPU-Z.
 
AMD A64x2 5200+, AMD A64x2 5000+ Black Edition, AMD A64x2 5600+.
 
Il n'y avait pas, selon moi, de vrai raison pour se désintéresser de mes validations   .
 
 
J'ai fait de l'ombre à la fiabilité du logiciel français CPU-Z. Son auteur est entouré de quasi-professionnels de l'informatique.
 
En moins de 24 H après le démenti "PLL exploit", publié en world wide web au premier semestre 2008 par la communauté overclocking à la suite de la validation d'un Core Speed à 4851MHz pour un A64x2 5000+ Black Edition, j'ai reçu des menaces très graves sur mes diverses configurations, des menaces explicites sur le Web dirigées contre ma propre famille.
 
----------
 
J'apporte de l'eau à ton moulin : je m'arrange lors de mes Suicide-Runs pour faire passer un double temps d'analyse de la vitesse des ventilateurs du rad de mes processeurs. Chaque rad est monté en push'n'pull ( 2 ventilateurs de 120mm de chaque côté du gros radiateur ).  
 
Mais en plus du simple push'n'pull je ne relie pas seulement les 2 ventilateurs de 120mm à la prise CPU Fan de la carte mère grâce à un dédoubleur classique.
 
Un dédoubleur aboutit, de 2 vers 1, à une seule prise unique qui est branchée sur la prise CPU-Fan de la carte mère. Cette prise CPU-Fan comporte une sonde au niveau du branchement direct sur la carte mère; cette sonde de vitesse est ainsi l'une de ses trois fiches au total.
 
Là où cela pourra peut-être t'apporter plus de facilité à te figurer ce qui se passe j'insiste sur le fait qu'il existe dans le commerce deux types de dédoubleurs :
- Le premier est incomplet puisqu'il ne comporte qu'une seule sonde ( celle-ci se trouve disponible pour seulement 1 des deux ventilateurs );
- tandis que le deuxième type de dédoubleur, lui, comporte une sonde de vitesse sur chacune des 2 prises que l'on branche sur chacun des 2 ventilateurs de 120mm.
 
Etant donné que ce dédoubleur 2 vers 1 se branche finalement sur la prise CPU Fan de la carte mère, la prise CPU Fan de la carte mère reçoit les impulsions dues aux 2 variations de chacun des 2 ventilateurs.  
 
De ce fait la carte mère reçoit un double temps d'analyse de la vitesse finale "CPU Fan". Elle n'est habituée qu'à un seul signal provenant du nombre de tr/min d'un seul ventilateur. Ici elle s'habitue à un signal alterné indifférent qui provient du mix des 2 vitesses. Chaque ventilateur a son droit d'impulsion donc la carte mère reçoit un double temps d'informations, informations qui sont des vitesses CPU Fan, la carte mère reçoit ces informations ainsi que le processeur.  
 
Le processeur AMD sait interpréter chacune de ces impulsions à chaque temps d'information ( "report" ) signalé par la prise CPU Fan située sur la carte mère.
Je fais passer par cette prise CPU Fan un double temps d'analyse de la vitesse des ventilateurs du rad CPU.    
 
Qui plus est, c'est un des meilleurs principes de cette génération de processeurs puisque l'interprétation classique des impulsions de la prise CPU Fan par le processeur A64x2 s'appelle le Cool'n'Quiet... et elle fonctionne en duplex puisque la vitesse du ventilateur CPU sera changée lorsque le processeur témoignera d'une température nécessitant une augmentation ou une diminution de la vitesse du ventilateur principal CPU Fan.    
 

Bien, très bien. . Pour améliorer ta compréhension je vais faire "tourner le moulin" dans ton sens, car ces erreurs s'applique encore mieux sur du hardware/hardware :
 
Comprend que, tout cela est électrique donc facilement manipulable. Ajoute à cela le rôle des Normes-Lanes qui sont, à leurs créations, des "en-têtes" de lecture pour les octets 'autonome'. Pour introduire cela dans un schéma compréhensible, je vais revenir a ton point de départ :
- Le rad CPU :
 Depuis la création de ces en-têtes de lecture en 1995, ils ont été adaptés en premier lieu au 'rapport' de certains périphériques PC qui ne pouvait fonctionner sans un processus en ligne, tel que les périphérique ISA, certains PnP aussi, mais surtout PCI. Ils étaient alors nécessaire pour l'utilisation par le système d'exploitation, que cela soit en transparent (arrière-plan) ou en limpide (invite de commande à l'époque du dos, par fénêtre depuis Windows 3.1). En 96-97, certains composants "enfichable" (comprenez application se lançant avec peu ou pas d'interaction sur l'utilisation d'un PC dans la vie de tout les jours) commence à en faire usage sous win95OSR2, pour les ports COM & LPT. Il s'agit d'un concours de circonstance que cela soit nécessaire de les introduire dans des contrôleurs hardware, comme les monitoring et cela en 97-98, pour le pMMX et pII. Cela se matérialise par un circuit intrinsèque comptabilisant, sans compilation, des séries de bytes autonome générés par un Mosfet, dans le circuit d'un moteur CC créant des "bits seuls" (en gros des impulsions de passage, un compte tours électrique quoi) à chaque tours qu'il effectue. le mosfet va générer ce "signal" avec le pôle négatif du "moteur". pour faire une parenthèse il s'agit en fait d'un bobino-résistance qui commute grâce a ce mosfet, sur deux ou plusieurs pôles chacun à tours de rôles avec un sens précis, permettant la mise en rotation de l'armature ferro-magnétique avec laquelle il est en répulsion. voilà pourquoi le terme moteur n'est pas des plus approprié. Bref, ce "signal" affirme la rotation du ventilateur et informe de sa vitesse.
- Le Cool&Quiet :
 Ce procédé mise en place avec les K8 en 03 (C&Q 1.0), vise à effectué une liaison privilégié entre le ventilateur et le CPU. cette liaison rendu à double sens avec les K8 X2 et les FX X2 (C&Q 2.0), permet au processeur de "parler" avec son ventilateur. Cela lui permet entre autre de faire varier sa vitesse par le biais d'un plot Ohmique sur le ventilateur. ainsi équipé du circuit RC complet, cela lui permet tout aussi bien de se couper le cas échéant ou le CPU le lui demandait "R= x > 1", d'aller au dessus de sa vitesse nominale "R= x < 0", en plus des variations de vitesse "R= 0 < x < 1". Ce procédé fut encore amélioré en 06 (C&Q 3.0), notamment sur les K10 grâce a un fréquenceur (grille ACC rev.A [en 06] jusqu'a D [en 09]) mise en adéquation avec l'amplitude de la rotation. appelé PWM et avec des explication plus poussées, cela dit   .
- Le fin mot :
 Pour cela je revient sur les normes-Lanes qui est un en-tête de lecture, qui s'applique à rendre les bytes autonomes utilisable par le CPU à leurs arrivé sur la carte-mère. À la différence des 'suivis' les normes-lanes n'accompagnent pas les octets, elles se contentent d'ajouter un bits de lecture et de diriger ces octets au bon endroit. Alors pourquoi ne pas les utiliser partout   ? tout simplement parce qu'elles ont une seule voie de traitement (résolument une chaine à "bip" qui rajoute un "un" ou un "zéro" ) et une latences de 580 à 730ms   ! C'est la d'ailleurs que les 'suivis' améliore leurs réponses, car non assujetties aux limitations sur les pipes, il peuvent avoir une latence de 230 à 110ms selon les performance et le degrès de finition des lanes de votre carte-mère   . Avec un Y-bracket typique, les bytes envoyés du ventilateur au CPU font l'objet de tronquage sérieux au niveau de leurs intégrité, cela à pour conséquence de générer un Super-Calc à partir duquel le CPU devra interpréter le statut actuelle de son ventilateur. Car le fait est qu'il y a qu'une seule prise donc un seul groupe de norme-lanes, et que par voix de conséquence communiquant dans les deux sens, il arrive que le statut CPU soit mise en faute parce que le C&Q n'a pas pu intégrer des données viable dans son ou ses rapports du ventilateur   !
Au vu de tout ceci :
la vitesse erroné du ventilateur, bien souvent inutilisable car corrompu,
le résultat du C&Q, qui du fait ne répondra plus avant le prochain cycle d'analyse,
et la désinformation du CPU, il en résulte bien souvent un Super-Calc dont seule la carte-mères à le pouvoir de corriger. Car elle seule à le droit de régénérer les cycles d'horloges : que cela soit FSB, D-Ram Timing, PCI Clock refresh, World Clock timer ...
Voilà pourquoi par intervalles irrégulières, de la désinformation est générée par le CPU lui-même lorsqu'il affiche une fréquence abérante et incohérente avec les paramètres de la carte-mère qu'elle seule corrigera lors du prochain T-clock. Mais sa propre fréquence n'a pas bougé, car ce n'est que l'interprétation de celle-ci qui a fait qu'elle apparaisse aussi extravagante.

Mince, en lisant ça je pensais pouvoir booster mon A64 3200+
Je vais regarder la vidéo.
Edit : 6,7Ghz

IL est plus qu'important de garder à l'esprit, que ces lectures sont fausse !!! les vrais réglages et les vrais paramètres n'ont, eux, pas changé d'un poil    
 
Voilà, tenez le vous en pour dit

Question bête : un test "auto-corrigé" comme SuperPi doit pouvoir lever le doute facilement non?
 
Même si le CPU est censé tourner à 14.5 Ghz, SuperPi va se planter le nez dans la poussière au bout de la 1ere itération, ou faire son "temps normal" (on peut aussi chronométrer simplement en externe, histoire de ne pas lire "woah en 4 sec" alors qu'il a mis 2 minutes )
 
(?)

@NORAD (nuke 'em up ) : le prob c'est que Franck (D. ) il a développé un soft ACPI/WMI qui se sert du disque dur pour interfacer la lecture des informations CMOS qui sont envoyées avec le Bios au démarrage du système. Regarde par ailleurs son "set FSB" >> les valeurs changent.
 
Donc on ne peut pas dire que les paramètres ne bougent pas d'un poil.
 
@Zonka : j'ai chronométré >> c'est pas significatif :  avec un jumping à 10GHz il y a une différence d' environ 0,125 secondes ( en temps de durée d'un long calcul Super PI 1M ). 0,125 secondes systèmatiquement en plus lorsque cpu-z prouve la présence d'un jump/bounce pendant le calcul.
 
Je l'ai fait 15 à 20 fois >> c'est pas très significatif.

Je me dois de vous encouragez à relire ce que j'ai dit plus haut , apparement les réponse vous ont échappé, ceci dit sans offense . La carte-mère n'est pas exclu dans ce phénomène, elle est juste la seul à pouvoir corriger ces lectures éronées et ce au prochain cycle d'horloge . Mais il vrai que cela reste tout-à-fait amusant de voir c'est chiffre futuriste apparaître ainsi !! Je vous propose de faire la même chose avec vos vieux frigos, genre PIII, Duron ou même Celeron ! Cette Anomalie devient sensiblement plus prononcé avec un FSB de 100 Mhz minimum, à bon entendeur   ...

Super PI, entre autre de faire augmenter ce phénomène durant ces Itérations de calcul, ajoute une part de discrédit quant à la véracité de l'utilité d'un tel phénomène ; La valeur complexe des calculs y aidant j'en est bien peur . Cela dit, il aide effectivement à lever le voile : La variation du temps final de calcul n'est pas affecter ...

Mon égo va en prendre un coup mais n'y a-t-il pas plus de sérieux à croire que le processeur atteint en définitive ces valeurs allant de 1,2GHz à 20GHz.
 
Je mets exprès la Ram à un voltage de 2,29V ( pour de la G.Skill PC6400 HK qui a un Vstock autour de 2,0V/2,1V ) sinon ça ne marche pas et je la cale à 350MHz environ comme démarrage avant tout "bounce" possible.  
 
Rien ne sera jamais significatif dans ce phénomène :
- parce que cela ne dure que 1/2 seconde environ, chaque
- parce que à ces fréquences là le processeur ne fera, en 1 seconde ou en 1/2 seconde, rien de spécial. Même à 10GHz pendant 1 seconde qu'est-ce que fait un processeur déjà lancé sur un travail ?
 
S'il y a "PLL effect" c'est qu'il y a Over-voltage, le temps que la PLL redresse le courant. Il y a un gap, un laps de temps, pendant lequel le processeur est alimenté par un courant non compréhensible par un processeur déjà lancé.
Pendant le même laps de temps le processeur est accaparé par des opérations d'encodage qu'il connaît hyper bien sous Windows Movie Maker. Rien n'empêche qu'il les fasse quasiment sans pouvoir s'arrêter pendant ce laps de temps. C'est le principe de l'apprentissage électrique du cache L2. Pendant ce temps le courant alimentant le processeur est anormal. Il y a Over-shoot du voltage... le temps que la PLL re-délivre un courant continu correctement redressé.
 
Moi je crois, personnellement, que cpu-z, Everest et Super de e-RightSoft ne peuvent pas commettre la même erreur de routine de calcul et d'affichage du Core Speed.

Il est vrai qu'il peut paraître (pour certain) important de croire en quelque chose pour avancer, mais cela ne doit en rien nous empêcher d'être cohérent, neutre et de savoir garder un minimum de cette approche cartésienne qui font de nous des êtres curieux de la technologie et de ses déboires pour être elle aussi cohérente ...
Toutes ces ressources de travail que sont un Ordinateur aujourd'hui mettent, de plus en plus, un temps infinitésimal pour se "rafraichir", une sorte de check-up très peu élaboré qui consiste à ré-effectuer une impulsion de mise à zéro, le point de départ d'un de ces fameux cycle d'horloge née en 1950. Il est vital de garder à l'esprit que nous tous, maîtrisons avec une quasi-perfection, la base de ce système qu'est l'informatique, à savoir : L'électricité ... Déplacement d'électrons d'un corps conducteur à un autre (pas nécessairement le même), ce phénomène est on ne peut plus influençable : il l'est par adduction de tension, de courant, de résistance, de champ, et par simple interaction sur son cheminement. Les bases sont jetées !
 
Les éléments qui constituent un Ordinateur aujourd'hui sont à la fois très complexes: GPU 3 milliards de Transistors, CPU +500 Millions, "ET" à la fois très simple: circuit RC, Circuit dopé N (ECC, parity Check) ou dopé P (TMC, SOI, etc..), par voie de conséquence il sont, eux aussi, très influençable car assujetti à ces mêmes faiblesses qu'a l'électricité ! Mais ce n'est que l'électricité qui à ces faiblesses , en aucun cas les éléments d'un ordinateur et cela même si certains de ces faits peuvent se répercuter sur ces dits éléments, cela reste par pouillème (expression pour nommer les fragments d'éléments atomique devenu très petit ) et d'une intervalle de temps quasi-inexploitable... Et pire cela ne change en rien la tension que le processeur reçoit, si cela parvenait ne serait-ce qu'a dépasser les étages d'alimentation, quant au courant, c'est la résistivité induite du processeur qui dicte le courant qu'il absorbera pendant son fonctionnement, que cela soit au repos ou en pleine charge  ; c'est une loi de la physique : I = U/R   !!! Plus le processeur travail, plus les transistors sont passant, plus les électrons sont happés, dirigés en quelque sorte, vers le processeur et les électrons n'étant ni plus, ni moins que le courant "I", les ampères, bien qu'ils ne se limitent pas à ça... Avez-vous compris tous cela ??
 
Pour ce qui est de CPU-Z, Everest, Super, a qui vous pouvez ajouter, AIDA32, SetFSB, PC Probe et j'en passe pas des meilleurs, exception faite pour sandra qui ne fait que lire les DMI's, TOUS, ne font que lire des expressions Octales, des bytes si vous préférez, d'accès [AEC] pour définir, paramêtrer et même afficher des données sur votre processeur : sa fréquence d'horloge, son ou ses bus, sa tension et j'en passe , pour la simple, bonne et unique raison : c'est que, en temps réel une fois sous OS (peut importe laquelle et sa version x86 x64), c'est la seule façon de procéder pour obtenir en temps réel ses valeurs ...

J'ai relu.
 
ça y est, moi, j'ai trouvé !!
 
Enfin.
 
Post Electroscriptum : Franck, si tu passes par là, je sais mes tendances à te tutoyer dans mon domaine à moi, mais en définitive... là, j'ai vraiment trouvé.
 
 
 
C'est histoire de rappeler de deux façons coriaces que j'avais VALIDE le record d'OC AMD en 2008.
 
Honnêtement... 4959,5 MHz... ça se voit pas tellement.
 
 
Et donc... plus simplement : merci, NORADII.

alors ? ?