Je peux lire une compilation de MP3 si tu veux... :p
Version imprimable
Je peux lire une compilation de MP3 si tu veux... :p
As tu vraiment besoin de faire des installs ? Ou booter d'1 livedisk, mount les SSD et make pourrait suffir ? (D'ou pas besoin de faire d'install pour tester la fameuse compil de kernel dont le newb reve;)).
Pataper :).
PS: et pas la peine de m'envoyer les disques, ca fait 3 semaines que je tourne a 70+ heures. Je ne slack pas comme le newb :).
C'est vrai. Et si en plus tu faisais tes benchs avec un système de fichiers modernes comme ZFS? C'est justement optimisé pour les petits fichiers. Ça serait future-proof comme-ça vu qu'on va sûrement devoir attendre 5-6 ans avant de voir quelque-chose comme-ça sous windows.
Arrêtez de le tenter, vous allez avoir un divorce sur la conscience...
Il faut juste ajouter qu'il faut désactiver le scheduler d'I/O avancé de linux quel que soit le FS utilisé quand on travaille sur du SSD.
(http://www.cyberciti.biz/faq/linux-c...-for-harddisk/)
Normalement, Windows seven aura des optimisations spécifiques aux SSD (WinHEC 2008).
Et comme d'habitude, attention à la géométrie de la partition sur le SSD. Surtout si on teste avec XP.... ^_^
Tu peux détailler un peu plus, genre pourquoi il faudrait désactiver le scheduler?
En fait, c'est assez simple: les premières versions de linux avait un scheduler fifo: les données étaient retournées dans l'ordre demandées.
Depuis je ne sais plus quelle rélease (2.2 ? 2.4), le scheduler par défaut n'est plus le fifo mais le CFQ. Et son principe de fonctionnement n'est plus du tout le même: Partant du principe que c'est le déplacement des tetes qui prend du temps, il va tenter de conserver une liste des blocs demandés, et de tenter de réorganiser cela de manière la plus efficace possible.
Or, sur un SSD, il n'y a pas de tete. Et parfois même deux blocs contigus dans la géométrie du disque ne le sont pas en hardware. C'est donc du temps perdu.
Et ce serai pire si le scheduler était l'AS (je ne connais pas de distro qui le met par défaut), car dans ce cas, le scheduler ATTEND après chaque ordre pour voir s'il arrive un autre ordre qui serait proche (Algo de l'ascenseur).
Ça demande un peu d'investigation, mais effectivement je n'avais pas pensé que les algos étaient liés au déplacement physique des têtes. Je vais me renseigner, ça me parait trop facile :)
Edit: un peu plus d'infos http://www.redhat.com/magazine/008ju...es/schedulers/
Ça me paraît quand-même assez aléatoire et trèèès dépendent de ton utilisation.
Pas tellement en fait. Ici, c'est un test orienté 'serveur'. Comme toujours avec RedHat, quasiment d'ailleurs, et comme d'ailleurs s'oriente de plus en plus linux au détriment de l'utilisateur de base comme Newbie06 qui ne va pas pouvoir résister à un troll pareil.
Brefle.
Ta comparaison, ici, est: Ayant un sous système disque qui a de la latence (le temps d'accès), quel est le meilleur scheduler dans le cadre d'une base de données.
Or, sur un SSD, il n'y a point de latence.
La latence due au CFQ me parait quand-même totalement minimale, voir négligeable sur une configuration desktop (dont l'utilisateur t'emmerde d'ailleurs :p). Je vais tester.
Je ne reponds pas a un mec qui dit qu'il faut du swap pour un OS :p
Bon, j'ai fini ma petite série de benchs qui aura quand-même pris plus de 2h...
Alors mon SSD, un Samsung MLC disposant d'un contrôleur décent et de mémoire cache a subi quelques compilations de kernels 2.6.28 avec une configuration par défaut. J'ai juste fait un "make menuconfig" et sauvé le fichier .config généré dans l'archive du kernel.
Résultats avec le scheduler en CFQ: 4161 secondes
Résultats avec le scheduler en NOOP: 3653 secondes
Ce qui nous fait 13% de temps en moins à la compilation, qui utilise plein de fichiers partout. Appréciable...tout ça en ajoutant "elevator=noop" au démarrage du kernel.
Si jamais le petit script tout pourri que j'ai fait:
Et le gentil contrôleur Samsung en question et le disque (d'un Lenovo x301):Citation:
#!/bin/bash
START=$(date +%s)
tar -jxf linux-2.6.28.2.tar.bz2
cd linux-2.6.28.2
make
STOP=$(date +%s)
TOTAL=$(($STOP - $START))
echo $TOTAL
http://www.alphatek.info/divers/ssd/ssd.jpghttp://www.alphatek.info/divers/ssd/ssd2.jpg
Merci à toi plutôt pour m'avoir averti de l'existence même de ce "problème" :)
Joli, 13% c'est pas degueu. On se demande a quel point les tests de SSD actuels sont pourris par ce genre de "details" caches dans les OS aujourd'hui. Cela me surprendrait que windows ne fasse pas ce genre de choses par exemple.
Cette info vaut une news, les poussins, IMHO.
Ouais, juste pour tester effectivement.
Intéressant tout ça. Qui s'y colle pour en faire une news ? :P
Neo il a l'air super motivé, c'est un héros.
La question qui se pose maintenant est de savoir ce qu'il advient si on balance les mêmes tests sur du ZFS au lieu de l'ext3? Sachant que le ZFS a des algos pour garder les petits fichiers en cache avant de les écrire tous d'un coup dans un gros bloc et qu'en plus il fait du copy on write. Ça permettrait presque de contourner le problème de vitesse d'écriture sur les chips JMicron que Stéphane a constaté.
Titre: Un lapin en raid de cafe optimise Linux pour les SSD - Quid de Windows ?
Je vous laisse ecrire la news, je suis deja epuise.
Effectivement, sans vouloir froisser les linuxiens, savoir ce qu'il en est pour Windows serait (plus) intéressant...
Cela dit, +13% c'est énorme, sachant que c'est le temps total de compilation donc ça compte aussi la partie CPU qui n'est en rien accélérée.
J'aimerais bien voir le meme test avec make -j 2 et -j 3 puisque tu as un dual-core...
Attends les résultats de la compilation parallèle, ça sera une bonne indication supplémentaire je pense :)