AMD Ryzen 5 1600X, 1600, 1500X et 1400 en test

Tags : AM4; AMD; Ryzen; Zen;
Publié le 11/04/2017 par
Imprimer

AMD l'avait annoncé lui même par le biais de son blog, le lancement des Ryzen 5 serait accompagné d'une nouvelle version de l'AGESA 1.0.0.4 qui apporterait plusieurs modifications :

  • Une réduction de la latence DRAM d'environ 6ns
  • La correction d'un crash lié à une séquence de code FMA3 "inhabituelle"
  • La correction de la fréquence rapportée comme incorrecte après une sortie de veille en OC

AMD s'est permis une petite simplification en utilisant le terme d'AGESA pour parler de ces modifications. En pratique, AMD fournit à tous les constructeurs de cartes mères trois firmwares indépendants qu'ils intègrent dans leurs BIOS :

  • l'AGESA : il s'agit du code qui permet entre autre l'initialisation du processeur et de la mémoire
  • le microcode : il s'agit du "firmware" du processeur qui permet de patcher d'éventuels bugs (comme celui du FMA3). En pratique, ce firmware est appliqué à chaque fois au processeur par le BIOS lors du démarrage de la machine
  • le SMU : il s'agit du firmware qui regroupe la gestion des diverses sondes de températures de tensions, ou d'énergie

Nous avons traqué ces dernières semaines avec l'aide de certains d'entre vous sur notre forum (nous vous en remercions !) les diverses versions de ces firmwares, que l'on peut lire via des outils comme les excellents HWiNFO64 et Aida64 :


[ AGESA ]  [ microcode/SMU ]  

On retrouve dans les tous derniers BIOS en date de nouvelles versions pour ces trois composants :

  • AGESA : 1.0.0.4a
  • microcode : 800111C
  • SMU : 25.70.0

AMD nous a confirmé que le microcode 800111C apporte bien le correctif pour le bug du FMA3. L'AGESA 1.0.0.4a (que vous pourrez retrouver également sous la notation 1.0.0.3a chez certains constructeurs comme Gigabyte) apporte de son côté l'amélioration de latence. Nous ne savons pas ce qu'apporte la mise à jour du SMU, elle ne semble pas corriger des bugs existants comme le fait que l'on se retrouve parfois avec des lectures de tensions (plus précisément, de VID) bloquées à 1.55V par exemple.

Un gain de latence...

Nous avons donc mesuré les latences avec ce nouvel AGESA 1.0.0.4a pour voir si le gain tant attendu était là :


Oui, il est là ! 6ns peut sembler faible par rapport aux chiffres de latences annoncés qui restent particulièrement élevés (vous pouvez vous reporter à notre article sur la mémoire pour plus de détails), mais un tel gain est tout sauf négligeable !

En soit, 6ns représente l'équivalent de passer d'une mémoire CL16 à une mémoire CL12, soit un saut massif qui peut apporter, selon notre article, entre trois et cinq pourcents de performances dans les applications limitées par la mémoire (c'est le cas par exemple de 7-Zip) et près de 4% dans les jeux.

On est tout de même surpris de la manière dont cette valeur scale. Si l'on a environ 5,7ns de différence en DDR4-2400, le gain ne tombe qu'a 4.8ns en DDR4-3200, ce qui est assez curieux !

...très relatif

Nous avons donc voulu mesurer l'écart de performances pratique obtenu. Par souci de temps (nous n'avons obtenu ce BIOS que vendredi dernier, nous remercions Asus qui nous a fourni une version bêta pour notre carte mère X370 de test), nous nous sommes portés sur le R7 1700 pour effectuer la comparaison :


Nous vous épargnerons le graphique de jeux, les performances sont là aussi strictement identiques entre les deux versions de l'AGESA... Devant cet illogisme nous avons effectué de multiples vérifications :

  • Effectuer de nouveau le test sur une autre carte mère (Gigabyte AX370 Gaming 5 en BIOS F5J)
  • Regarder les performances avec deux barrettes mémoires uniquement en DDR4-2400
  • Regarder les performances avec deux barrettes mémoires uniquement en DDR4-3200

