Reprise du message précédent :
Apparement les news sur les nouveaux ssd OCZ sont fausses. C'est 120 en lecture mais 40 en ecriture pour ces ssd abordables. Sinon c'est beaucoup plus cher. http://www.techarp.com/showarticle [...] 550&pgno=7 tout en bas.

Parce qu'une fois tout chargé en RAM, le disque ne sert plus à rien, c'est le reste de la machine qui prend le relais. Tu chargeras tes niveaux plus vite, c'est tout, mais ça ne sera pas plus réactif.

ok merci pour vos reponses
 asmomo je voulais dire économique nivo consommation pas niveau portefeuilles

 
Alors j'ai pas l'habitude de troller quand je m'intéresse à une technologie que je voudrais acheter pour mettre dans mon PC, mais quand je vois ceci :
 

 

 

 

 
Je me dis que pour les 2/3 secondes que j'attendrais en moins sur plus de 30 secondes de chargement de niveau ce serait dommage de me ruiner dans un SSD pour y mettre des jeux dessus...    
 
 
 
 
 
Et quand je vois cela :
 

 

 
 
Je me dis que mon Office peut aussi aller sur le velociraptor.    
 
Pour contre ici :
 

 

 
On peut déjà constater les avantages du SSD.    
 
 
D'ou mon idée, sans avoir jamais pu tester de SSD d'avoir un disque système en SSD de 32 Go (pour être à l'aise avec Vista 64 bits au cas où), d'avoir un vélociraptor 300 Go pour installer les jeux, office ou j ene sais quoi et un gros dur de 1 Tera pour le stockage...
 
 
PS : anadtech est le seul site à ma connaissance à proposer des bencmarks d ela "vraie vie" : temps de boot en secondes, temps de charement d'un jeu en secondes et pas seulement des benchs synthétiques qui donnent des résultats que l'on en retrouve pas toujours dans la vie réelle...un peut comme 3D mark quoi...    
 

 
Oui mais c'est faux, ça consomme pas moins qu'un DD.

Pour le file copy, je ne sais pas si ça a vraiment à voir avec Office...

oueh enfin y a jeux et jeux
 
c est sur qu'un jeu ou t'as juste 3,4 gros fichier de 300Mo à chargé (exemple grossier)
le ssd il va t apporté que dalle
 
mais un jeu avec plein de fichier partout à cause de mods entre autres (oblivion ?)
ou un truc genre flight simulator moi je demande à voir si avec tout les fichier qu il y a partout dans le dossier du jeu y aurait pas un gain
 
bref des jeu ou tu peu foutre des milliers de modeles de bateau, d avion, de bagnole  
bref des jeux ou tu peut bricoler (ça reste l avantage de l ordi par rapport à la console... des mods gratos pour un nombre consequent de jeu)
 
faudrait pouvoir tester quoi

 
Et inversement je pense qu'Office est plus agréable sur un SSD.

 
quel interet de balancer des resultats qui sont +ou - synthetiques car ne mentionnant pas la config et la maniere dont est installé le systeme... Il y a des tas de trucs qui ralentissent des chargements d'appli ou de jeux selon ta config (Antivirus, imagine l'impact sur un hdd comparé à un ssd si le jeu se met à lire / ecrire pendant que l'a/v check des fichiers).... Autre cas : Tu lis des mp3 pendant que ça charge ton jeu ... comparont quand c'est sur le meme hdd/ssd comparé à 2 hdd / ssd différents pour chaque (mp3 / jeu).

Et de loin, je trouve.

Ouais bon j'abandonne. Maho-Kun m'a tuer lol...  
Si tu as envie de faire des tétrachiées de benchs pas synthétiques follment détaillés OK je prends si tu fait mieux qu'Anandtech.
Pour les confis utilisées va voir sur le site, Anandtech les donne.
 
Et sinon j'écoutes pas de mp3 quand je joue à un jeu => il y à déjà de la musique dedans...
 
 
 
Sinon Office sur SSD j'y crois vu qu'il est vrai qu'on ouvre des applis/fenêtres. Et qu'on ne s'amuse pas à faire des copies de gros trucs sous office (c'est là que j'aimerais qu'Anandtech s'explique sur le chois de leur méthode pour office...)
 
Je suis convaincu de la performance des SSD mais pour le moment on a quand même le droit de les challenger avec les autres solutions du marché non ?
 
Le juste beoin pour chaque chose ça s'appelle.
 
Après évidememnt quand on est pété de thunes, on s'en fout, on prends le best of the best.
 
 
 

Je suis un homme de science, je ne crois pas en la magie et je crois que mon SSD déconne, ou alors tu peux me le dire, les tests qui montrent que le SSD est "saint" sont des tests effectué dans les même conditions CAD demarrer hdtune et ne rien toucher pendant le test?

Par contre pour le raid SSD DD, pourquoi ca serait stupide? Windows a une fonction ready boost (qui à l'air de fonctionner avec n'importe quel type de "disque" ). Sur le site il est dit que les performances seront amélioré mais qu'il faut pas s'attendre à la même chose qu'avec deux disques pareil.

Muahaha, dans un sens c'est chiant dans un autre j'aurais pas payé trop cher mes ssds ...question de temps je pense...

Parce que les perfs de la grappe dépende du nœud le plus lent, le contrôleur devant attendre les datas des deux nœuds en lecture ; et en écriture le contrôleur devant attendre la fin des deux écritures sur les deux disques avant de pouvoir exécuter une autre commande. Ex en raid0 SSD + HD, tu aurais le temps d'accès du HD + un delta dû au contrôleur, et deux fois le débit du HD : gros gaspillage du SSD.

Et encore tu es optimiste, à mon avis les 2 seraient tellement désynchro que les perfs seraient calamiteuses.
 
C4_4 : le RAID c'est qqchose de précis, qui n'a rien à voir avec readyboost, disques hybrides et compagnie.

c'est pire sur les ssd, sauf le mtron :

 

Ouais enfin "les" ssd, il manque les Memoright, les nouveaux SuperTalent, les nouveaux Samsung...

 
c'est normal que les graphs HDTune sont bizarres si tu utilises le PC en même temps    
C'est un test synthétique qui stresse le disque, quand tu fais un autre truc, il doit changer de bloc de lecture et donc t'as une perte à ce moment là.
 
Et oui, le SSD/DD c'est stupide, vu qu'on synchronise le tout sur le plus lent.  
 
Et Ready Boost, en dehors du fait que ça fonctionne juste super mal (ça apporte quasi rien), ça a rien en rapport avec du RAID : c'est utiliser une carte mémoire/clé USB comme cache pour certains accès en lecture (uniquement).

Ou en un seul mot : c'est un cache.

Faudra qu'on m'explique quelque chose quand même avec les SSD. Comment, à débit égal à un bon DD mécanique, et à temps d'accès divisé par 10, on peut avoir de mauvaises perfs sur l'écriture de multiples petits fichiers ?

Parce que les accès à la mémoire flashs se font par bloc, et que plusieurs petits fichiers sont regroupés dans un seul bloc pour ne pas gaspiller de place.

Donc quand on écrit un petit fichier, on lit un bloc, on le modifie, puis on l'écrit à nouveau. Au lieu de seulement écrire un bloc complet dans le cas d'une écriture plus grosse.

Ok donc faut que les contructeurs et la presse arrêtent de nous balancer les caractéristiques débit lecture/écriture et temps d'accès. Cet inconvénient d'écriture aléatoire de petits fichiers lentissime n'est que trop peu mis en avant.  
 
Au final on se retrouve avec une techno qui met potentiellement les dd mécaniques à la retraite (je ne parle pas du rapport prix/perf) mais qui, lors des tests, s'avère quand même pas si meurtrière que ça.
 
Sachant que je suis un personne qui peut mettre beaucoup d'argent pour avoir une techno avant gardiste et me faire plaisir, dans le cas des SSD, le gain est vraiment trop faible à mes yeux.
 
Pour être extrêmiste, je dirais que les fabricants de SSD devrait proposer 2 firmwares :
 
- un qui optimise les petites données dans un block au détriment des perfs pour gagner en place (actuellement le cas si j'ai bien compris)
- un autre qui gâche l'espace du block pour un simple petit fichier mais dont les perfs ne s'effondrent pas en écriture pour l'écriture de ces fichiers.
 
 
J'aimerais votre avis là dessus.

Article de matbe sur l'utilisation pendant 1 mois d'un SSD de qualitaÿ :
 
http://www.matbe.com/articles/lire [...] d-verdict/
 
Bilan : c'est de la balle mais 1000 €      
 

C'est un peu comme un raptor par rapport à un disque en 7200trs/min. Même si c'est pas une révolution dans les benchs, c'est toujours plus agréable avec.

 
 
Apparement puces MLC selon le forum d'OCZ  

pt etre un reponse à la lenteurs des ssd en sequenciel.... un nouveau systeme de fichier qui prepare les block pour une ecriture direct... :
http://linuxfr.org/2008/04/04/23938.html

Biensur pour windows... ca va prendre du temps mais je ne pense pas que crosoft se laisse vite distancer, et puis il parait qu'avec le depart de billou, crosoft serait plus à l'aise avec l'interropérabilité... alors pt eutre un FS identique supporté par tout le monde ?

 
 
t'as la serie 7000 chez mtron à 755€ en 3,5" au lieu 1000€ aux caracteristiques "similaires"
 
ou un peu moins veloce à 555€la serie 3000
 
bref les prix on tout de meme baissé pour les 64Go faut pas charier et ce sans se retrouver avec de la memoire mlc de merde ultra lente

 
 
Ya pas de topic ou de post sur les bons plans en SSD ? Parceque je viens de regarder sur mat.net et le mobi 3000 64 Go est quand même encore à 830 euros et le mobi 7000 64 Go à 1300 euros...      
 
 
 
 
 

Quelqu'un a des infos sur les SSD transcend 32GB ou 64GB
 
Débit 116MB/s en lecture et 38/42 MB/s en écriture.  
 
Par 3 c'est 159EUR/229 EUR
 
Donc un RAID 0 de 3*32GB ou 2*64GB c'est plus ou moins le prix d'un RAID 0 de v'raptor et espace suffisant pour un disque système. Les 600GB du raid vraptor sont pour moi inutiles. Impossible à sauvegarder facilement ...  Donc seulement 100 seraient utilisés en laissant 500GB de swap, dossier de travail temporaire, ... mais largement sous utilisé.
 
 
 
 

 
La gestion de la mémoire flash en bloc.
 

 
Rien à voir, j'explique apres.
 

 
T'es parti d'un constat faux, donc essai faussé.
 
 
Concrètement :
 
Un SSD travaille avec de la mémoire organisée en blocs (typiquement 128 Ko, de plus en plus souvent 256 Ko) organisée en pages (typiquement 64 pages)
 
Quand on lit une donnée, on lit par pages : par bloc de 2 ou 4 Ko, donc. Le temps de lecture d'une page est fixe, que les données fassent 1 octet ou 2 Ko. Comme on lit rarement des fichiers de moins de 2 Ko, on voit pas la différence.
 
Quand on écrit une donnée, c'est au niveau du bloc. Vu la façon de fonctionner de la NAND, on doit écrire entièrement un bloc même si on n'écrit en pratique que 1 octet. L'écriture d'un bloc prenant toujours le même temps, écrire réellement 1 octet ou 128 Ko prend exactement le même temps, ce qui donne l'impression que l'écriture du fichier de 1 octet est lente. Et des fichiers de moins de 128 Ko, c'est courant. Dans le cas d'un gros fichier, la différence est négligeable pour se faire ressentir.  
 
Comme on va vers des blocs plus gros, le problème va s'amplifier. Note aussi que travailler avec un système à base de petits clusters (genre NTFS avec cluster de 2 Ko) a tendance a diminuer un peu les perfs en écritures.
 
Y a pas de façon réelle de modifier le problème, en dehors de limiter la taille des blocs (mais c'est le contraire qu'on vise) ou de changer de techno de flash. Faut s'y habituer, la Flash NAND a ce problème et ça changera pas, c'est juste masqué par une vitesse en écriture de base très élevée.

Est ce qu'une conception à base de blocs de tailles différentes corrigerait en partie cet inconvenient ?
 
Si je comprends bien, l'agrandissement des blocs vise à améliorer les perfs et diminuer le coût en même temps. En utilisant au sein d'un même SSD un espace minoritaire en capacité composé de petits blocs pour les petits fichiers et d'un autre côté des blocs plus grands qui ne seront pas pénialisant pour les gros fichiers. Le controleur pourrait ainsi attribuer les écritures plus intelligemment en fonction de la taille. J'ai donné 2 tailles en exemple mais pourquoi pas N sans tomber dans l'excès.
 
Possible ? Utile ? Trop compliqué ? Ou je suis passé à côté une fois encore ?

Trop compliqué et pas viable : si t'as vraiment bcp de petits fichiers, comment on divise ?
 
La seule solution actuelle c'est d'augmenter violemment les perfs de base et donc mécaniquement de masquer le problème : ça va moins vite en petits fichiers mais le moins vite reste rapide.
 
Sinon, mettre un cache devrait permettre de masque les écritures, mais faut quand même vider le cache à un moment, donc bof.
 
Faut bien se dire aussi que les contrôleurs des SSD ont déjà pas mal de boulot, donc faut pas essayer de rajouter des trucs (ça joue sur la conso, de mettre un CPU ARM dans un support de stockage)

imho il faudrait surtout un cache et une fonction type NCQ.

edit : grillé

I have a dream....  
Edit : Dandu tu oubli la gestion par un FS adequat, ca pourrait pas gerer le cache en ram pour une ecriture  diffuse dans le temps et donc masquer le blem sans pour autant avoir un vrai chache dans le ssd ?

 
Moins de fiabilité dans les écritures, il faudrait une batterie et une pile.

 
j ai filé des liens y a en gros 1 page pour un site ou j ai déjà commandé du matos

Salut , je suis entrain de tester une CF 280x OEM sur mon portable avec ubuntu .
Ca me reboot apres Grub loading stage 1.5 !
Avec une sandisk ultra 2 ca marche .
C'est quoi la différence ?
 

 
 
et c est quel marque model ta 280x ? une no name

oui mais elle a l'air d'avoir du débit : 26mb/s  en UDMA2

pas mb/s mais MB/s