Encore un nouveau contrôleur pour disque SSD, Réactions à la news du 02-03-2009

[Lionel]

Source : Hardware.fr



Alors que l'industrie informatique est atteinte d'une morosité sans précédent, le marché des disques SSD continue à avancer à marche forcée et il ne se passe pas un jour ou presque sans qu'une annonce se fasse.
La dernière en date est assez importante. SiS, un fabricant de puces a annoncé deux nouveaux contrôleurs pour SSD. Ils sont capables de supporter de la mémoire SLC ou de la MLC. Ils seront déclinés en deux versions, le 815 capable de contrôler la mémoire sur 4 canaux, mais surtout le 820 qui supportera 8 canaux, gage de performances élevées puisque les données seront adressées à 8 puces en même temps.


Bonne nouvelle, ce contrôleur supportera également une puce de DRAM externe qui servira de cache, ce qui est extrêmement important pour assurer de bonnes performances lors de l'écriture de fichiers.

La crise économique semble bien jouer le rôle de catalyseur sur ce marché devenu très concurrentiel. A ce rythme, il devrait devenir accessible au plus grand nombre d'ici quelques mois.

[tutux]

il y a une puce DRAM, mais pas de batterie pour sauver la DRAM et finir l'ecriture sur la flash en cas de plantage / coupure de courant?

[aranaud]

il y a une puce DRAM, mais pas de batterie pour sauver la DRAM et finir l'ecriture sur la flash en cas de plantage / coupure de courant?

Comme sur les disques dur mécanique. Rien de choquant là dessus.

[Dj x-fuse]

D'où l'importance d'onduleur lorsqu'on traitre des données importantes...

Sinon pour en revenir au sujet, effectivement, d'ici quelques mois les SSD deviendront abordable pour pas mal de gens qui apprécierons la qualité de tel support physique.

Quid du cycle d'écriture sur les puces SLC / MLC ?

[SartMatt]

Quid du cycle d'écriture sur les puces SLC / MLC ?

100 000 effacements sur les SLC, 10 000 sur les MLC.

Sans wear-leveling, ça serait assez problématique, mais avec le wear-leveling, ça ne posera pas de problème, même en étant un gros bourrin (le Intel MLC est garanti 5 ans à raison de 100 Go écrits par jour, et d'après mes calculs, Intel s'est même gardé une très grosse marge sur ce point...).

[zeugme]

Cela me rappelle cet article (je ne sais plus ou sur le net) qui se évoquait une fragmentation constatée sur de tels disques après un usage conséquent : nombreuses installation/désinstallation.
J'ai été très surpris, que signifie la fragmentation sur ces disques ?
Que des données soit contiguës ou non, cela n'a ne devrait pas avoir d'impact sur les temps de réponses précisement sur les SSD

Qu'en pensez-vous ?

Sinon, 100Go par jour, ca peut aller très vite, surtout avec une activité de développeur et admin système. Entre les backups qui transitent pas la machines et les bases de données de tests et les ficiers de code liées aux build (effacement, compile, run), c'est un énorme volume relatif qui est créé chaque fois, même si peu de fichiers restent finalement sur le disque une fois la machine éteinte (d'une build sur l'autre, tout est effacé, mais cela fait quelques giga).
C'est en même temps précisément pour se type d'activité que le SSD devrait faire une grosse différence.

[elub88]

oué enfin tu vas pas enregistrer sur un ssd maintenant pour développer ou quoi, t'installes tes softs dessus mais tu enregistres sur un hdd classique.

[SartMatt]

Cela me rappelle cet article (je ne sais plus ou sur le net) qui se évoquait une fragmentation constatée sur de tels disques après un usage conséquent : nombreuses installation/désinstallation.
J'ai été très surpris, que signifie la fragmentation sur ces disques ?
Que des données soit contiguës ou non, cela n'a ne devrait pas avoir d'impact sur les temps de réponses précisement sur les SSD

Ça n'a pas d'impact sur les temps de réponse, mais la fragmentation existe quand même. De plus, c'est une fragmentation physique, pas une fragmentation logique.
En effet, contrairement à ce qu'on à avec un disque dur, sur un SSD, un fichier qui est en un seul fragment logique au niveau du système de fichiers peut se retrouver en plusieurs fragments physiques éparpillés un peu partout sur le SSD. C'est dû au wear-leveling, c'est inévitable, et à l'heure actuelle il n'existe pas de solution pour l'éviter, à part un formattage bas niveau (et encore, pas sur tous les SSD) pour tout reseter une fois de temps en temps.

Mais comme l'impact sur les performances est très faible, voir quasiment inexistant sur les SSD corrects (avec un contrôleur performant et doté de suffisament de cache), ça n'est pas vraiment problématique.

