fréquence / température du CPU, bizarrerie

[pehache]

Bonjour,

Suite aux discussions sur le throttling CPU des nouveaux MBP à cause d'une dissipation thermique insuffisante, par curiosité j'ai voulu voir comment le CPU de mon iMac 2011 tenait la charge, avec l'outil Intel Power Gadget indiqué par @Fromgardens.

Mon CPU est un core i5 2400S 2.5GHz, turbo-boost 3.3GHz, et avec une TDP de 65W : https://ark.intel.com/fr/products/52208/Intel-Core-i5-2400S-Processor-6M-Cache-up-to-3_30-GHz

J'ai lancé un encodage avec Handbrake, et au bout d'un moment la température CPU se stabilise juste en dessous de 80°C, et la fréquence reste parfaitement constante à 2.6GHz : http://prntscr.com/k97ht1

Par contre deux bizarreries :

• La conso rapportée ne dépasse pas 32W, pour 65W de TDP annoncée. Est-ce que c'est parce que les 65W incluent la partie CG intégrée, qui n'est ici pas du tout utilisée ?
• Même à froid et sur un seul thread, la fréquence ne monte jamais au dessus de 2.6GHz, comme si le mode turbo-boost n'était jamais utilisé : comment se fait-il ?

 

[Sethenès]

J'essaie une réponse de "bon sens", comme il s'agit d'un encodage (donc avec j'imagine, un "input" et un "output" sur disque) rien ne dit que les autres sous-systèmes tiennent la cadence (disque > bus > cache > CPU > cache > bus > disque).

D'autre part, j'avais fait pas mal de tests avec le P4 3,06, le premier cpu d'Intel à être équipé du multithreading (mais la machine n'avait toujours qu'un seul core). Il fallait vraiment envoyer deux processus très différent au CPU pour que la vitesse des deux processus soit la même que celle d'un des deux processus seuls (par exemple, un "gros" calcul avec des nombres en virgules flottante et en // un gros calcul sur des nombres entier). Deux calculs trop sembles (nombres entiers) demandait entre 1,5 et 1,7x le temps d'un seul calcul pour s'effectuer. Mais évidemment, ceci se voit très vite actuellement. Il suffit de surveiller la charge des unités logique. Il faut que tous soient au max pour être certains que l'HT est utilisé au maximum de ses capacités.

Il existe un soft, appelé CPU burner (qui est de mémoire une partie de "Fur mark" qui teste plutôt la partie graphique). Ce soft / ces softs sont spécialement conçus pour faire chauffer le CPU / GPU.

 

[pehache]

il y a 28 minutes, Sethenès a dit :

J'essaie une réponse de "bon sens", comme il s'agit d'un encodage (donc avec j'imagine, un "input" et un "output" sur disque) rien ne dit que les autres sous-systèmes tiennent la cadence (disque > bus > cache > CPU > cache > bus > disque).

En pratique il me semble que la complexité des opérations d'encodage telles que h264 les rend CPU bound, ce qui garantit que le CPU est utilisé pas loin du max de sa capacité. Dans le doute je referai l'essai avec un exemple canonique de type y=ax+b en boucle...

 

il y a 32 minutes, Sethenès a dit :

D'autre part, j'avais fait pas mal de tests avec le P4 3,06, le premier cpu d'Intel à être équipé du multithreading (mais la machine n'avait toujours qu'un seul core). Il fallait vraiment envoyer deux processus très différent au CPU pour que la vitesse des deux processus soit la même que celle d'un des deux processus seuls

Là je crois que tu confonds avec l'hyperthreading (coeurs logiques). Mon CPU ne fait pas d'hyperthreading.

[pehache]

Il y a 2 heures, pehache a dit :

Dans le doute je referai l'essai avec un exemple canonique de type y=ax+b en boucle...

Alors là avec 4 process lancés faisant ce calcul tout simple, le CPU ne consomme que 24W... ?

[Sethenès]

Il y a 3 heures, pehache a dit :

En pratique il me semble que la complexité des opérations d'encodage telles que h264 les rend CPU bound, ce qui garantit que le CPU est utilisé pas loin du max de sa capacité. Dans le doute je referai l'essai avec un exemple canonique de type y=ax+b en boucle...

 

Là je crois que tu confonds avec l'hyperthreading (coeurs logiques). Mon CPU ne fait pas d'hyperthreading.

Oui, oui, c'est bien un lapsus, je parlais de l'hyperthreading.

Et pour le test dont tu parlais, il faut quand même pas mal ruser car les compilateurs sont devenus extrêmement malins.

