Bonjour.
 
J'ai fait l'acquisition d'un ssd corsair f120 fin avril à l'occasion d'une promo.
Il a été installé sur une P5Q-E sous windows 7 64 AHCI/trim activé (après deux-trois semaines en mode IDE).
 
Le moins que l'on puisse dire c'est que les débits en écriture sous crystal disk mark sont décevants:
 

 
surtout en comparant à ce qu'obtient un membre concernant le f115
 

 
sur ce topic:
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 
Aucun des sujets postés sur le f120 sur hfr ne traite de ce problème.
Un ou des experts du ssd pour me donner une piste?
 
merci.  

Tout se situe dans le 0x00 Fill  
 
Par contre, je sais pas comment y remédier...
 
Au cas où, cherche des cmparaisons ATTO, tu devrais déjà avoir des scores normaux

 
Peux tu préciser (en terme de signification à défaut d'y remédier)?
 
J'ai les mêmes mauvais résultats sous AS SSD benchmark.
 

 
(31K BAD)?

Non ça me parait pas.
 
Windows7, à moins que tu aies gardé la partition de XP, aligne correctement pour la mémoire flash... * Si tu as reformaté la partition XP sans la recréer je crois bien qu'il y a le problème de 63 secteurs... à voir*
 
 
Les contrôleurs Sandforce compressent en hardware les données, à l'écriture, et donc ont besoin de moins de "flashage" pour débiter autant que la câble SATA.
A la lecture, bien sûr le phénomène se répercute.
 
Le 0x00 Fill spécifie à Crystal de ne pas mettre de données aléatoires et donc peu compressibles  
 
 
Le truc maintenant, mais je connais pas assez AsSSD, c'est que si tous les benchs te donnent moins bon c'est donc peut-être bien aussi un souci d'alignement de cluster....
Regarde avec Dispar sans "t" sous fenêtre DOS  
diskpar -i 0     (Zéro)
 
Si tu as 63 hidden sector c'est pas bon.
 
Deux solutions :
- Backup d'une image et recopie avec une bonne indexation.
- Changer la taillle de cluster à 512k comme ça il n'y aura aucun cluster qui n'écrive sur deux pages de flash. *Ceci est mon expérience personnelle   *

Oulà ça fait pas mal de nouvelles infos à "digérer".
Je vais analyser à présent tout ça calmement car je débarque dans le monde du ssd.    
 
Pour le système c'est un copier/coller du système qui résidait sur un (vieux) disque PATA avec un log genre drive image. Ceci explique peut être celà...
 
les commandes [dispar] et [diskpar] ne sont par reconnues par mon système.    
 

 
Quoi qu'il en soit merci pour les pistes que tu m'as données et n'hésite pas à me faire part d'autres idées que tu aurais sur le sujet.
 
[edit]
Je n'avais même pas capté que diskpar est un exe ne fait pas partie du système et se récupère à part.  

J'ai réaligné les clusters et secteurs avec paragon alignment tool. ---> HiddenSectors = 4096
 
Les débits d'écriture sont un peu mieux quoi qu'encore insuffisants masi il y a eu un saut énorme de perfs pour la partie 4K QD32(?) ainsi que l'écriture des blocs 4k.
 
Avant

 
Après

 
Je continue à chercher...

Essaye de trouver comment mettre Crystal en 0 fill  
 
La solution est dès le 2è post ici : http://forum.hardware.fr/hfr/Hardw [...] 2703_1.htm  
 
Je crois bien que le problème ne sera plus très bientôt

QD32 c'est l'option NCQ...
 
En 4K aléatoire, un par un, Crystal fait des accès de partout sur le disque et regarde la vitesse pour les lire/écrire.
 
Queue Dept 32 veut dire que y a 32 commandes simultanées faites par Crystal.
Si le SSD a prévu cette éventualité (qui est bien réelle en multitask) alors.... disons que le contrôleur s'est équipé d'hyperthreading, et gère plusieurs tâches à la fois (et va plus vite )

La méthode de bench impacte effectivement les résultats.    
En 0 fill (se passe de commentaires):
 

 
Quoi qu'il en soit merci j_camelet pour toutes les précieux conseils et informations fournis.
Grace  à toi je suis un peu moins noob en techno ssd.
 
Au passage le 31k bad sous as ssd benchmark indiquait bien un mauvais alignement.
 

En 0 Fill on mesure la vitesse de l'interface, pas celle du SSD vu qu'il comprime celui là .