Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 32 sur 36 PremièrePremière ... 2224252627282930313233343536 DernièreDernière
Affichage des résultats 931 à 960 sur 1072

Discussion: SSD et mémoire flash

  1. #931

  2. #932
    Citation Envoyé par Stephane@Mat.be Voir le message
    Je peux lire une compilation de MP3 si tu veux...
    Remarque, c'est plus représentatif de l'utilisation d'un PC
    Bah sinon c'est hyper facile : tu prends tes 10 disques, tu fais 10 install de Linux, tu lances les tests. Si tu commences maintenant, t'as encore une chance de pouvoir publier ton article demain

  3. #933
    Citation Envoyé par newbie06 Voir le message
    Remarque, c'est plus représentatif de l'utilisation d'un PC
    Bah sinon c'est hyper facile : tu prends tes 10 disques, tu fais 10 install de Linux, tu lances les tests. Si tu commences maintenant, t'as encore une chance de pouvoir publier ton article demain
    je viens de faire lire ton post à ma femme. Elle est repartie en proférant des insultes, je me demande pourquoi

  4. #934
    Citation Envoyé par Stephane@Mat.be Voir le message
    je viens de faire lire ton post à ma femme. Elle est repartie en proférant des insultes, je me demande pourquoi
    Envoie-le matos chez moi, ma femme est en train de fabriquer des meubles, j'ai plein de temps là

  5. #935
    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

  6. #936
    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

  7. #937
    Arrêtez de le tenter, vous allez avoir un divorce sur la conscience...

  8. #938
    Citation Envoyé par newbie06 Voir le message
    Arrêtez de le tenter, vous allez avoir un divorce sur la conscience...
    Ca serait pas le premier sur ma conscience.


    Oups .
    fefe - Dillon Y'Bon

  9. #939
    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.

  10. #940
    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

  11. #941
    Citation Envoyé par Minuteman Voir le message
    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).
    There are only 10 types of people in the world: Those who understand binary, and those who don't.

  12. #942
    Ç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 à 14h15.
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  13. #943
    Citation Envoyé par Minuteman Voir le message
    Ç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.
    There are only 10 types of people in the world: Those who understand binary, and those who don't.

  14. #944
    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

  15. #945
    Je ne reponds pas a un mec qui dit qu'il faut du swap pour un OS

  16. #946
    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:
    #!/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
    Et le gentil contrôleur Samsung en question et le disque (d'un Lenovo x301):
    Dernière modification par Minuteman ; 02/02/2009 à 18h28.
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  17. #947
    Citation Envoyé par Minuteman Voir le message
    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):
    http://www.alphatek.info/divers/ssd/ssd.jpghttp://www.alphatek.info/divers/ssd/ssd2.jpg
    Merci. J'avais pas le temps de tester pour voir si la théorie rejoint bien la pratique....
    There are only 10 types of people in the world: Those who understand binary, and those who don't.

  18. #948
    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

  19. #949
    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

  20. #950
    Cette info vaut une news, les poussins, IMHO.
    Mes propos n'engagent personne, même pas moi.

  21. #951
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  22. #952
    Citation Envoyé par Minuteman Voir le message
    tout ça en ajoutant "elevator=noop" au démarrage du kernel.
    Y'a plus simple :
    Code:
    echo noop > /sys/block/sda/queue/scheduler

  23. #953
    Ouais, juste pour tester effectivement.
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  24. #954
    Intéressant tout ça. Qui s'y colle pour en faire une news ? :P

  25. #955
    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 à 19h51.
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  26. #956
    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

  27. #957
    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.

  28. #958
    J'aimerais bien voir le meme test avec make -j 2 et -j 3 puisque tu as un dual-core...

  29. #959
    Citation Envoyé par Doc TB Voir le message
    Intéressant tout ça. Qui s'y colle pour en faire une news ? :P
    Si je trouve comment on fait pour faire une news, je m'y colle tout à l'heure...
    Mes propos n'engagent personne, même pas moi.

  30. #960
    Attends les résultats de la compilation parallèle, ça sera une bonne indication supplémentaire je pense

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •