On reprend où l'on s'était arrêté : l'installation de la Slackware proprement dite. Mais je vais me permettre quelques digressions sur l'aspect hardware avant de revenir vers le soft un peu plus tard.
Je tiens quand même à rappeler que les événements que j'ai retracés (en les condensant en plus !) dans les deux derniers articles ont quand même pris 3 semaines.
Entre le temps de faire les premiers tests, de commander la RAM supplémentaire et de la recevoir, de poursuivre les différents essais entrecoupés de (trop) nombreux reboots fastidieux m'imposant presque à chaque fois de reconfigurer le BIOS – notamment redétecter le disque –, et les recherches infructueuses sur la Toile, ce fût un travail de longue haleine.
Le fait de devoir reconfigurer le BIOS après chaque extinction (car manque de prises oblige, je débranchais la bête après utilisation) était particulièrement pénible. Surtout le premier boot où par défaut la RAM est vérifiée intégralement. Quand je n'avais que 6 Mo c'était déjà long, mais avec 16 Mo c'est devenu intenable, surtout le buzzer sadique qui égrène les Ko presqu'un par un.
Le remplacement de la pile CMOS
Possédant la pile d'origine, je me suis dit qu'il serait facile de trouver une remplaçante sur n'importe quelle boutique en ligne. J'ai rapidement regardé les inscriptions dessus et j'ai vu "3.6V", j'ai donc lancé mes recherches avec cette seule valeur, pensant qu'il était plus simple de chercher une pile de même tension plutôt que de même modèle. Mal m'en a pris.
Si j'avais lu correctement et complètement j'aurais également vu "1/2AA", ce qui m'aurait permis de trouver directement cette référence sur Amazon.
Au lieu de ça j'ai écumé plusieurs boutiques chinoises sur le Web (ainsi qu'Amazon mais qui ne m'a rien sorti de pertinent avec cette seule information) qui m'ont amenées à la conclusion que ce modèle n'existait plus.
Je me suis alors dit que je pouvais sûrement bidouiller un abaisseur de tension qui me permettrait d'utiliser n'importe quelle autre type de pile en remplacement. J'ai donc commandé des résistances pour faire un pont diviseur de tension avec une pile de 9V. Sauf qu'un montage pareil consomme déjà à vide ce qui fait que la pile ne tient pas plus de quelques jours (expérience à l'appui !).
Après une semaine de tests j'ai dû me résoudre à l'évidence : mon montage ne tenait clairement pas la route. Il faut bien faire des erreurs pour apprendre, diront certains. C'était en cours de techno il y a 15 ans que j'aurais dû les faire, préciserai-je. Mais bon, l'ensemble ne m'aura pas coûté plus de 8€. Pour le temps perdu par contre c'est une autre affaire.
En recherchant cette fois le modèle exact (TL-5151 de Tadiran) je tombe sur de nombreuses boutiques qui proposent enfin de quoi m'aider ! (http://www.google.fr/search?q=tl-5151) Mon choix se porte logiquement vers Amazon qui affiche une référence équivalente pour 6€ (http://www.amazon.fr/dp/B002Q4W8SU/). Commande passée, et reçue en un délai record (expédiée le jour-même, et reçue 2 jours plus tard si je me souviens).
La pile d'origine était soudée à 2 fils reliés au connecteur qui se branchait sur la carte mère. Je n'ai pas de fer à souder donc j'improvise les contacts avec du papier alu et du chatterton (l'ami des bricolos du dimanche). Un petit test et tout se passe bien, je peux enfin sauvegarder les réglages du BIOS et débrancher à loisir l'alimentation ! C'est dingue comme un petit détail comme ça fait toute la différence.
Je peux à présent me concentrer sur le coeur du problème. Évidemment, c'est un peu tard, car maintenant que le réseau fonctionne je n'ai plus à rebooter sans cesse (enfin, c'est vite dit).
Premier aperçu
La copie des paquets mettra 3 heures environ pour s'achever, sans aucune erreur il faut le préciser.
Un reboot plus tard – sur le disque cette fois ! – et me voilà avec un beau prompt à l'écran. Je procède aux réglages d'usage : ajout d'un utilisateur non-privilégié, suppression des daemons inutiles, configuration du réseau, et pour pouvoir me balader un peu sur mes partages réseau je rajoute Samba.
Environ 10 Mo de RAM sont utilisés après le login, ce qui laisse... huh... 6 Mo pour tout le reste. Je pressens quand même que ça va swapper sec dès que je vais lancer un programme un peu gros (et à cette échelle, tout programme est gros).
La copie de fichiers via Samba tourne à environ 500 Ko/s ce qui balaie immédiatement d'un revers de la souris toute possibilité d'en faire un serveur de fichiers décent.
Les ralentissements observés lors du lancement de commandes semblent d'ailleurs surtout intervenir dès l'accès au disque. Un petit benchmark rapide devrait nous aider à y voir plus clair.
root@ancient:~# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 9.69 seconds = 13.21 MB/sec
Timing buffered disk reads: 64 MB in 42.96 seconds = 1.49 MB/sec
Une brève comparaison avec Usul, mon petit home server :
root@usul-server:~# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1076 MB in 2.00 seconds = 537.50 MB/sec
Timing buffered disk reads: 280 MB in 3.01 seconds = 92.97 MB/sec
Argl. Ah oui on n'est clairement pas sur la même planête ! Pas étonnant que les tranferts de fichiers par le réseau soient si lents. Le disque est déjà à la ramasse pour fournir les données en lecture, alors on imagine à peine en écriture !
Mais parlons à présent CPU. Que nous disent tout d'abord les informations extraites de /proc/cpuinfo ?
root@ancient:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 4
model : 3
model name : 486 DX/2
stepping : 5
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme
bogomips : 33.17
Deux choses me sautent aux yeux ici : tout d'abord la ligne "bogomips" qui révèle la triste évidence : ce CPU est à des années-lumières de ce qui se fait aujourd'hui. Cette mesure, toute relative qu'elle est, est une évaluation de la puissance du processeur. Plus exactement, c'est le nombre de millions de fois par seconde qu'un processeur est capable de... ne rien faire. Oui c'est une boucle vide quoi. Ici en l'occurence il est très simple de calculer sa valeur : c'est la fréquence brute du processeur (en MHz) divisée par deux : 66 / 2 = 33 le compte est bon, tou-dou-dou.
Si je consulte la même valeur sur mon Atom 230 – un CPU qui est dans l'extrême limite basse de ce qui se faisait en 2008 – j'obtiens presque 100 fois plus :
bogomips : 3191.94
Ici le calcul est inverse : architecture et HyperThreading aidant, c'est la fréquence brute du processeur multipliée par deux : 1600 x 2 = 3200, le compte est bon là aussi. C'est donc Michel qui remporte cette manche, et Maryse nous quitte mais repart avec l'Encyclopédie Larousse en 22 volumes. À la semaine prochaine. Heu non c'pas ça.
L'autre valeur qui est assez marquante également est "flags" qui liste toutes les extensions supportées par le processeur, permettant entre autres d'utiliser des registres supplémentaires par rapport au standard x86 ainsi que de réaliser des opérations complexes en une seule instruction. Ici nous n'avons que... deux extensions :
- "fpu" : Floating Point Unit permettant d'accélérer grandement les opérations en virgule flottante (opérations sur des nombres réels),
- "vme" : Virtual-8086 Mode Enhancement permettant de simuler le mode réel du processeur original 8086
Si je compare là encore avec mon simple et modeste petit Atom de 2008 la différence est abyssale :
...
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
...
Je ne vais pas détailler ici chacune d'elle, il est facile de trouver leur signification par Google.
On retiendra cependant "mmx", célèbre pastille marketing d'Intel de la fin du XXème siècle, "lm" (long mode) qui signifie que le processeur est capable de fonctionner en mode 64bit, et "sse" qui fût la réponse d'Intel au 3DNow! d'AMD sorti en 1998, et dont les différentes évolutions ultérieures sont aussi présentes ("sse2" et "ssse3").
Ce sont toutes ces extensions qui font aussi la différence du point de vue des performances de ces deux processeur. Des programmes utilisant intelligemment leur support – ou ayant été compilés pour tirer parti de celle-ci – verront leur exécution largement accélérée (à fréquence égale j'entends).
Ces résultats parcellaires me poussent à lancer un benchmark plus important avant de poursuivre la configuration de ma Slackware, sur lequel je reviendrai très prochainement dans le prochain article (qui devrait arriver rapidement puisque déjà presque rédigé). Stay tuned :)
La suite :
Les aventures d'un 486 DX2 au XXIème siècle (4ème partie)
Les aventures d'un 486 DX2 au XXIème siècle (5ème et dernière partie)