Une clause de licence sur l'application des derniers patches Intel de microcode relatifs au failles L1TF empêche les utilisateurs de faire des comparaisons ou des benchmarks. La baisse de performance doit vraiment être importante...
Liens:
 
https://perens.com/2018/08/22/new-i [...] cceptable/
https://www.theregister.co.uk/2018/ [...] h_licence/

faut pas s'inquieter y'aura des bios customs qui feront sauter ça

Bah voyons, c'est pas du tout abusif comme clause ça, m'étonnerait même que ce soit légal

Intéressant mais ça aurait plus eu sa place ici: https://forum.hardware.fr/hfr/Hardw [...] ujet-1.htm
 
Dommage; on pourrait continuer à "faire vivre le site" à travers le forum mais bon...

Plop'
 
Ça va mal finir, je sens déjà le procès en class action venir gros comme une maison
 
Blague à part, +1 avec Zerist, c'est même plus une clause abusive la, c'est du "damage control" (de l'enfumage pour les puristes) en règle, si ça n'est pas autre chose.

merci de l'infos.
On en parle également ici :
https://www.developpez.com/actu/220 [...] ux-Debian/
 
Mon prochain cpu sera d'AMD, à cause du comportement exécrable d'Intel.

Re,

EDIT: C'est à prendre avec des PINCETTES en tout cas, tant qu'on n'en saura pas plus sur cette "tempête dans un verre d'eau"

Bonne nouvelle, Intel ont levé les restrictions de Benchmark Avant/Après (extrait tiré de TheRegister) :

Source de l'article (en Anglais) :
https://www.theregister.co.uk/2018/ [...] e_license/

-----------------------------------------------------------------------------------------------------------------

J'ai aussi trouvé un article en français (de Tom's Hardware France) traitant de la débâcle de la license du nouveau microcode :
https://www.tomshardware.fr/article [...] 68298.html

Voilà un extrait :

Encore une tempête dans un verre d'eau en somme.

la question est : est-ce que s'il y avait pas eu de tempête dans le verre d'eau, intel aurait changé sa license ?
et quand ils disent petite erreur, faut le faire écrire une phrase complète c'est pas comme s'ils inversaient un mot avec un autre

Ouais erreur mon c**, ils ont essayé en se disant qu'avec un peu de chance ça passerait inaperçu, ils se sont fait choper donc ils minimisent

moins d'une dizaine d'heures pour changer une CGU...Il est probable que ça soit une coquille.  Maintenant seul les benchs donneront leur vérité...

Marrant de défendre des méga entreprises et les faire passer pour des plaisantins qui font des erreurs alors que tout est planifié , surveillé etc
Je vois pas bien le rapport avec les benchs.  
La phrase n'est pas tombée là par hasard. Ce n'est pas une erreur de copier-coller. Et pas non plus la faute à un stagiaire.

La CGU en question est au sujet de l'interdiction de benchmarker la maj du microcode...Voila le rapport...
C'est possible qu'ils se soient fait prendre le doigt dans le pot de confiture...En même temps vu leur vitesse de réaction c'est aussi possible que leurs armées d'avocats aient préparé plusieurs versions de la maj des CGU et que le stagiaire se soit planté de version... ^^.
c'est ce que je voulais signifier..
Ou comme le dit mogana, qu'ils aient tenté une petite entourloupe...Mais pourquoi Intel s'excuse aussi vite alors? l'erreur humaine reste possible.
De toute façon, à moins d'être D.I. dans un entreprise ciblée par des hackers de haute volée, osef du microcode...J'ai mis à jour mon bios par précaution au mois d'avril, je n'ai pas vu de baisse de perf quelconque...Alors tempête dans un verre d'eau...A moins que la prochaine maj dont on parle soit catastrophique pour les performances des CPUS.
Là crois moi je serais le premier à troller...

