Actualité informatique du 22-01-2018

MAJ 22/01 : Intel a annoncé  avoir possiblement trouvé la cause des plantages sur "Haswell et Broadwell" (quid des autres, cf notre article ci dessous ou Intel avait indiqué la semaine dernière que ce problème n'était pas limité qu'a ces deux plateformes ! Est-ce un errement de plus dans la communication ou est ce que le bug n'est corrigé spécifiquement que sur ces deux plateformes ?) provoqués par les microcode rendus disponibles dans la précipitation avec les BIOS en début de mois. Le constructeur indique que ces nouveaux microcode sont en phase de test chez ses "gros clients" et recommande aux utilisateurs "moins gros" d'attendre la version finale de ce microcode pour mettre à jour leur BIOS. Aucune date n'est donnée pour cette mise à disponibilité pour les partenaires d'Intel, malheureusement. On restera donc prudents et nous vous tiendrons au courant dans les jours à venir des derniers développements !

Un nouveau communiqué de presse publié par Intel aujourd'hui  évoque les problèmes de stabilités rencontrés avec sa dernière mise à jour de microcode. Intel a, on s'en rappelle, fourni une mise à jour du microcode pour ses architectures les plus récentes il y a une dizaine de jours pour proposer des contre mesures envers la variante 2 de Spectre (qui doivent s'accompagner de modifications côté OS et compilateurs).

Intel continue d'indiquer qu'il a proposé un microcode pour "90% des CPU Intel introduits ces cinq dernières années" comme s'y était engagé son CEO à l'ouverture du CES. Le communiqué indique cependant qu'Intel a reproduit les problèmes de stabilités rapportés par ses clients, et que contrairement à ce qui était indiqué la semaine dernière, ces problèmes ne sont pas limités à Broadwell et Haswell .

Ivy Bridge, Sandy Bridge et les dérivés de Skylake sont (sans surprise) également touchés par les problèmes de stabilité. Intel indique avoir réussi a reproduire ce problème en interne et qu'il fournira une version beta du microcode pour validation à ses (gros) clients la semaine prochaine. Sur son site security center , le constructeur reprend le même discours demandant à ses clients de déployer la prochaine beta "dans l'attente d'une résolution définitive du problème". On ne sait pas si ces versions beta seront également rendues disponibles auprès du grand public directement.

En ce qui concerne la question de l'impact sur les performances, le communiqué du jour d'Intel regarde la question côté serveur et se félicite que, sur des benchmarks purement arithmétiques comme Linpack, l'impact soit sous les 2%. Par contre en ce qui concerne les scénarios où les charges d'I/O disques sont lourdes, le constructeur reconnaît qu'une baisse de 20% de performances (si l'on était limité par le CPU, et une augmentation de la charge CPU de 20% dans le cas inverse) est constatée ce qui confirme ce que l'on a pu voir jusqu'ici dans de tels scénarios testés de manière indépendante.

Dans le cas des situations ou les I/O sont limitées, c'est le patch KPTI déployé pour la faille Meltdown qui est en cause. D'autres scénarios côté serveur (avec de gros volumes I/O réseaux par exemple) voient également des pertes de performances nettes.

Côté "client", Intel avait publié en fin de semaine dernière quelques benchmarks . Aucune perte de performance n'était notée sous 3D Mark "Sky Diver" même si dans ce cas, Intel a réalisé ses tests avec ses IGP, une situation excessivement favorable étant donné qu'on est très loin d'être limité par le CPU avec un IGP dans les jeux/benchmarks 3D !

Sous PC Mark 10 et Bapco Sysmark 2014, Intel note des baisses de performances de quelques pourcents, entre 3 et 5% dans la majorité des cas (on note une grande variabilité dans les benchs d'Intel !).

Un test se distingue assez fortement des autres cependant, le test "Responsiveness" (RE) de Sysmark. Dans son "Whitepaper", Bapco décrit ce test de la manière suivante :

Responsiveness

The Responsiveness scenario models usages where the ability of the system to react quickly to the user's input impacts the experience of using the system (i.e. - user's want to feel like the system responds smoothly and quickly). Some workloads include: application launches, file launches, web browsing with multiple tabs, multi-tasking, file copying, photo manipulation, file encryption and compression, and background application installation.

Là encore sans surprise, ce sont des tâches où les I/O et plus généralement les interactions applications/OS sont les plus élevées (le patch "KPTI" et ses équivalents tels qu'implémentés sur d'autres OS rajoutent un coût important aux syscall et aux changements de contextes applicatifs/OS).

Si la perte de performances est en général au dessus de 10%, sur un Skylake 6700K, elle monte a 21% sous Windows 10 avec un SSD ce qui est tout sauf négligeable. La même configuration sous Windows 7 ne perdrait que 11%. Si des différences entre les OS peuvent expliquer l'écart, on restera assez prudents étant donné la variabilité que l'on note dans des configurations qui semblent proches.

L'autre série de benchs où une chute de performances notable est relevée est WebXPRT qui teste des applications Web (sous Edge et IE dans les tests d'Intel) . La perte est autour de 10% sur un 6700K sur ce scénario.

On terminera rapidement sur ce sujet pour aujourd'hui en évoquant nos confrères de Phoronix qui ont testé le patch Retpoline (l'autre patch, pour Spectre) sur les CPU AMD  et les CPU Intel . Les impacts diffèrent, mais les patchs diffèrent également, le patch Intel réclamant des changements supplémentaires  sur Skylake et ses dérivés par exemple.

L'impact pratique de Retpoline sur les performances est plus réduit que le patch KPTI comme supposé, même si les patchs sont encore très jeunes et que les microcode sur lesquels ils reposent sont, au moins chez Intel, en version beta. AMD a commencé a fournir ces patchs qui ont été distribués par certaines distributions (Redhat et Suse en tête, Ubuntu proposera ses patchs retpoline et les mises à jour de firmware AMD lundi prochain aux dernières nouvelles).