Heureux possesseur d'un Fit-PC slim (www.fit-pc.com) tout neuf, je vous fais part de quelques tests et ordres de grandeur sur la puissance de calcul de la bête.
Matériel : AMD Geode LX 800 (500MHz), disque dur IDE 5400 tpm. Processeur x586 (686 est possible mais émulé, donc non recommandé), chiffrement AES-128 et générateur aléatoire matériel.
Distribution : Debian lenny (etch initialement, passée en lenny vu l'imminence de sa parution). Je passe sur l'installation à partir d'une clef USB via une console série, tout se passe bien quand on se décide à prendre l'image toute faite (qui nécessite une clef de 256MB) au lieu de tenter d'utiliser une clef 128 en copiant a minima les fichiers (image ISO businesscard), je vous laisse consulter http://www.debian.org/releases/stable/i386/ch04s04.html.fr ). Ne pas oublier de préciser la console dans syslinux.cfg.
1) Modules matériels crypto & random.
Le module de chiffrement AES et le générateur aléatoire matériel sont bien reconnus sous Linux depuis les versions 2.6.2x. Il est donc naturel d'essayer de quantifier leur apport dans le cadre d'une utilisation pratique.
1.1) AES
L'application première d'un tel module sous Debian est bien évidemment le chiffrement des partitions (LVM pour /, /boot excepté). Bien sélectionner chiffrement AES-128-CBC à l'installation, le mode CBC étant (avec le mode ECB qui n'est pas recommandé) le seul supporté par le module matériel. On ajoute un ESSIV sha256 pour plus de sécurité (ça aura un impact comme vous le verrez). On évite par contre le remplissage du disque avec de l'aléas vu la puissance du processeur (le module matériel n'étant pas utilisable faute de module compilé dans l'image d'installation), à faire ensuite.
On ajoute geode-aes au fichier /etc/initramfs-tools/modules pour qu'il soit chargé et utilisable par l'API crypto du noyau dès le démarrage.
Exemple de résultat significatif (refaits plusieurs fois, aucun service ne tournant à part sshd):
hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 90,6 MB in 3.05 seconds = 29,7 MB/sec
hdparm -t /dev/mapper/ma_partition_chiffrée
/dev/hda:
Timing buffered disk reads: 41,6 MB in 3.05 seconds = 13,7 MB/sec
ce qui est très correct. À noter que sha256 en logiciel fait tourner le processeur à plein, c'est donc lui qui nous limite. Ce ne serait sans doutes pas le cas avec un module matériel crypto un peu plus développé (par exemple via padlock).
Si on retire le module geode-aes de l'initrd, les performances chutent drastiquement:
hdparm -t /dev/mapper/ma_partition_chiffrée
/dev/hda:
Timing buffered disk reads: 17.4 MB in 3.05 seconds = 5,7 MB/sec
ce qui n'est pas vivable.
1.2) Module d'aléas
on charge le module geode-rng par la commande modprobe geode-rng , il faut installer le paquet rng-tools pour qu'il soit utilisé. Ce paquet installe le démon rngd, qui est chargé de récupérer l'aléas du générateur matériel 20000 octets par 20000 octets, d'effectuer des tests cryptographiques (FIPS) dessus pour en vérifier la qualité, et ensuite de l'ajouter au pool d'entropie du noyau. On peut ensuite lire /dev/random (oui ami lecteur, tu as bien vu ! random et non urandom ou autres !) à plus ou moins 70ko/s (vérifier avec la commande dd if=/dev/random of=/dev/null ). Le démon rngd occupe environ 30% du processeur, le reste pour dd.
2) Le processeur en lui-même
Je voulais profiter d'une des innovations de la dernière version de gcc, à savoir l'apparition d'une option de compilation spécifiquement dédiée au geode LX.
2.1) Le noyau
Les sources du noyau Linux ne prennent pas encore en compte cette possibilité, il faut modifier (légèrement) un des Makefile pour que l'architecture soit la bonne
# Geode LX support
cflags-$(CONFIG_MGEODE_LX) += -march=geode
au fichier arch/x86/Makefile_32.cpu donnent l'option demandée (vérifiable avec ps aux |grep geode durant la compilation du noyau par exemple).3 heures de compilation avec make-kpkg plus tard (noyau allégé de beaucoup de modules et de pilotes inutiles... je peux fournir mon .config si quelqu'un est intéressé), reboot, pas d'amélioration significative propre à l'architecture à mesurer (j'ai également modifié d'autres paramètres, la préemption et la fréquence de base) sauf peut-être un temps de démarrage plus rapide au niveau de l'initrd et de la détection du matériel, et une légère amélioration de la vitesse de lecture sur disque (de l'ordre de 3 à 4 % peut-être ? mais les mesures fluctuant déjà pas mal, je n'ai pas fait de stats détaillées. L'ordre de grandeur reste le même de toutes façons :-)
2.2) Benchmark nbench (http://www.tux.org/~mayer/linux/ ) avec différentes options de compilation.
Les différentes sources sur internet précisent qu'en général, vu le faible cache du geode LX (64kB = 32kB instructions, 32 kB données pour le L1, 128 kB pour le L2) il vaut mieux compiler avec l'option -Os (réduit la taille du code) plutôt que -O3) je voulais voir un peu ce qu'il en était et jouer avec les différentes options d'optimisation de gcc. Notamment, prendre un -Os mais en ajoutant certaines optimisation (précisées comme pouvant avoir un impact au niveau
Il devient possible de mesurer l'impact du choix de l'architecture face à un x86 générique, on obtient des gains de temps allant de 20 à 50% suivant les options !!
À noter que comparé à la liste des processeurs présentés ici http://www.tux.org/~mayer/linux/results2.html , le geode se sort très honorablement des tests faisant appel à la mémoire et au calcul sur les entiers, par contre est très lent en ce qui concerne les flottants - peu étonnant, la fiche technique détaillée disponible à http://www.amd.com/files/connectivitysolutions/geode/geode_l(...) précise en effet page 202 que les opérations sur les double sont émulées et prennent beaucoup plus de temps que les opérations sur des float).
Les résultats sont les suivants, idem je peux fournir les résultats détaillés (différents tests sont exécutés, par exemple transformée de Fourier, chiffrement IDEA, tri, etc. les résultats varient suivant les options) :
kernel : 2.6.26-geode
C compiler : gcc version 4.3.2 (Debian 4.3.2-1)
libc : libc-2.7.so
NATIVE
-s -static -Wall -O3
MEMORY INDEX : 11.665
INTEGER INDEX : 12.023
FLOATING-POINT INDEX: 10.855
GEODE (arch, O3 plus some optimizations)
-s -static -O3 -fomit-frame-pointer -Wall -march=geode -fforce-addr -falign-loop
s=2 -falign-functions=2 -falign-jumps=2 -funroll-loops
MEMORY INDEX : 15.813
INTEGER INDEX : 13.508
FLOATING-POINT INDEX: 10.766
OPTIMIZE FOR SIZE (same options, except O3 is replaced by Os)
-s -static -fomit-frame-pointer -Wall -march=geode -fforce-addr -falign-loops=2 -falign-functions=2 -falign-jumps=2 -funroll-loops -Os
MEMORY INDEX : 15.680
INTEGER INDEX : 13.271
FLOATING-POINT INDEX: 10.642
OPTIMIZE FOR SIZE, PLUS SOME O3 & OTHER OPTIMIZATIONS:
-s -static -fomit-frame-pointer -Wall -march=geode -fforce-addr -falign-loops=2 -falign-functions=2 -falign-jumps=2 -funroll-loops -fsee -ftree-vectorize -ffast-math -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -Os
MEMORY INDEX : 16.333
INTEGER INDEX : 13.335
FLOATING-POINT INDEX: 10.774
3) Compléments
Les impressions générales sont bonnes, le processeur n'est pas très rapide mais il fonctionne très bien et il y a de la place pour bons nombres de services sur une telle configuration. J'avais vraiment peur pour des applications java, mais il s'en sort très bien. À ce sujet, il vaut mieux les lancer avec l'option java -server :-) pour un gain de performances sensible même si là encore non quantifié avec précision vu les variations de charge de l'application.
Les capteurs de température fonctionnent très bien, pour fixer un ordre de grandeur à pleine charge le processeur monte à 47°C (pour une température recommandée inférieure à 70°C, critique à 85°C, le CPU chauffe un peu plus (70°C, max recommandé 86°C, critique 126°C). Pendant ce temps, le disque beaucoup sollicité monte à 43°C (c'est un seagate momentus). Le boîtier chauffe pas mal, mais on peut en général laisser la main dessus, d'ailleurs c'est amusant ce faisant on voit tout de suite la température baisser ! ben oui, la main au contact du boîtier évacue mieux la chaleur que l'air ambiant sans ventilation ni radiateur !). Enfin, la machine est aussi silencieuse que le disque dur, c'est-à-dire qu'on n'entend quasiment rien.
À suivre : recompilation d'autres packages laissant espérer des gains appréciables quant aux optimisations liées à l'architecture (comme la libc...), apt-build semble être mon ami. Le flag -O3 (ou d'autres flags d'optimisation de la compilation) sont-ils réellement vecteurs d'instabilité ? http://gentoo-wiki.com/CFLAGS_matrix dit qu'il est considéré risqué, mais sans plus... Des retours d'expérience sur apt-build et -O3 ?
Le plus impressionnant est selon moi les perfs du module matériel AES, openssl dispose d'un engine lui permettant d'utiliser le padlock de via, à quand un patch pour le geode ? Sinon il y a un projet qui cherche à proposer l'API crypto du noyau comme engine openssl (ocf framework for linux, http://ocf-linux.sourceforge.net/ mais je n'ai pas vu grand-chose d'utilisable pour le moment. Dommage, si j'avais le temps et les compétences j'essaierais de contribuer, car certains trucs seraient très intéressant : utiliser ssh en précisant le mode de chiffrement AES-128-CBC, et éviter une grosse montée en charge, bien visible avec top, lors de transferts de fichiers un peu gros à haut débit (même sans compression. Avec ssh -C, c'est pire !)).
PS (je profite de ce journal pour poser une question qui aurait plutôt sa place dans les forums, pardonnez-moi svp :) : si quelqu'un a acheté le même PC, peut-il me dire si le wi-fi est désactivé par défaut dans le BIOS ou non ? impossible de le faire fonctionner (j'ai tout essayé, chargé les modules rt73usb & co, installé les firmware du site de ralink dans /lib/firmware, rien n'y fait pas de nouvelle interface réseau !), et je n'ai pas d'écran facilement accessible pour vérifier (d'où l'installation par une console série).
# /dev/random
Posté par yellowiscool . Évalué à 3.
Car même si c'est théoriquement plus aléatoire, dd if=/dev/urandom of=/dev/null me donne 4.1Mo/s sur ma machine. C'est beaucoup plus performant.
Envoyé depuis mon lapin.
[^] # Re: /dev/random
Posté par Aefron . Évalué à 4.
"random" est un bien meilleur générateur pseudo-aléatoire, mais, sur une machine qui n'a rien de prévu pour créer de "l'aléa", son flux va être très lent... tu peux le vérifier en faisant un "cat /dev/random" : si tu ne fais presque rien, il ne crache presque rien... dès que, par exemple, tu bouges ta souris, il crache du bruit...
Apparemment, la plate-forme geode testée par khivapia embarque de quoi nourrir un peu mieux "/dev/random", et le rendre plus utilisable
Par exemple, du "dd if=/dev/random" sur une partition de plusieurs Gio, par exemple, faut vraiment vraiment vraiment pas être pressé (même à 70kio/s)...
Par contre, je l'ai vu facilement rajouter une dizaine de secondes au boot sur la génération de deux clés aléatoires, une pour le swap et une pour le /tmp)... pour des clés qui sont vraiment toute petites, de quoi booster "/dev/random" peut être intéressant.
[^] # Re: /dev/random
Posté par khivapia . Évalué à 7.
Ça implique comme le dit plus haut Aefron les clefs de chiffrement temporaires de partition, mais (normalement aussi) tout ce qui est clef ssl, etc. Après, ça dépend des données à protéger, mais ça ne peut qu'améliorer la sécurité (et parfois on trouve des problèmes, qui ne sont certes pas à la portée de tout le monde, mais qui rappellent que rien n'est sûr, voir par exemple http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Gut(...) qui avait un peu étudié urandom, ou le papier complet ici http://eprint.iacr.org/2006/086.pdf ).
La partie de l'article wikipedia sur FreeBSD explique que dans le pire des cas (pas de disque dur donc très peu d'aléas interne), le pool d'entropie est quasiment sous contrôle de l'adversaire (par le réseau), ce qui n'est pas une bonne idée. On évite complètement ce problème avec un générateur matériel. Par exemple si le PC geode sert comme routeur et serveur ssh, il y a des risques !
D'une manière générale obtenir et utiliser facilement de l'aléas de bonne qualité est une meilleure chose :-) ça évite de se retrouver avec des surprises plus tard.
Pour ce qui est des partitions en effet ça ne sera pas très rapide :) mieux vaut alors utiliser urandom (qui est lui-même bien lent pour tout un disqueà ou bien, mieux, un chiffrement de flot dont on réinitialise la clef (avec random) régulièrement.
Enfin un dernier avantage est que ça évite les attaques DoS par exhaustion du pool d'entropie (faites un cat /dev/random et essayez de générer une clef gpg par ailleurs, ça devrait moins bien se passer :)
# Fit-PC Slim, ça vaut le coup ?
Posté par Médéric RIBREUX (site web personnel) . Évalué à 5.
merci de ce récapitulatif intéressant et complet sur cette machine que je ne connaissais pas...
Il n'y a pas si longtemps, je me suis mis en quête de trouver une machine (station de travail) avec le cahier des charges suivants:
- Tourne correctement sous Debian lenny.
- ne prend pas trop de place.
- est silencieuse.
- ne consomme pas beaucoup d'électricité.
- est un vrai ordinateur (pas un netPC).
- par extension dispose d'un vrai disque dur
- est équipée avec un processeur digne de ce nom (de quoi coder avec vim et compiler un noyau complet sans y passer des heures tout en jouant de la musique...).
- dispose du Wifi
- ne coûte pas une fortune pour ce que c'est (exit mac-mini quoi)
J'ai vu des solutions intéressantes et le Fit-PC Slim aurait sans doute valu le coup mais, j'ai l'impression d'avoir trouvé mieux: une Asus EeeBox. Je l'ai payée 230€ avec 1Go de RAM et un Intel Atom N270 (je ne connais pas la comparaison possible entre ce processeur et l'AMD Geode LX800) et un disque dur 2,5" SATA de 80Go... (et une licence WinXP je l'avoue, simplement car à l'époque, il n'y avait pas de version Linux de disponible à la vente et que j'étais pressé).
Je vois que le Fit-PC Slim est vendu entre $350 et $390 soit entre 260 € et 287€ et j'ai l'impression (à confirmer) que ce matériel est moins performant qu'une EeeBox.
Maintenant, peut-être que la taille de la machine est encore plus réduite et que le fait d'être totalement fanless monte un cran dans le domaine du silence.
Du coup, moi je dis: "Question ! Question ..." (Qu'est-ce-qu'il y connait Rick Hunter aux femmes ?): Qu'est-ce-qui t'a fait acheter cette machine ?
[^] # Re: Fit-PC Slim, ça vaut le coup ?
Posté par khivapia . Évalué à 4.
tout d'abord ce comparatif n'est pas complet :) je ne me suis absolument pas intéressé aux performances graphiques par exemple...
Pour répondre à tes questions, de ce que j'ai compris sur internet le fit-pc ne consomme que 5W tout compris (et même si je n'ai pas d'ampère-mètre ça m'a l'air plutôt vrai) là où les solutions à base d'Atom consomment plutôt au minimum 20W voire 35 (le processeur tout seul consommant 5W, ajouter chipset, puce graphique etc (qui sont intégrés dans le cas du geode), etc. etc. ).
Après, je pense qu'entre un geode de 2005 cadencé à 500 MHz et un Atom conçu en 2007/2008 et fonctionnant à 1.6GHz, il n'y a pas de comparaison possible :) le geode est beaucoup moins performant (sauf en génération d'aléas et chiffrement AES, mais bon... ;). D'ailleurs si quelqu'un veut faire le nbench pour comparer ! (télécharger sur le lien du journal)
Après ce qui m'a fait l'acheter, c'est bien évidemment le côté totalement silencieux (si l'on excepte le disque dur, mais neuf ça va c'est plutôt tolérable ;), la consommation très faible, et le fait qu'il soit largement suffisant pour mes besoins - serveur web, fichiers, quelques applications tournant 24h/24, voire plus tard comme ordinateur de bureau quand j'en aurai vraiment marre de mon vieux portable sans autonomie. Et bien sûr, sur une petit config ça force à geeker un peu pour voir si en tunant un peu les paramètres on gagne vraiment en performances ressenties :) Je n'ai pas vraiment pensé à l'eeeBox.
D'après d'autres retours d'expérience sur internet, le geode est convenable pour à peu près tout, sauf lire des vidéos flash (étonnant, non ? encore que en désactivant l'anti-aliasing et en diminuant la résolution il paraît que ça passe) et parfois la vidéo (ne pas compter lire de la HD). Pour compiler des projets, c'est certes un peu lent, mais de mon point de vue c'est tout à fait correct tant qu'on reste en -O0, en tout cas c'est comparable aux netbooks à base de Celeron.
[^] # Re: Fit-PC Slim, ça vaut le coup ?
Posté par alice . Évalué à 3.
Il y en a maintenant???
# Nbench et -O3
Posté par gUI (Mastodon) . Évalué à 2.
Il suffit que gcc soit moins optimisé pour ce processeur pour faire chuter les scores. Autant l'utiliser avec ce qu'on utilise en général : -O2.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Nbench et -O3
Posté par khivapia . Évalué à 2.
Sinon c'est bien le problème de tous les benchmarks, on ne compare pas seulement les processeurs mais aussi le compilateur, la libc, le noyau etc. etc. Mais ça permet de se faire une (petite) idée... Sinon j'avais plutôt fait les bench pour voir l'influence des options de compilation sur la performance du code, pour déterminer quelle était la meilleure combinaison.
Il faudrait refaire le bench sur d'autres architectures, dans les mêmes conditions (même version du compilateur, mes noyaux & libc), pour pouvoir comparer un peu plus finement. Ce n'est pas très long, il suffit de télécharger le tar.gz, de modifier (le Makefile avec les options désirées, et
[^] # Re: Nbench et -O3
Posté par Zenitram (site web personnel) . Évalué à 4.
Il faut utiliser les optimisations, car c'est ce qu'on va utiliser plus tard.
Si GCC est moins optimisé pour ce CPU, le constructeur dudit CPU peut contribuer à GCC...
Autant je peux être d'accord avec toi si on teste sur des applications dont on ne maitrise pas la compilation, autant la on parle de code libre non? Si on peut compiler,avec -O3, ben on bench avec -O3, et que le meilleur (pas seulement le CPU, mais l'éco-système CPU+compilateur) gagne.
[^] # Re: Nbench et -O3
Posté par Corto . Évalué à 2.
Les constructeurs participent au code des compilateurs ?
Je crois que Intel vend son compilateur (et qu'il est assez performant), mais je n'ai pas eu vent d'un compilateur AMD... il serait intéressant qu'ils fassent eux-même les optimisations pour leurs processeurs dans gcc.
Ce serait un argument de choix pour leurs procs !
Corto
[^] # Re: Nbench et -O3
Posté par Ontologia (site web personnel) . Évalué à 5.
http://developer.amd.com/assets/AMD_GCC_Quick_Reference_Guid(...)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Nbench et -O3
Posté par Raphaël G. (site web personnel) . Évalué à 5.
Par exemple a lyon sur la doua il y a des labos qui récupèrent les premières version de nouveaux processeurs amd (et intel?).
(version ni optimisée, ni finement gravée qui fait plusieurs cm de large)
C'est comme ça que par exemple le support amd64 est arrivé extrêmement tôt !
On avait pas encore de machine amd64 dans le commerce ni pour les professionnels que le noyau, gcc et compagnie avait déjà du code écris pour.
[^] # Re: Nbench et -O3
Posté par gUI (Mastodon) . Évalué à 2.
Ce que je veux dire, c'est que toi, dans ta distrib, c'est pas compilé avec -O3 (sauf si tu as Gentoo par exemple et que tu tes tunné les options, mais le -O3 est déconseillé).
Donc bencher sur -O3 ne sert à rien, puisque presque personne n'utilise le -O3.
En benchant avec -O3 tu prends le risque de trouver un processeur plus rapide si le compilo est particulièrement optimisé, mais après dans tout le reste de ta vie ce sera pas le cas. Donc ton résultat ne sera pas du tout réaliste.
Après, encore une fois, je sais très bien que tous les bench ont leurs limites, c'est évident, et incontournable.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Random en passant
Posté par Kerro . Évalué à 4.
J'imagine en plus que ça ne coûte rien d'en mettre un dans un chipset. Pourquoi ce n'est pas en standard depuis des années ce truc ! Ca m'agace.
Un chti sourire tout de même tient: :-)
[^] # Re: Random en passant
Posté par khivapia . Évalué à 3.
lshw ne m'a rien donné à ce sujet en effet, et il n'y a pas de fichier dans /dev/ avant l'insertion du module.
En général la présence du générateur matériel est quelque chose sur lequel les fabricants/revendeurs font de la pub, c'est comme ça que je l'ai su,
# OpenSSL & OpenBSD
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
Si tu as envie d'essayer, cela existe déjà sous OpenBSD et OpenSSL peut donc utiliser l'AES-CBC du Geode LX.
# Geode AES
Posté par Patrick Lamaizière (site web personnel) . Évalué à 4.
Jamais : le cryptage avec le via padlock est fait par des instructions étendues du processeur, l'approche utilisée sur le Geode LX est complètement différente.
Même s'il est intégré au processeur, le bloc de sécurité AES est vu comme un périphérique PCI, on y accède en faisant du DMA entre la mémoire et le périphérique.
Pour accéder au matériel, OpenSSL utilise un périphérique cryptodev qui fait le lien entre le userland et le matériel dans le noyau. C'est ce qu'apporte l'Open Crypto Framework (OCF). Sous les BSD, OCF est aussi utilisé en interne par le noyau (pour IPsec par exemple).
J'ai fais pas mal de tests de perf avec OpenSSL sous FreeBSD (j'ai porté le driver glxsb d'OpenBSD sous FreeBSD). Ce qui me chagrine le plus dans le bloc de sécurité c'est la lenteur des interruptions pour déterminer la fin du codage. Du coup il faut utiliser un horrible busy-wait et tester la fin en lisant les registres. Beurk !
Pour crypter un fichier de 361 Mo:
/usr/bin/time -h openssl enc -e -aes-128-cbc -in file -out /dev/null
-k abcdefghijk -nosalt
- sans le matériel:
1m11.57s real 1m7.69s user 3.34s sys
- avec le matériel en utilisant les interruptions (oui c'est plus long en temps réel)
1m27.08s real 1.58s user 6.85s sys
- avec le matériel et un busy wait.
18.41s real 1.51s user 16.75s sys
- avec le matériel et un busy wait, mais qui tourne dans un thread noyau (pour éviter de bloquer dans l'OCF). C'est la version actuelle du driver FreeBSD.
21.11s real 1.57s user 6.41s sys
Je suis preneur de mesures faites sous Linux.
J'ai aussi fait des essais sur IPsec en aes-128-cbc + hmac_md5, en faisant des pings flood simultanés à partir d'une autre machine "ping -f -s 3000". Sans le matériel, la machine est à genou avec 5 ping, top ne tourne plus. Avec le matériel, je peux faire 8 ping flood sans aucun soucis (je n'ai pas essayé plus loin). Top:
CPU: 0.0% user, 0.0% nice, 33.5% system, 12.5% interrupt, 54.1% idle
Je n'ai pas fait de benchmark d'Ipsec, OpenBSD annonce du 30Mbit/s mais sans en dire beaucoup plus :
http://www.onlamp.com/pub/a/bsd/2007/11/01/whats-new-in-bsd-42.html
Enfin bref il y a quand même un net gain de perf, et puis c'est présent sur le processeur alors autant s'en servir.
Pour le générateur de nombre aléatoire pas grand chose à dire, je l'ai testé avec le module rndtest (FIPS 140-2) de FreeBSD et j'ai eu une dizaine d'échecs en quatres jours, mais toujours avec des valeurs très proches de l'intervalle autorisé:
glxsb0: rndtest: zeros interval 3 failed (723, 542-708)
723 pour 708
glxsb0: rndtest: ones interval 1 failed (2336, 2343-2657)
2336 pour 2343
Alors je pense que c'est bon, enfin j'espère c'est pas facile à dire.
les pixels au peuple !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.