Sinon, 100Go par jour, ca peut aller très vite, surtout avec une activité de développeur et admin système. Entre les backups qui transitent pas la machines et les bases de données de tests et les ficiers de code liées aux build (effacement, compile, run), c'est un énorme volume relatif qui est créé chaque fois, même si peu de fichiers restent finalement sur le disque une fois la machine éteinte (d'une build sur l'autre, tout est effacé, mais cela fait quelques giga).

Pour les backups, c'est pas malin de les faire passer par un SSD : les backups, faut les faire sur les supports qui coûtent pas cher au Go, ça n'a aucun sens de les mettre sur un SSD.
Pour les build de gros projets, faut vraiment être un sacré gros bourrin pour arriver à 100 Go par jour... Si tu comptes une journée de 8h de travail, ça fait 12.5 Go par heure, donc même si ton build génère 2-3 Go de données, tu peux en faire 3-4 par heure sans soucis... Et des builds générant de telles quantités de données, ça m'étonnerait que beaucoup de gens en fassent plus de 3-4 par heure, vu le temps que ça doit prendre...

Dans le pire des cas, si on arrive vraiment à de tels volumes, la meilleure solution c'est de se mettre un ramdisk (vu les cours de la RAM, un ramdisk de 4 Go ça revient à moins de 50€...) et de mettre les fichiers temporaires du build dessus.

Accessoirement, plus le SSD gagne en volume, plus le volume d'écriture quotidien toléré est élevé. Par exemple, si Intel garanti le X25-M 80 Go pour 100 Go/jour sur 5 ans, alors on peut faire 200 Go/jour sur 5 ans ou 100 Go/jour sur dix ans avec un X25-M 160 Go (et en pratique, en faisant le calcul, sur un 80 Go, à raison de 100 Go par jour il faut plutôt 18 ans pour arriver à une usure moyenne de 9000 cycles par cellule, donc y a vraiment de la marge...).

C'est en même temps précisément pour se type d'activité que le SSD devrait faire une grosse différence.

J'avais testé sur un build du noyau linux sur une Ubuntu. Mon SSD est un peu plus rapide qu'un 7200 RPM, mais plus lent qu'un VelociRaptor pour cette opération. Mais les écarts sont globalement très faibles (cf http://forum.macbidouille.com/index.php?s=...t&p=2918575 ).
Et c'est relativement logique : sur un build, y a quand même énormément de travail niveau CPU, donc l'accès au système de fichiers est rarement limitant, surtout quand on build en multithreadé avec plus de threads que de coeurs (ce qui permet de compiler un fichier pendant qu'on attend la réponse du stockage pour la récupération d'un fichier).

Ce message a été modifié par SartMatt - 2 Mar 2009, 15:58.

[xpech]

J'avais testé sur un build du noyau linux sur une Ubuntu. Mon SSD est un peu plus rapide qu'un 7200 RPM, mais plus lent qu'un VelociRaptor pour cette opération. Mais les écarts sont globalement très faibles (cf http://forum.macbidouille.com/index.php?s=...t&p=2918575 ).
Et c'est relativement logique : sur un build, y a quand même énormément de travail niveau CPU, donc l'accès au système de fichiers est rarement limitant, surtout quand on build en multithreadé avec plus de threads que de coeurs (ce qui permet de compiler un fichier pendant qu'on attend la réponse du stockage pour la récupération d'un fichier).

Un build demande beaucoup d'accès disque en lecture, surtout des entêtes (.h), mais tout ça rentre dans le cache du disque. Je le vois bien le matin à la première compilation, ça broute (on entend bien le disque) puis dans la journée, terminé.

[Huby SEA]

Cela me rappelle cet article (je ne sais plus ou sur le net) qui se évoquait une fragmentation constatée sur de tels disques après un usage conséquent : nombreuses installation/désinstallation.
J'ai été très surpris, que signifie la fragmentation sur ces disques ?
Que des données soit contiguës ou non, cela n'a ne devrait pas avoir d'impact sur les temps de réponses précisement sur les SSD

Plutot flagrant cette article, pour ceux qui savent lire du Shakespear:
http://www.pcper.com/article.php?aid=669&a...xpert&pid=1

En plus il s'agit des disques Intel: réputé les plus rappides en se moment!!

Biensur Intel se défend toute de suite en disent que ses tests ne sont pas vraiment vrai:
http://news.cnet.com/8301-13924_3-10168084-64.html

Hmmm, et celle d'un MacBook Pro Unibody 17 pouce alors?? 10.000 écritures et puis point barre???

Huby