Enfin ! Il aura fallu un peu de temps, mais AMD vient enfin de confirmer la question de l'impact du Core Parking pour Ryzen sous Windows 10, que nous avions ...
Lire la suite ...

Impact sur la conso. ???

Bah ça risque surtout de changer la conso idle de quelques watt rien de plus.

Ca ne change pas la conso que l'on mesure dans nos tests (idle, charge un coeur, charge tous coeurs).  
 
Ca peut légèrement changer la conso dans le cas de charges intermittentes dans le sens ou les coeurs rentreront plus vite dans les modes d'économies d'énergies. Des petits gains qui joueront surtout sur les versions mobiles, sur Desktop c'est marginal. J'ai clarifié ce passage dans l'article du coup.

Vous êtes les meilleurs !

Ah super, merci pour la news !
 
Attention par contre, dans Windows 10, la gestion d’alimentation minimale du profil AMD Ryzen balanced est à 90%.
Personnellement je l'ai baissé à 5%, comme la valeur par défaut du profil Utilisation Normal.
EDIT 1 :Il ne faut pas faire ça, tout est géré par le CPU avec ce mode et non pas le scheduler windows.

Oui exactement, ce seuil fait qu'en pratique on bypasse le P2, ce qui veut dire que dans les logiciels de monitoring on ne verra plus 2.2 GHz, mais l'économie d'énergie sera toujours active. En pratique même quand on voyait 2.2 GHz, on n'était pas à cette fréquence (d'après nos informations Ryzen peut descendre à 400 MHz en fréquence avant d'éteindre le coeur, mais AMD ne souhaite pas communiquer là dessus donc chut on a rien dit !).  
 
Donc entre laisser 90 ou passer à 5, sur desktop, c'est peanuts en diff. Sur mobile par contre tout compte !

Merci pour le super boulot C_Wiz
 
Profil installé et testé pour ma part, rien de particulier à signaler. Je confirme que les softs de monitoring habituels ne "voient" plus la fréquences du processeur baissée.
 
En regardant d'autres discussions sur le net et pour résumer il semblerait que le changement d'état se fassent désormais trop vite pour que les softs en questions "capturent" le changement d'état/fréquence.

C'est pas une question de rapidité non, les softs en seraient capables, mais uniquement lorsqu'il s'agit du changement d'état géré par le scheduler Windows.
 
Tout ce qui est fait par le CPU (donc tout ce qui est "sous" P1 dans le graph) n'est pas monitorable parce que AMD ne donne pas accès à ces informations, tout simplement !

Ah ok, makes sense

Donc dans les profils de gestion d'alimentation il y a plus de paramètres que ce que laisse voir Windows?
Existe-t-il une appli qui permet de les voir tous ?

pas mal !!!
arriver a reprocher a AMD un bug (sabotage?) microsoft, et en plus critiquer la reactivite, trop fort !!!

Quelle réactivité ?
 
Ça fait un mois qu'AMD était silencieux sur le sujet alors qu'il lui avait été remonté, alors même que c'est un problème qui aurait du être vu en amont... sauf à penser qu'AMD n'avait pas de Ryzen fonctionnels sous Windows 10 avant mars
 
Il n'y a pas mort d'homme mais mettre en avant la réactivité d'AMD sur ce coup est un peu fort de café.

Alors pour le dossier des 1700/X, nous avions déjà pris sur nous en testant en Core Parking OFF tous les Ryzen, rien a changer ! Sur le 1800X on a les deux résultats avec et sans pour montrer la différence et on avait pris en compte dans nos commentaire les résultats en Core Parking OfF, on le laisse ainsi pour rester cohérent

Vous pouvez être fier, vous aviez super bien diagnostiqué le problème en amont. Et votre dossier était très clair et complet.
 
Merci pour cette actualité !

Clock gating, tout simplement, non?  
 
