http://static.pcinpact.com/images/smiles/rouge.gif
 
PC INpact...
 
http://static.pcinpact.com/images/ [...] apello.gif
 
 
 
http://static.pcinpact.com/images/smiles/francais2.gif
Anti-HS: Avec un peu de chance, les Ridata tiendront les specs annoncées, ce que n'ont pas l'air de faire (sur les rares benchs dispos pour l'instant) les OCZ Core Series...

 
bizarre le graph pour le write quand meme...
 
comment les perfs se cassent la gueule, j espere que c est un bug parce que sinon c est a chier  
 
en read les dents de scie doivent être du au faite que l OS est installé dessus
 
pour l acces a 0.4ms c est un peu au dessus des specification d OCZ mais ca va

ton système est dessus ?

Bon a quand ce controleur magique sur du SLC ?

A ce train, le bus SATA va rapidement être saturé    
 
Son évolution est prévue pour quand?

Les perfs en écriture pourraient être dues à une mémoire cache évitant au SSD de bloquer le disque et le PC lors d'écriture. Ce qui expliquerait le début de la courbe.
Si c'est le cas, on s'en fout, à part pour bencher

Bon a quand ce controleur magique sur du SLC ?

ton système est dessus ?

Les perfs en écriture pourraient être dues à une mémoire cache évitant au SSD de bloquer le disque et le PC lors d'écriture. Ce qui expliquerait le début de la courbe.
Si c'est le cas, on s'en fout, à part pour bencher

Je suis pas super aware sur le fonctionnement dans le détail des SSD mais quelqu'un pourrait m'expliquer en quoi :
- le graphs dégeulasse des perfs en écriture du OCZ CORE n'est pas un problème
- que c'est dû ou pas à ce que son OS soit installé dessus (genre ça influe les résultats du test)
- qu'est ce que ça donne avec un raptor sur lequel est installé l'OS lui aussi

A partir de ce moment là je commencerais à y voir un peu plus clair parceque je n'ai pas d'éléments de réponse probants à la lecture des posts sur le forum  

 
 
Je suis pas super aware sur le fonctionnement dans le détail des SSD mais quelqu'un pourrait m'expliquer en quoi :
- le graphs dégeulasse des perfs en écriture du OCZ CORE n'est pas un problème
- que c'est dû ou pas à ce que son OS soit installé dessus (genre ça influe les résultats du test)
- qu'est ce que ça donne avec un raptor sur lequel est installé l'OS lui aussi
 
A partir de ce moment là je commencerais à y voir un peu plus clair parceque je n'ai pas d'éléments de réponse probants à la lecture des posts sur le forum    
 

Nous supposons que les bon débit en écriture obtenu en début de graphique soit le fruit de l'utilisation d'une mémoire tampon.  
 
Lorsque la taille du fichier à écrire sur le disque reste en dessous de ~15Go (22% du disque), la mémoire tampon joue parfaitement son role permettant un débit moyen de 70Mo en écriture.
 
Mais quand le fichier est plus grand (dans les bench c'est la taille du disque donc 64Go) la mémoire tampon n'arrive plus a suivre pour assurer des débits corrects, d'où le graphe dégueulasse passé les 22%.
 
En utilisation courante ce n'est pas vraiment génant (on a rarement des fichiers de plus de 15Go à transférer, surtout sur un SSD qui est destiné à être utilisé pour l'OS...) car ce phénomène ne se produira jamais.
 
(Encore une fois, nous supposons qu'il y a une utilisation de mémoire tampon...)

Si perf pourries je renvois le produit : clause des 7 jours

faudrai pouvoir confirmer cette theorie de la memoire cache ^^

Nous supposons que les bon débit en écriture obtenu en début de graphique soit le fruit de l'utilisation d'une mémoire tampon.  
 
Lorsque la taille du fichier à écrire sur le disque reste en dessous de ~15Go (22% du disque), la mémoire tampon joue parfaitement son role permettant un débit moyen de 70Mo en écriture.
 
Mais quand le fichier est plus grand (dans les bench c'est la taille du disque donc 64Go) la mémoire tampon n'arrive plus a suivre pour assurer des débits corrects, d'où le graphe dégueulasse passé les 22%.
 
En utilisation courante ce n'est pas vraiment génant (on a rarement des fichiers de plus de 15Go à transférer, surtout sur un SSD qui est destiné à être utilisé pour l'OS...) car ce phénomène ne se produira jamais.
 
(Encore une fois, nous supposons qu'il y a une utilisation de mémoire tampon...)

Il faut essayer de copier des fichiers plus ou moins gros (donc plus petit et plus grand que ~15Go) un peu partout sur le disque.
 
Si quand on copie des fichier < 15Go les débit reste bon peut importe la position sur le disque, alors la mémoire cache est confirmé.
 
Mais de toute façon je ne voie pas d'autre explication, car la position des blocs "physique" (l'endroit exacte sur la puce MLC) et "virtuelle" (l'adresse du bloc vue par l'OS) sont complètement indépendant à cause du wear levelling...

 
Ca j'avais deviné    
 
Ils testent/simulent les écritures de fichiers de 64 Go ???    
 
 

 
 
Donc ça dépends bien du protocole de test....
 
Je ferais un bench ce soir sur mon 150 Go inutilisé....
 
 
 
 

Nous supposons que les bon débit en écriture obtenu en début de graphique soit le fruit de l'utilisation d'une mémoire tampon.  
 
Lorsque la taille du fichier à écrire sur le disque reste en dessous de ~15Go (22% du disque), la mémoire tampon joue parfaitement son role permettant un débit moyen de 70Mo en écriture.
 
Mais quand le fichier est plus grand (dans les bench c'est la taille du disque donc 64Go) la mémoire tampon n'arrive plus a suivre pour assurer des débits corrects, d'où le graphe dégueulasse passé les 22%.
 
En utilisation courante ce n'est pas vraiment génant (on a rarement des fichiers de plus de 15Go à transférer, surtout sur un SSD qui est destiné à être utilisé pour l'OS...) car ce phénomène ne se produira jamais.
 
(Encore une fois, nous supposons qu'il y a une utilisation de mémoire tampon...)

De toute façon un bench ne reflète pas les améliorations de performance que tu ressentira au quotidien... Le mieux reste de tester le SSD en situation réelle.
 
De plus, si cette théorie de la mémoire cache est vérifié, alors ce disque est vraiment bon.

Ou alors c'est le fait d'écrire en continu pendant 15Go (avec un tempon de par exemple 128Mo) qui finirait par saturer le cache ? Càd qu'il n'arrive plus à se vider assez vite.

Il faut essayer de copier des fichiers plus ou moins gros (donc plus petit et plus grand que ~15Go) un peu partout sur le disque.
 
Si quand on copie des fichier < 15Go les débit reste bon peut importe la position sur le disque, alors la mémoire cache est confirmé.
 
Mais de toute façon je ne voie pas d'autre explication, car la position des blocs "physique" (l'endroit exacte sur la puce MLC) et "virtuelle" (l'adresse du bloc vue par l'OS) sont complètement indépendant à cause du wear levelling...

 
Le hic c'est qu'il faut une source ultra rapide. Car là le test "invente" un fichier à l'aide du CPU, il ne copie rien.

C'est qui "nous" ?

Et ça n'a pas tellement de sens cette histoire de 15Go, le cache peut pas faire cette taille. Ou alors c'est le fait d'écrire en continu pendant 15Go (avec un tempon de par exemple 128Mo) qui finirait par saturer le cache ? Càd qu'il n'arrive plus à se vider assez vite.

http://www.bluefi.co.uk/oczhdtach.png
 
 
le hdtach est pas si mauvais

ça dépasse jamais les 100 Mo

En même temps je sais pas ce que vous avez à vous focaliser sur les débits, perso à 50Mo ça m'intéresserait déjà, tant que le temps d'accès est de moins de 0,5ms

Ah ce graph là me rassure !    Il est aussi en dents de scie mais ca me va bien. L'autre graph était épouvantable : il descendais  à 0.1 Mo/sec au mini  !

Bof OSEF du moment que ça descends pas trop. Cela dit c'est en dessous des spec constructeur... A voir sur quellle config ça à été testé (limitation AHCI pas activé sur ICH Intel etc.....)

Idem mais je mettrais la barre un poil de cul plus haut 70 Mo/sec en lecture/ecriture je suis content      

 
 
Ah ce graph là me rassure !    Il est aussi en dents de scie mais ca me va bien. L'autre graph était épouvantable : il descendais  à 0.1 Mo/sec au mini  !