En même temps ça me paraissait assez suspect qu'Intel disent que c'est une erreur (en même temps vu les procès qu'ils ont pris en pleine poire après le bug Meltdown/Spectre)... Je ne les défend pas du tout, mais bon, reste plus qu'a attendre comment ça va se passer

Edit: corrigé

 
C'est un bug...Pas un scandale...ça fait 20 ans qu'Intel privilégie la perf sur la sécurité, à un moment il faut bien corriger le tir.
 
Sur Windows la correction du bug n'a pas un impact significatif sur les perfs:
https://www.hardware.fr/focus/124/w [...] ances.html
 
Espérons juste que c'est la même sous Linux.
 
Pour rappel AMD est aussi victime des failles de Spectre, simplement ils ont choisi un autre type de communication "regardez ailleurs y a rien à voir", tout en proposant des patchs correctifs "optionnels" ...
 
Tout le monde est dans le même panier...

bien essayé mais ça eu l'effet inverse .....Intel et la COM uhuhu

et encore on connait pas les failles qui sont encore sous NDA... et celles qui vont continuer a être découvertes sur ces CPU passoires..
Le dégagement de Brian le CEO pour relation .... mouarf  
Une façon détournée pour le dégager pour ses erreurs de gestion des CPU au détriment de la sécurité...   sans affoler les investisseurs, la bourse..et mr Michou...

 
T'as réussi à exploiter la faille?
 
Si ne je ne dis pas de conneries t'as pas trop le choix en CPU mainstream,Intel ou AMD... et AMD présente la même faille sous spectre.

 
sur les applis à fort % d'io genre certains serveur c'est pas la même histoire avec meltdown
ensuite spectre c'est du fait même de l'execution OOO, arm et power sont touchés
t'as des gens de la communauté bsd qui vont jusqu'à recommander de désactiver l'hyperthreading sur les procs intel
le truc ici c'est qu'il semble qu'intel ait été un peu trop loin au contraire d'amd, mais l'avenir le confirmera, même si à ce moment ce sera bien loin

T'es pas à la page, les failles Meltdown et maintenant Foreshadow sont spécifiques CPU intel, et les combler plombent les perfs ! Il est même conseillé de désactiver l'hyperthreading sur les procs intel, les gros clients : grosses boites cloud, Azure, Amazon AWS, etc vont apprécier, si si..

http://www.strategie-bourse.com/amd.html
http://www.strategie-bourse.com/intel.html

Quant à spectre il touche tous les CPU les patchs peuvent etrent indolores sur certains CPU..et  sur certains OS.

 
Non mais là ...
 
Il est conseillé de désactiver le SMT sur les CPU AMD aussi   par OpenBSD, s'il te plait. Un peu le too mcuh sécuritaire...
 
https://www.phoronix.com/scan.php?p [...] abling-SMT
 
Et le pire c'est que cette désactivation est plus efficace chez Intel qu'AMD...
 
Ceci dit je n'ai rien rien contre l'un ou l'autre, et ça me fait chier dans les deux cas.    
 
 
 
Quand à tes graphes, à mon âge j'ai déjà connu 2 cracks boursiers majeur dans les NTIC... je n'achète pas d'actions.
MErci quand même

Cette faille impacte la sécurité en virtualisation sur les CPU intel , ceux qui seront le plus impactés par les prochains patchs et microcodes seront les gros clients, Jean-kevin sur fornite n'y verra que du feu ...
https://www.ovh.com/fr/blog/ovh-l1- [...] isclosure/

https://arstechnica.com/gadgets/201 [...] on-attack/

Quant à AMD : https://www.amd.com/en/corporate/security-updates

Çà me fait chier aussi, j'ai aussi des machines intel (laptops). Bien que je ne fais pas ou peu de virtualisation sur ces machines.

 
 
Non mais d'accord, mais voila :
 
"Security oriented BSD operating system OpenBSD is making the move to disable Hyper Threading (HT) on Intel CPUs and more broadly moving to disable SMT (Simultaneous Multi Threading) on other CPUs too"
 
la recommandation date du 19 juin 2018, donc après la seconde couche de révélation de mai 2018...
 
https://www.phoronix.com/scan.php?p [...] abling-SMT
 
 

https://www.mail-archive.com/source [...] 99141.html
 
Leur fond de commerce c'est la sécurité, applications, serveurs sensibles..
Theo, a poussé un coup de gueule surtout car intel ne leur a filé aucun coup de main, ni fournis de doc, démerdez vous tous seul... le microcode helas ne fait pas tout. Pourtant ils se sont empressés d'aider Redmon et les autres..
https://www.blackhat.com/us-18/brie [...] ough-10149
 

 
 
Si les dev Debian n'avaient pas refusés en bloc d’intégrer le dernier microcode contenant la  fumeuse License abusive dans la distro (utilisée par de grands comptes), intel aurai gagné, personne n'aurai tenté le diable de provoquer intel et leur hordes d'avocats en balançant les benchs sur la toile..., la suite on la connait intel a du plier ....  en pretestant une erreur...

 
Ok, possible. ça j'avoue que je n'en sais rien, et Intel n'est pas net dans l'histoire.."Quand c'est flou, y a un loup " - Martine Aubry

 
Sinon pour le SMT tu peux raconter ce que tu veux, selon   openBSD tu dois la désactiver sur AMD aussi. Point barre.
 
Ils disent simplement qu'intel est plus touché par les failles de spectre qu'AMD,  pas qu'AMD est totalement spectre proof...

For now this only works on Intel CPUs
when running OpenBSD/amd64. But we're planning to extend this feature
to CPUs from other vendors and other hardware architectures.
 
Note that SMT doesn't necessarily have a posive effect on performance;
it highly depends on the workload.  In all likelyhood it will actually
slow down most workloads if you have a CPU with more than two cores.
 
Çà dépend des taches et appli de ton serveur.

je pense que tu ne comprends pas l'anglais.  
 
Alors voila la news en français
 
https://www.hardware.fr/focus/124/w [...] ances.html
 
 
"Pour ce qui est de Spectre, AMD estime pour rappel que "des différences entre son architecture [et celle de son concurrent] rend l'exploitation plus complexe" .
 
 
Pour en revenir à ton extrait.
 
Ils disent que l'HT off résout le problème plutôt bien et qu'ils préconisent par extension  le SMT off sur toutes les autres marques de CPU sur toutes les plateforrmes.
Pour faire passer la pilule ils disent que SMT OFF n'a pas d'impact sur les performances, à part en cas de charge haute.
Et même que ça a plutôt tendance à ralentir les perfs SMT ON sur les tâches courantes si t'as un CPU de plus de 2 cores.
 
Sympa, ça fait bien vendre le threadripper /xéon ça
 
Sinon Hyperthreading = SMT , c'est simplement un terme d'intel
 
Je te fais la traduction littérale de ton extrait..

Moi je te parle des failles L1TF  et de la variante 3646 de Foreshadow, pour les serveurs HPC (calcul haute performance) de big data, de workloads fortement multithread, compilations, et toi tu me sort des benchs de jeux.. sur Windows 10......., Meltdown et Spectre... et Publié le 07/02/2018 ................
Bref on parle pas du même sujet..et comme tu sembles tout mélanger, je vais éviter de perdre mon temps à te répondre..

 
Mmmmhhhhh certes...
 
Je te cite  :" T'es pas à la page, les failles Meltdown et maintenant Foreshadow sont spécifiques CPU intel,  et les combler plombent les perfs !"

 
-0.8 à + 5 point de perf après application du patch sous windows...Tu appelles ça "plomber les perfs"?? C'est bien écrit "applicatif", pas jeux.
 
 
" Il est même conseillé de désactiver l'hyperthreading sur les procs intel, les gros clients : grosses boites cloud, Azure, Amazon AWS, etc vont apprécier, si si.."
 
Bah si ils ont des threadrippers ils vont aussi kiffer à mort... La préco est la même..SMT OFF   (sauf que c'est juste pour spectre, pas Meltdown et Foreshadow qui ne concernent qu'Intel).

pour le dernier microcode update, phoronix a testé et rien à signaler, quelques % par ci par là quelquefois, bon à ce rythme 2-3% sur 10 failles et ça fait moins 20-30%
 
https://www.phoronix.com/scan.php?p [...] code&num=3
 
"but it looks like it may have just been an overzealous Intel lawyer who thought it would be a good idea to forbid benchmarking and further lock-down their microcode license...", je sens qu'un avocat doit être mal
 

Quand je disais que c'était une tempête dans un verre d'eau ^^.
 
Sinon on va peut être s'arrêter là pour les failles, hein Monsieur Intel...

Tu oublies TLBleed ... et vi ça commence à faire beaucoup rien que pour intel, on n'est pas près d'en voir la fin..., je ne serai pas surpris que les gros clients migrent vers Epyc..

https://www.zdnet.fr/actualites/tlb [...] 870198.htm
https://www.ginjfo.com/actualites/c [...] d-20180828

Bon bah je prendrais éventuellement un 9700k  pour mon prochain desktop . Au moins ça règlera le problème ^^

Bien d'accord . En espérant que dynamis31 ne m'en voudra pas j'ai pris la liberté de déplacer le topic, même si entre temps Intel a rectifié.

Ils disent en fonction de la charge, pas à haute charge. Et ils ont raison.  
Certes, avec la plupart des bench (et jeux) récents, fortement optimisés pour mettre en avant le multithreading, tu auras des perfs légèrement supérieures avec l'hyperthreading. Mais tu augmentes le throughput au détriment de la latence. Ce qui se traduira en général par plus de FPS, mais aussi plus lag ...
 

La mailing list d'OpenBSD n'a pas la même ligne éditoriale que les magazines d'informatique

 
Je sais bien que le SMT/HT c'est juste un doublement des files d'attentes ^^. Je sais aussi que c'est rarement utile en gaming, à part peut être quelques jeux "vitrine technologique" à la crysis x et pour certains mmo. La littérature gaming anglaise et allemande préconisent le SMT/HT OFF si c'est pour du jeu. Précisément pour les raisons que tu évoques: plus de lag.
Il vaut mieux avoir un fps constant et un poil plus bas qu'un fps plus élevé qui lag
 
Tu prêches un convaincu    
 
Mais bon, comme je me sers aussi de mon PC pour faire de l'applicatif velu (PAO/MAO) je laisse le HT ON pour le moment.  
 
J'ai plus de chance de me faire écraser par un chauffard en traversant la rue ou de me prendre une météorite en pleine poire que de me faire piquer mon numéro de CB lors d'une transaction cryptée sur Internet*.
* Jusqu'à nouvel ordre tout du moins  

The Performance Cost Of Spectre / Meltdown / Foreshadow Mitigations On Linux 4.19
 
https://www.phoronix.com/scan.php?p [...] ions&num=1
 
http://openbenchmarking.org/result [...] &obr_imw=y

ça fait mal quand même sous linux pour le Xéon. EPYC prend un petit coup quand même de temps en temps mais s'en tire mieux.
 
On va dire que c'est un réajustement sécurité/performance assez âpre ^^.