J'ai maintenant un Prodesk 600 G3 mini. Et comme tout bon geek, je l'ai upgradé à fond (ou presque). Mais ça a été plus folko que je pensais... 😅

J'ai acheté de la RAM, 8 Go. Je n'ai pas remplacé la RAM existante, elle marche bien, et c'est de la Hynix.

J'ai acheté un Core i5 7500T, vrai quad-core, basse consommation. Le Core i3 6100T d'origine est dual-core hyperthreading, mais avec fréquence plus élevée.

J'ai aussi trouvé un module HDMI pour remplacer le module série. C'est la partie la plus simple, juste enlever 2 vis, changer le module, revisser, fini, j'ai un port HDMI. 😉

La RAM, facile aussi, juste à clipser sur l'emplacement vide. Le processeur aussi, enlever le radiateur, enlever l'ancien processeur, mettre le nouveau, mettre de la pâte thermique, remettre le radiateur, terminé.

Ensuite, tester la RAM. Toujours tester la RAM. Et c'est le drame. La machine plante carrément sous Memtest86+... 😰 Je me rends compte que le 2e slot de RAM provoque immédiatement une erreur... La machine ne démarre même plus avec un module dedans, que ce soit celui d'origine ou le nouveau... Et les bips indiquent bien un problème de mémoire... 😑

Je me décide à commander une barrette de 16 Go. 😑 Et là, en relisant un post sur le net, je vois que quelqu'un a eu le même problème, et qu'en fait le socket était sale... Je démonte la machine, mon socket est nickel. Mais le processeur avait des contacts crados... 😥

Ni une ni deux j'essuie les contacts, je remonte tout, je remets les deux modules de RAM, et tout marche ! 🎉

Bon il faut tester la RAM quand même, et tout passe. 😉

Et pendant mes tribulations, j'ai decouvert un truc avec HP et Secure Boot... J'avais laissé Secure Boot activé, et j'avais fait des mises à jour Windows avec l'install qui est arrivée avec pour mettre à jour le BIOS. Et là en démarrant un Ventoy, je me prends une erreur Verifying shim SBAT data failed: Security Policy Violation... C'est un problème connu, Microsoft a invalidé des clés Secure Boot, dont certaines utilisées par les Linux...

Bizarrement mon Debian qui démarrait bien jusque-là s'est aussi pris l'erreur... 😑 Je me suis dit que j'allais désactiver Secure Boot. Il y a un menu exprès dans le BIOS HP. Au redémarrage, le BIOS demande qu'on tape un code numérique affiché à l'écran, pour confirmer la désactivation. Mais je me rends compte que ça ne marche pas, le Secure Boot est réactivé tout seul... 😑

Après un moment à chercher, je découvre qu'en fait le code tapé doit s'afficher à l'écran... Je tapais les touches numériques tel quel en clavier US, mais j'avais dû le mettre en FR... 😑 En tapant les touches numériques avec Maj, les chiffres s'affichent et Secure Boot se désactive. 🎉

J'en ai profité pour mettre à jour les clés Secure Boot de mon Debian :

apt update 
apt install --reinstall grub-efi-amd64-signed shim-signed
grub-install
update-grub

En retestant avec Secure Boot, ça passe. 😉 Je l'ai redésactivé dans le doute...

Et donc au final, qu'est-ce que ça m'a apporté ? Deux fois plus de RAM, toujours la même utilisation :

btop ram new

Graphe mémoire de Btop++

En ce qui concerne le processeur... J'ai trouvé quelques benchmarks sur le net, et c'est... édifiant. D'abord sysbench. Le test CPU calcule des nombres premiers pendant 10 secondes.

Résultat pour le Core i3 6100T :

# sysbench cpu run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 1061.90
General statistics:
total time: 10.0002s
total number of events: 10621
Latency (ms):
min: 0.94
avg: 0.94
max: 1.23
95th percentile: 0.94
sum: 9997.66
Threads fairness:
events (avg/stddev): 10621.0000/0.00
execution time (avg/stddev): 9.9977/0.00

Résultats pour le Core i5 7500T :

# sysbench cpu run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 1080.48
General statistics:
total time: 10.0003s
total number of events: 10807
Latency (ms):
min: 0.91
avg: 0.93
max: 1.36
95th percentile: 0.97
sum: 9997.99
Threads fairness:
events (avg/stddev): 10807.0000/0.00
execution time (avg/stddev): 9.9980/0.00

Le 6100T trouve 1062 nombres par seconde, contre 1080 pour le 7500T. J'ai donc gagné... 2 % de performances. Pour presque 45 €. 😅

Je teste Geekbench, et je me trouve rassuré. 🎉

Le test single core me donne 1181 pour le 6100T, pour 1239 pout le 7500T. 5 %. C'est "mieux". 😒

Mais le test multi-core est bien meilleur ! 2237 pour le 6100T, et 3686 pour le 7500T, 65 % d'amélioration ! 🎉 Mais bon, Btop++ me dit que c'est toujours inutile... 😅

btop cpu new

Info CPU Btop++

Donc voilà, je suis passé à côté d'acheter de la RAM pour rien, d'avoir une machine qui plante aléatoirement, pour au final dépenser autant sur les pièces inutiles que la machine entière. Trop bien. 🤣