Je peux lire une compilation de MP3 si tu veux...
Je peux lire une compilation de MP3 si tu veux...
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 .
fefe - Dillon Y'Bon
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.
"La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24
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....
There are only 10 types of people in the world: Those who understand binary, and those who don't.
Tu peux détailler un peu plus, genre pourquoi il faudrait désactiver le scheduler?
"La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24
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).
There are only 10 types of people in the world: Those who understand binary, and those who don't.
Ç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.
Dernière modification par Minuteman ; 02/02/2009 à 13h15.
"La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24
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.
There are only 10 types of people in the world: Those who understand binary, and those who don't.
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 ). Je vais tester.
"La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24
Je ne reponds pas a un mec qui dit qu'il faut du swap pour un OS
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):#!/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
Dernière modification par Minuteman ; 02/02/2009 à 17h28.
"La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24
Merci à toi plutôt pour m'avoir averti de l'existence même de ce "problème"
"La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24
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.
fefe - Dillon Y'Bon
Cette info vaut une news, les poussins, IMHO.
Mes propos n'engagent personne, même pas moi.
"La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24
Ouais, juste pour tester effectivement.
"La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24
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é.
Dernière modification par Minuteman ; 02/02/2009 à 18h51.
"La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24
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.
fefe - Dillon Y'Bon
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