Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 33 sur 36 PremièrePremière ... 23252627282930313233343536 DernièreDernière
Affichage des résultats 961 à 990 sur 1072

Discussion: SSD et mémoire flash

  1. #961
    Citation Envoyé par Alexko Voir le message
    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.
    en soi, ça ne rendra jamais un mauvais SSD meilleur...

  2. #962
    sous Windows, y a des trucs comme ça aussi :D

    Sur carte mémoire, le FAT16 avec clusters de 64 Ko accélère vachement certaines cartes, par exemple.

    Et en NTFS, la gestion des petits fichiers (moins de 1 Ko) est différente et ça accélère violemment aussi par rapport à la FAT classique (stocké en MFT ou un truc comme ça).

  3. #963
    Ouaip, attends seulement, c'est en cours.
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  4. #964
    Citation Envoyé par Stephane@Mat.be Voir le message
    en soi, ça ne rendra jamais un mauvais SSD meilleur...
    Bah non c'est sûr, mais ça permet au moins de l'utiliser de façon optimale. C'est clair que ça ne rachètera pas le Crucial que tu as testé

  5. #965
    Citation Envoyé par Neo_13 Voir le message
    Si je trouve comment on fait pour faire une news, je m'y colle tout à l'heure...
    J'ai pas le pouvoir, çaybaysay donc.
    Mes propos n'engagent personne, même pas moi.

  6. #966
    Bon, résultats surprenants et théorie viable en approche

    J'ai tout d'abord refait les benchmarks avec un simple "make" tant en mode NOOP qu'en CFQ, les résultats à ce niveau sont confirmés avec un pic de gain à 17% pour le mode NOOP. Notez qu'entre chaque test je supprime le dossier du kernel et je reboot la machine.

    J'ai ensuite attaqué une nouvelle série de benchmarks (2x chacun également) en faisant un "make -j 3", ce qui veut dire que je lance 3 threads en parallèle, la règle admise étant généralement "nombre de cores + 1" pour cette option. Là, c'est le drame. Les enfants pleurent, les mamans sont obligées de se prostituer, Stéphane redevient consultant SAP et newbie06 est obligé d'utiliser Windows, bref, les résultats s'inversent carrément en faveur du CFQ.

    Les résultats en -j 3 sont:
    1481 et 1566 secondes pour le NOOP
    1202 et 1256 secondes pour le CFQ
    Soit respectivement 23 et 24% de différence en faveur du CFQ.

    Pourquoi? Mais pourquoiiii? A cause du contrôleur du SSD qui est à la rue je pense, théorie soumise par braoru:

    (10:45:50 PM) braoru: ton contrôleur SSD il est fait pour de l'accès séquentiel
    (10:46:03 PM) braoru: en fifo c'est je prend un fichier, je te le donne..
    (10:46:08 PM) braoru: avec 3 threads c'est .. je veux un bout de fichier
    (10:46:16 PM) braoru: puis j'arrête, je vais voir ailleurs, je prend un bout, après j'arrête.
    (10:46:30 PM) braoru: la le CFQ va faire comme il fait d'habitude, il va essayer de limiter trop de déplacement et ta géométrie de SSD qui a rien a voir est un facteur mais statistiquement tu a surement plus de collage de blocs que de dispersion totale
    (10:47:20 PM) braoru: donc le CFQ maintien les lectures et tu te retrouve avec plus de linéarité

    La théorie se tient, vous en pensez quoi? Entre le best case et le worst case, on a une putain de variation de l'ordre de 25% des résultats quand-même. La seule conclusion qu'on peut visiblement en tirer, c'est que sur UN type de SSD, un scheduler I/O est bien plus performant qu'un autre selon l'usage spécifique de sa machine. En utilisation desktop normale, le NOOP a l'air d'avoir l'avantage.
    Dernière modification par Minuteman ; 03/02/2009 à 01h17.
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  7. #967
    Non je passe pas à Windows, je m'attendais à ce résultat

  8. #968
    Tu confirmerais la théorie?
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  9. #969
    Franchement je ne sais pas.

    Tout ce que je peux dire c'est que le scheduler mis par défaut doit être bon et que Linux depuis un moment s'oriente vers le SMP. Donc quand tu ajoutes le fait que Torvalds depuis des mois utilise un SSD, au fait que Linux est bien optimisé pour les IO sur les SMP, je ne suis pas étonné ; mais ça reste de l'intuitif

  10. #970
    tiens, question de FS, MS vient de proposer exFAT pour Windows XP. Ca peut etre intéressant pour les clés USB, vu les résultats de Stéphane sur la Corsair.

    http://www.ghacks.net/2009/01/29/win...system-driver/

  11. #971
    Pour la différence en multithread, en fait, c'est pas une question de collage de bloc ou pas, je pense, mais plus qu'il doit effectuer des écritures plus souvent.

    en mode fifo, il écrit directement chaque truc quand un des threads lui envoie, que ça fasse 1 Ko ou 200 Ko. En mode CFQ, c'est regroupé, donc y a des chances qu'il ait des plus gros trucs à écrire à chaque fois. Et comme l'écriture de 128 Ko (ou 256 Ko, selon les modèles) prend en gros le même temps que l'écriture de 1 Ko (fonctionnement en blocs), ça doit jouer. C'est pas le fait que ce soit des blocs proches ou pas, c'est qu'il écrit plus d'un coup en CFQ.

  12. #972
    je pense que la géométrie du disque est en effet un facteur très faible dans le cas présent. (et de toute façon j'imagine (je suppose, mais ça me semble le plus logique) que CFQ n'utilise plus vraiment de géométrie physique mais une géométrie virtuel ).

    Par contre le "Complete Fair Queuing" fait tous son possible pour rendre les collisions inexistantes. A mon avis ceci joue beaucoup dans l'aspect séquentiel des accès sur les fichiers lors de la compilation.

    Au final j'imagine que ça doit être quelque chose de bien plus complexe qui mélange ton explication, celle si dessus et sûrement d'autres choses comme l'interprétation que CFQ se fait du disque qu'il imagine comme un disque classic dont la géométrie est virtuel ou ses options de priorités.

    We should treat all the trivial things of life seriously, and all the serious things of life with sincere and studied triviality.[Oscar wilde]

    There is no such thing as a moral or an immoral book. Books are well written, or badly written. That is all.[Oscar wilde]

    No artist is ever morbid. The artist can express everything.[Oscar wilde]

  13. #973
    En bref, si on avait la possibilité d'avoir un scheduler qui gérait directement les écritures par bloc de 64ko (ou 128ko selon la taille) on récupérait des perfs perdues à cause d'un controleur pourri

  14. #974
    Suite à un lecteur qui m'a alpagué à propos de mon test sur les SSD à base de JMIcron paru hier, j'ai affectué des tests ce matin. Le débat portait sur le fait que les partitions des SSD que j'ai testés n'étaient pas alignées. Utilisant Vista pour mes tests, il est supposé aligné les partitions. Mais selon ce lecteur, ça changeait tout. Donc voici mes observations :

    Victime : SSD CSX 128 Go (MLC+JMicron JMF602 "B" ).

    Infos de la partition créée classiquement sous Vista :

    StartingOffset : 1048576
    Hidden Sectors : 2048

    Après avoir suivi la procédure de création d'une partition alignée avec un starting offset de 128 Ko, voici les infos de cette partition :

    StartingOffset : 65538
    Hidden sectors : 128

    En termes de perfs, ça n'a strictement rien changé à quelques Ko/s près.

    Voici les perfs de CrystalDiskMark avant l'alignement :


    Sequential Read : 169.316 MB/s
    Sequential Write : 96.120 MB/s
    Random Read 512KB : 143.902 MB/s
    Random Write 512KB : 43.066 MB/s
    Random Read 4KB : 18.479 MB/s
    Random Write 4KB : 1.810 MB/s

    Test Size : 1000 MB
    Date : 2009/02/03 10:06:45

    Même tests après alignement :

    Sequential Read : 168.690 MB/s
    Sequential Write : 95.752 MB/s
    Random Read 512KB : 141.957 MB/s
    Random Write 512KB : 43.024 MB/s
    Random Read 4KB : 18.077 MB/s
    Random Write 4KB : 1.848 MB/s

    Test Size : 1000 MB
    Date : 2009/02/03 12:01:30

    Les tests de transferts de fichiers moyens et petits ne donnent pas de différences non plus.

    Bref sous Vista, l'alignement semble être bine effectué. Sous XP, c'est une autre histoire.

  15. #975
    Effectivement si l'OS n'est pas capable d'aligner la partition sur la taille du bloc ca ne serait vraiment pas drole (force de doubler les transferts sur des acces random de la taille d'un bloc), mais je suis surpris qu'il y ait des OS qui n'alignent pas sur des gros blocs des le debut.
    fefe - Dillon Y'Bon

  16. #976

  17. #977
    Le driver exFAT (ou FAT64) pour XP est sorti (cf actualité de Dandu sur THFR), quid de l'alignement des secteurs avec ?

  18. #978
    Citation Envoyé par Stephane@Mat.be Voir le message
    Windows XP ne le fait pas d'où ce genre de topics sur le forum OCZ :

    http://www.ocztechnologyforum.com/fo...ad.php?t=48309
    Tout OS qui respecte les normes... ne le fait pas.
    Par convention, la première partition débute au secteur 63.
    Je parierai que Linux fait de même, puisqu'on aligne à la main les partitions sur un env VMWare vers SAN EMC.
    There are only 10 types of people in the world: Those who understand binary, and those who don't.

  19. #979
    Bon, pour ma part j'ai abandonné (ptête pas définitivement) l'idée de booter sur une CF vu que rien n'est foutu de booter dessus: échec avec Debian, Mandriva, et BSD (FreeNas plus précisément). Il ne me reste guère que vindoze à tester, mais juste à tester alors...
    Même un live-CD sur la CF ne boote pas.

  20. #980
    Une des raisons pour lesquelle je n'aime pas (alors pas du tout) Sony :
    Encore un nouveau format de carte MS :
    http://www.lesnumeriques.com/news_id-7554.html
    http://valid.x86-secret.com/cache/banner/313021.png

  21. #981
    (troll) C'est exactement pour cela que je deteste MS qui cree ses propres standard soft.

  22. #982
    Ca fait tellement longtemps que je refuse d'acheter du Sony, ou alors seulement du Sony avec des standards. Et tellement longtemps que je peste après cette bande de [auto-censure] qui s'ils sortent du bon matos refusent de respecter les désidératas du plus grand nombre, mettant souvent le consommateur lambda dans une panade absolue quand il faut trouver de quoi aller dans son [insérez ici un quelconque appareil électronique].

    S'ils n'avaient pas remporté le combat de la HD (victoire que j'ai encore du mal à expliquer en un sens), n'auraient-ils pas au contraire de Toshiba, refusé d'admettre leur défaite et ouvert un marché parallèle, dans le même genre de celui qu'ils entretiennent actuellement avec la flash ?


    Edith: pour le coup, je suis content d'avoir trouvé un article sur un site extrêmement consulté qui va dans mon sens...
    Dernière modification par Aerin ; 06/02/2009 à 23h15.

  23. #983
    Un peut en complément à celui de Marc, AnandTech publie un article (j'ai pas finit mais pou le moment assez bien fait) sur les ssds.
    http://www.anandtech.com/storage/sho...spx?i=3531&p=1

    Je pense que en termes généraux de performances (quantitatives, qualitatives et surtout d’expérience à l’utilisation) on passe un palier.
    Avec l’arrivée des nouveaux contrôleurs (pour certains des problèmes restants correctibles ou en tous cas réductibles) et des nouvelles révisions d’interfaces on va d’ici pas trop longtemps pouvoir bien se marrer :D
    Dernière modification par braoru ; 18/03/2009 à 13h33.

    We should treat all the trivial things of life seriously, and all the serious things of life with sincere and studied triviality.[Oscar wilde]

    There is no such thing as a moral or an immoral book. Books are well written, or badly written. That is all.[Oscar wilde]

    No artist is ever morbid. The artist can express everything.[Oscar wilde]

  24. #984
    Le problème c'est que la dégradation des performances ne sera jamais uniforme mais dépendra de l'usage qui est fait du SSD. Perso, je fais un secure erase avant de bencher un SSD. Au moins, on a les perfs "pures", après si ça se dégrade, c'est une autre histoire...

  25. #985
    Tu ne pense pas qu’en améliorant les FS, l’architecture du SSDs, leurs contrôleurs et méthodologies d’affection il soit possible d’améliorer le maintien des performances ?

    We should treat all the trivial things of life seriously, and all the serious things of life with sincere and studied triviality.[Oscar wilde]

    There is no such thing as a moral or an immoral book. Books are well written, or badly written. That is all.[Oscar wilde]

    No artist is ever morbid. The artist can express everything.[Oscar wilde]

  26. #986
    Le vertex revu et corrigé a l'air plutot sympatique (modulo la perte de jusqu'à 64Mo en cas de coupure de courant )

  27. #987
    Citation Envoyé par Stephane@Mat.be Voir le message
    Le problème c'est que la dégradation des performances ne sera jamais uniforme mais dépendra de l'usage qui est fait du SSD. Perso, je fais un secure erase avant de bencher un SSD. Au moins, on a les perfs "pures", après si ça se dégrade, c'est une autre histoire...
    Justement c'est l'apres qui est interessant. Les perfs en conditions ideales, on s'en tape juste un peu sauf si c'est une histoire de kikitoudur et qu'on ne se sert pas de son PC.
    Avis perso toussa toussa

  28. #988
    Citation Envoyé par braoru Voir le message
    Tu ne pense pas qu’en améliorant les FS, l’architecture du SSDs, leurs contrôleurs et méthodologies d’affection il soit possible d’améliorer le maintien des performances ?
    Ben ça va pas mal dépendre des sous cpu ARM qui gèrent le cirque.
    Mes propos n'engagent personne, même pas moi.

  29. #989
    Citation Envoyé par newbie06 Voir le message
    Justement c'est l'apres qui est interessant. Les perfs en conditions ideales, on s'en tape juste un peu sauf si c'est une histoire de kikitoudur et qu'on ne se sert pas de son PC.
    Avis perso toussa toussa
    Oui, tout à fait. Mais lors des tests, on voit tout de suite lesquels perdent des perfs à l'usage. Genre l'Intel, un bon IOmeter dans sa tête et c'est réglé. C'est le seul passé entre mes mains qui a ses perfs qui se dégradent. Les autres non.

    Ce qui compte aussi c'est la courbe des débit selon la taille des fichiers traités. Car il n'y a pas que les perfs d'un disque usé qui priment. Si les perfs "pures" sont pourries à la base, autant prendre un qui a pas des perfs pourries car s'il y a dégradation, il aura toujours plus de perf que le SSD moisi.

    Enfin vous verrez demain mon comparo de 5 SSD avec de nouveaux graphes inclus dans mon protocole ce que je veux dire.

  30. #990
    C'est pas humain les teasing comme ça !

    Mes Lego - Tof : Canon EOS 40D + Tamron 17-50mm F/2.8 + Canon Seepdlite 430 EX II | VDS MadCatz Arcade Fight Stick TE

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
  •