Dans tous les cas le résultat est sans appel :il n'y a strictement aucune différence de performances. Nous avons donc contacté AMD qui a confirmé la chose, il ne semble pas y avoir de différence de performance lié à ce gain de latence obtenu sous Aida64.

Cela ne veut pas dire qu'il n'y a pas de gains potentiels apportés par ces BIOS, et c'est ici que l'histoire se complique, pour nous, et pour AMD.

Deux changements accompagnent ces BIOS, le premier concerne le DRAM Gear Down mode. Lorsqu'il est actif, passé des timings de 2666, certains timings mémoires sont relâchés, notamment les commandes qui passent en mode 2T au lieu de 1T. La seconde est baptisée BankGroupSwap, et au-delà du nom nous n'avons pas d'explication spécifique sur son rôle à vous donner pour l'instant.

De ce que nous avons pu voir, le BIOS 5704 avec lequel nous avions effectué nos tests de Ryzen 7 disposait déjà du DRAM Gear Down Mode désactivé, expliquant l'absence de gain. Ce n'était pas le cas d'autres BIOS publics distribués par les constructeurs de cartes mères, nous y reviendrons. Le second paramètre est une nouveauté introduite dans les derniers BIOS, elle ne fonctionne cependant qu'avec deux barrettes mémoires, ce qui limite son intérêt pour nos tests (nous effectuons notre protocole de test avec quatre barrettes mémoires) et veut qu'elle soit désactivée par défaut.

De fait, même avec deux barrettes mémoires nous n'avions donc pas noté de gain sur notre Crosshair VI Hero de test.

Nous parlions un peu plus tôt du fait que beaucoup de BIOS publics avaient le DRAM Gear Down Mode actif, si c'est le cas, c'est pour une bonne raison.

Encore une histoire de compatibilité ?

Ce qui nous a été dit par les différents constructeurs que nous avons interrogés, c'est que la question de la compatibilité mémoire avec Ryzen est assez complexe et que ce nouvel AGESA n'arrange rien. Certains modules mémoires ont besoin impérativement, sur Ryzen tout du moins, que le DRAM Gear Down Mode soit désactivé pour pouvoir monter en fréquence, à l'inverse certains modules peuvent profiter de ce mode pour gagner un peu en performance en restant en 1T (un gain qu'on estime d'un peu plus de 1%).

Aujourd'hui, l'AGESA d'AMD ne permet pas aux fabricants de BIOS de proposer simplement le choix 1T/2T (ce serait prévu pour une prochaine version), ce qui oblige les constructeurs à proposer des BIOS avec l'un ou l'autre des choix. On peut donc comprendre leur position : la compatibilité prime sur un minuscule gain de performance pour les BIOS publics.

En pratique nous avons pu vérifier que la compatibilité était effectivement moins bonne avec ces BIOS avec des modules équipés de puces Hynix. Ainsi, nos quatre barrettes de mémoire DDR4 Ripjaws 4 utilisées pour nos tests des Ryzen 7 ont refusé de booter sur deux des trois cartes mères en AGESA 1.0.0.4a que nous avons pu tester. La troisième (la Crosshair VI Hero) démarre bel et bien ces barrettes mais leur fonctionnement a été accompagné de plantage. De la même manière, le kit DDR4-2400 Dual ranked qui ne fonctionnait dans notre article sur la mémoire qu'en DDR4-2133 sur Ryzen ne tient cette fois ci plus à ce timing.

Tout n'est pas cependant noir puisqu'à l'inverse, les modules équipés de puces Samsung tendent à monter un peu plus haut en fréquence si l'on s'en réfère aux retours d'utilisateurs et des constructeurs de cartes mères. De notre côté nous n'avons pas vu d'amélioration sur notre Crosshair VI Hero, il faut dire que sur cette dernière les modules Samsung 2x8 Go que nous avions sous la main tenaient déjà en DDR4-3200. Nous n'avons pas noté d'avancée sur notre kit Ripjaws V. équipé de puces Samsung, il reste limité en DDR4-2666 dans nos essais.