Parfois, en multipliant les boucles imbriqués, etc, le temps de calcul n'était pas significativement allongé. Et dans certains cas, je n'ai pas trouvé d'explication. Dans d'autre, en compilant et en générant un fichier ASM, je voyais que certains registres étaient assignés en lieu et place de variable classique ou ce genre de chose.

[pehache]

il y a 17 minutes, Sethenès a dit :

Dans d'autre, en compilant et en générant un fichier ASM, je voyais que certains registres étaient assignés en lieu et place de variable classique ou ce genre de chose.

A la limite tant mieux. Si le compilo évite de recourir à des lectures/écritures en mémoire, ça fait autant de temps consacré en plus au calcul dans le CPU.

[Sethenès]

il y a 7 minutes, pehache a dit :

A la limite tant mieux. Si le compilo évite de recourir à des lectures/écritures en mémoire, ça fait autant de temps consacré en plus au calcul dans le CPU.

Oui, certes. Mais si les calculs sont trop prévisibles, le compilateur les simplifie. Je viens de regarder et j'ai trouvé un bout de code en C++ qui date de 1994 où je faisais déjà ce genre de chose. Et d'expérience, je sais qu'on ne peut pas saturer un CPU avec ce genre de test simpliste. C'est d'ailleurs pour ça, que j'ai utilisé CPU burn.

[Sethenès]

Et d'ailleurs, tes tests le confirme.

Modifié 21 juillet 2018 par Sethenès

[pehache]

Que le compilo optimise les calculs ne me parait pas être un problème, le CPU fait moins d'opérations au total mais il en fait toujours autant par unité de temps.

Sinon j'ai téléchargé un petit utilitaire "Turbo Boost Switcher", qui permet d'activer/désactiver manuellement le turbo-boost

Avec 1 coeur occupé, TB activé : conso 17W, fréquence affichée 2.6GHz
Avec 1 coeur occupé, TB désactivé : conso 12W, fréquence affichée 2.5GHz
Avec 4 coeurs occupés, TB activé : conso 30W, fréquence affichée 2.6GHz
Avec 4 coeurs occupés, TB désactivé : conso 27W, fréquence affichée 2.5GHz

Curieux... La fréquence sans TB de 2.5GHz est bien la fréquence nominale du CPU. Mais le TB ne la fait passer qu'à 2.6 au lieu de 3.3 en théorie... A moins que Intel Power Gadget ne rapporte pas bien la fréquence.
 

 

 

[Sethenès]

Une limitation dans le bios de la machine ?

Comme je l'ai déjà expliqué, j'ai travaillé pendant plus de 20 ans chez un constructeur (PC, Serveur, Mainframe, etc.).

Lors de la sortie d'un modèle particulier de PC (tablet-convertible), certains collègues qui en étaient équipés se sont plaint d'une surchauffe anormale (la machine leur brûlait littéralement les cuisses). Après quelques semaines un "correctif" a été distribué (patch du bios).

Par la suite, j'en ai discuté avec l'un des possesseurs. Je lui ai demandé si à son avis, ils avaient juste réduit la fréquence maximum et il a acquiescé. Le PC était devenu plus lent.

[pehache]

C'est à se demander...

Fréquence de base 2.5GHz, TB théorique 3.3GHz (+32%), TB rapporté dans l'outil Intel 2.6GHz (+4%) 

Calcul perso sur 1 coeur : sans TB 5.1s, avec TB 4.2 (+16%)
Geekbench sur 1 coeur : sans TB 2633, avec TB 3072  (+16%)
Geekbench sur 4 coeurs : sans TB 7620, avec TB 8126 (+8%)

Il n'y a rien qui colle. Je pense que l'outil Intel rapporte mal la fréquence en TB car l'accélération constatée va largement au-delà de 4%. Par contre elle est quand même 2 fois moindre que l'accélération théorique.

[Fromgardens]

J'ai fait un essai avec mon MBP 15 mi 2012, c'est un i7 3615QM TDP 45W - 2.3GHz TB 3.3 GHz.

J'ai lancé un encodage Handbrake, il reste à 3.1 GHz pendant une minute environ (un peu en dessous des 3.3 max en TB) puis oscille entre 3 et 3.1 car un peu au dessus de 100°.

https://prnt.sc/ke6fq1

Il aurait peut-être besoin d'un petit changement de pâte thermique mais ça me parait normal comme valeurs. En tout cas la différence base/TB est bien visible.

Je ne comprends pas trop pourquoi l'iMac ne dépasse pas les 2.6 surtout si il reste à 80°…

L'iMac 2011 n'avait pas de problèmes de GPU qui surchauffent comme sur les MBP 2011 ? Apple a peut-être limité la fréquence à 2.6 pour éviter une surchauffe CPU+GPU ?