On peut même s'interroger sur l'utilité de conserver un "Cool'n'Quiet" (autrement dit, jusque la gestion par l'OS) quand il est si "facile" de simplement "oublier" des cycles 100% dynamiquement en fonction de ce qui passe par le décodeur.
 
Par contre, le fait de me traîner avec un A4-5000 m'a permis de voir qu'il existait des cas de code totalement foireux où la fréquence CPU réduite provoque des timeouts. A 1.5GHz ça marche plus ou moins, mais à 800MHz ça ne fonctionne plus du tout, et ça malgré une utilisation CPU rapportée faible. On peut supposer que le P2 élevé a quelque chose à voir avec ce genre de bugs...

Non    
 

 
Microsoft en fournit un en ligne de commande :

Ca écrit la config complète active dans fichier.txt, on peut avec ce soft aussi changer manuellement tous les paramètres. Il existe peut etre un autre logiciel qui fait ca de manière plus intuitive.

Relativement au sushi que je signalais sur mon Kabini, je viens de voir un paramètre pas très encourageant : SUB_INTSTEER, valeur "par défaut".
 
IDLESCALING est désactivé aussi.
 
Franchement difficilement lisible entre le probable mix UNICODE/ASCII du fichier que j'ai eu et les traductions vraiment mauvaises, ceci dit avec un peu de doc une GUI doit pouvoir se faire assez rapidement (mais Windows tolère toujours les manipulations du registre par des apps sorties de nulle part?)

par curiosité, hors Guillaume et la superbe équipe de Hfr, y a t il d autres testeurs tels anandtech qui avaient identifié le soucis du Core Parking des Ryzen, cad en même temps ou avant Hfr?
Est ce que les constructeurs (ici AMD) publient des remerciements lors de tels patchs?
EDIT: le blog d'AMD cite ComputerBase.de qui a publié son article le 14 mars. Guillaume a édité l article Hfr le 12 mars mais en parlais déjà sur le forum des jours auparavant, donc Hfr 1er sur l'affaire?

C'est quoi le scheduler Windows et pourquoi le processeur ne se gère pas tout seul ? Il y bien SenseMI pour gérer ça.

Je n'ai pas lu tous les tests du monde donc je ne sais pas. Nous on a publié notre update pour le Core Parking le 5 mars sinon (un dimanche !) cf ici : http://forum.hardware.fr/hfr/Hardw [...] #t10089809

Le 12 c'est la news récap avec les autres modifs (y compris F1 2016 qui nous a demandé le plus de temps à cause de Denuvo).

Pour les remerciements publics sinon non, AMD ne nous a pas remercié pour toutes les infos qu'on leur a donné, que ce soit sur le Core Parking, ou sur le bug de détection de F1 2016 par exemple, on leur a quand même dit que ça n'était pas très gentil de clamer que c'est AMD qui avait découvert le problème sous F1 dans la Community Update #2  

Nous avons également averti AMD sur le patch de Total War (cf cette news de lundi : http://www.hardware.fr/news/15076/ [...] ryzen.html ), AMD mentionne le patch mais ne dit pas l'avoir découvert, on progresse

Le scheduler de Windows est la partie du noyau qui s'occupe de dispatcher les threads des programmes vers les différents coeurs.

Comme tu as l'air de débuter, un peu de lecture : https://fr.wikipedia.org/wiki/Multit%C3%A2che

Faut être bien assuré pour laisser Windows gérer le car parking

Pour mon ryzen 1700, les performances mono-coeur ont diminué avec ce profil sous cinebench r15. Plus précisément suite à la mise à jour de "W10 anniversary update" vers "w10 creators update" mes performances en stock sous cinbench r15 sont passés de 135 à 147 (mono-coeur mais le multi n'a pas changé). Avec le profil ryzen ou haute performance sans core parking donc, les performances mono-coeur retombent dans les 135. En regardant les fréquences sous Hwmonitor, avec les core parking les 4 premiers cores boost plus souvent à 3.7 ghz qu'avec le profil ryzen ou haute performance d'où le score supérieur en mono-coeur. En multi-coeurs aucun changement ils sont tous à 3.2 ghz quelque soit le profil.

 
oui, je me souviens aussi avoir vu tes msg bien avant l update de l article.
C est pas très sympa de la part d'AMD tout cela..
Enfin tu peux tjs postuler pour un job de testeur en interne chez AMD si cela te tente

 
Je bosse dans l'IT, et quand il y a un bug dans un developpement sous Oracle, je ne demande pas / n'attends pas qu'Oracle sorte un patche pour le corriger. c'est a Microsoft de fixer un bug windows, pas a AMD.
Et 1 mois pour sortir un fix, a ce niveau, quand microsoft ne donne pas suite, c'est etre tres reactif.

Fabricants de matériels et de logiciels sont censés travailler main dans la main, c'est la première fois que AMD sort un processeur pourvu de SMT, on ne sait rien de leur échange avec Microsoft. Dire que c'est la exclusivement la faute de Microsoft si ces premiers processeurs AMD SMT n'ont pas le Core Parking réglés de la même manière par défaut c'est peut-être aller un peu vite en besogne, non ?

D'autant que si tu pars du principe que AMD lui-même n'a l'info que depuis un mois puisque tu prends cette date pour parler de réactivité, alors qu'ils ont des Ryzen fonctionnels depuis +/- un an, comment Microsoft aurait pu le voir avant AMD ?

comme l article le dit lui même, on aurait juste attendu qu AMD travaille plus étroitement avec Microsoft pour que cela soit Microsoft qui sorte le patch.
Mais cela est peut etre aussi en cours, et que cela dure encore plus longtemps, donc le patch AMD est là en attendant un hypothétique patch Microsoft (peut etre inclus seulement dans la prochaine build windows 10 rs3)!

je prends le train en marche. Je viens d'installer le patch pour mon 1700x. Y a un truc à faire juste après?  
je lis ça

c'est à faire??
Merci de vos réponses

Non ! Ca ne sert a rien au contraire, cf article.

Bah je comprend pas du coup.
J'ai fais cette manip' car sans cela le Vcore reste aux environs de 1.2V en permanence (car puissance mini du CPU fixé à 90% par défaut). Alors que si je réduit la gestion de l'alimentation minimale à 5%, là le Vcore tombe à 0.8V en cas d’inactivité. Donc où est l'inutilité ? J'ai lu l'article mais je comprend pas..
edit : j'ai rien OC, tension du CPU réglé par défaut en automatique. (1700x)

Cf l'article, les logiciels de monitoring n'ont pas accès à la lecture des couples fréquences/tension (fid/vid) utilisés lorsque c'est le CPU (et non le scheduler de Windows) qui gère les modes d'économies d'énergie. Tout ce que tu fais en réglant à 5%; c'est retarder le moment ou le CPU passe dans le mode d'économie d'énergie le plus efficace (géré par le CPU).

Dans dans le mode d'énergie de AMD Balanced Ryzen, la valeure lu CPU VCore est donc maintenant fausse c'est ça que tu me dis ? Car dans ce mode c'est le CPU qui gère les modes eco et non pas le scheduler Windows ? J'ai BON ?
Désolé mais j'ai bien lu l'article et j'ai eu du mal à comprendre, je suis dur de la comprenette...

C'est du coup perturbant de voir un Vcore à 1.2V en permanence XD

Donc on laisse les valeurs par défaut, qui sont donc 0% pour la fréquence maximale du processeurs, 90% pour l'état minimal du processeur, et 100% pour l'état maximal du processeur.  
On est d'accord?

Je les installer et je vois pourtant bien les fréquence baissé et remonté quand cela est nécessaire que ce soit sous cpu-z ou autre logiciel de monitoring, ainsi que la tension qui bouge également.
Ryzen 1700 et msi b350
Si je laisse par défaut au lieu de retombée à 1.5 ghz, cela reste à 2.2 ghz, si je met 5% pour l'état minimal du processeur, la je retombe à 1.5 ghz.

La lecture de la fréquence et du VID n'est pas possible lors des modes d'économies d'énergies gérés par le CPU, OUI.

On ne trifouille pas le profil d'AMD non ! Si vous voulez faire simple, vous désactivez juste le Core Parking via une des méthodes indiquées dans l'article du 1800X (la plus simple a mon avis, installer Park Control, régler sur desactiver en AC, puis désinstaller Park Control), soit vous utilisez le profil d'AMD tel quel.

Encore une fois, la fréquence et le VID ne sont pas lisibles par les logiciels comme CPU-Z, HWiNFO64, et autres, lorsque c'est le processeur qui gère les modes d'économie d'énergie (et non le scheduler Windows).

Quand on voit 1.5 GHz en mode balanced, on n'est pas vraiment non plus a 1.5 GHz. C'est juste que le seuil "avant" de rendre la main a la gestion du CPU est plus bas, donc on se rassure en disant "ha, c'est plus bas". En pratique, non, ca ne change rien ! Le coeur est au pire à 400 MHz ou éteint, mais ça, ce n'est pas détectable parce qu'AMD ne le permet pas.

Je sais c'est compliqué et tordu, perso je n'y peu pas grand chose. AMD a fait le choix de vouloir mettre en avant a tout prix ce mode d'économie d'énergie qui a un impact limité sur les performances et la conso en mode desktop, tout en ne voulant pas permettre aux logiciels de monitoring de ne serait-ce que détecter le moment ou le CPU prend la main sur la gestion de l'état des cores (P-States vers les modes jusqu'au CC6).

Si AMD avait été plus transparent avec les développeurs de ces logiciels le doute n'existerait pas, mais la logique chez AMD autour de cette question est discutable, pour ne pas dire autre chose.

Ah bais merci pour toute ces infos, j'ai donc remit à 90% juste désactivé la mise en veille des disques durs.
La moindre modif ne désactive pas le profil d'amd?

Non on modifie toujours le profil actif ! AMD ne fait que créer un nouveau profil en pratique (vs notre méthode qui change le profil actif en cours sans créer de nouveau profil). J'espère que c'est enfin plus clair