Dans tous les cas, AMD a placé les constructeurs de cartes mères dans une position délicate. En poussant à tout prix pour le lancement des Ryzen 5 ce nouvel AGESA, AMD a voulu mettre en avant des avancées de compatibilité. Si elles sont réelles pour certains, elles sont contre productives pour d'autres ce qui fait que l'on a détecté chez les constructeurs que nous avons consulté une certaine prudence sur la disponibilité de ces BIOS. En pratique, on vous conseillera la prudence. Si vous souhaitez essayer ces nouveaux BIOS, il pourra être nécessaire de revenir en arrière si le résultat n'est pas probant pour votre configuration. Si l'on peut accepter cela de BIOS beta, on ne peut pas s'empecher de penser que tout cela est inutilement complexe : ce travail aurait du être effectué en amont par AMD, et non par ses clients qui se retrouvent propulsés au rang de beta testeurs. Un mois après le lancement de Ryzen, on aurait pu espérer que la situation se soit simplifiée, en pratique il n'en est donc rien, et c'est fort dommage !

Et la latence, dans tout cela ?

Reste que sur la question du gain de latence, AMD ne nous a offert à l'heure où nous écrivons ces lignes aucune réponse. S'agit il d'une optimisation spécifique pour les algorithmes utilisés par les logiciels comme Aida64 pour mesurer là latence ? Une interprétation généreuse dirait qu'AMD a peut être ramené les valeurs dans ces logiciels à des valeurs plus proches de la réalité. Le fait que ce changement n'ait pas d'impact réel sur les performances, et qu'AMD ait envoyé à la presse des cartes mères équipées de BIOS AGESA 1.0.0.4a configurés avec les deux options sus mentionnées modifiées nous fait douter de notre générosité, on l'avoue !

La question de la latence des caches est un autre sujet qui fait débat et nous avons donc voulu regarder ce qui se passe sur ces quatre processeurs. Pour rappel, le Ryzen 5 1400 ne dispose que de 8 Mo de cache L3 (4 + 4) tandis que les autres disposent de 16 Mo (8 + 8). Nous utilisons le benchmark avancé de latence d'Aida64 qui mesure la latence en fonction de la taille des accès mémoires. Les mesures sont effectuées à la fréquence par défaut des puces :


Il n'y a pas trop de question à se poser en ce qui concerne le L1, on voit une latence très faible autour d'1ns pour tous les modèles, tandis que le L2 est entre 4 et 5ns en fonction de la fréquence des puces. Le comportement du L3 reste troublant et sur ce point nous n'avons toujours pas d'explication concrète de ce qu'il se passe.

Pour rappel, les benchs de latence sont monothreadés. Le design particulier de Ryzen fait qu'un thread qui est attaché à un coeur dans un CCX ne pourra utiliser que le cache L3 du CCX (le L3 est un cache dit "victime", il est rempli des "restes" des données qui sont éjectés des caches L1 et L2... qui ne peuvent être remplis que par des coeurs à l'interieur du CCX donné). En pratique on s'attend donc à voir un comportement comme si le cache était de 4 Mo sur le Ryzen 5 1400, et de 8 Mo sur les autres.

Dans le cas du Ryzen 5 1400, on voit que dès 3 Mo la valeur de la latence monte au-dessus de ce qui est attendu, ce qui signifie que l'on est déjà arrivé en mémoire centrale pour au moins une partie des accès. A 4 Mo on est largement dedans et au-delà on voit une latence conforme à des accès mémoires.

C'est le cas des trois autres qui nous intrigue puisque arrivé à 6 Mo, on est assez largement dans les accès en RAM pour le R5 1600 et surtout le 1500X, ce qui n'est pas le cas du 1600X qui est le seul à avoir un comportement « normal » et conforme à ce que l'on mesure avec d'autres processeurs.

Nous n'avons toujours pas d'explication sur ce point de la part d'AMD qui se contente de dire que les logiciels peuvent ne pas détecter correctement la taille des caches (ce n'est pas le cas de ce bench), ou réaliser par erreur des accès en mémoire centrale. C'est justement ce que l'on constate depuis un moment, et ce comportement qui semble assez variable n'est pas très logique.

Tout au plus, nous pouvons penser que cela est lié au fait qu'AMD décrive son cache L3 comme de type mostly exclusive, laissant penser qu'une partie du L3 puisse être utilisé à d'autres fins. En soit ce n'est pas anormal, mais le fait que cette proportion ne soit jamais fixe nous interroge une fois de plus.

Vos réactions

Top articles