Vos Bench SSD via QuickBench4 ici, Cherche QuickBench de SandForce après longue période d utilisation i

[Kierkegaard]

Un petit rappel au sujet des contrôleurs

Source:hardware.fr

Comme nous l’avons déjà expliqué à plusieurs reprises, notamment ici, la commande TRIM est importante puisqu’elle permet d’éviter une dégradation des performances du SSD au fur et à mesure de son utilisation.

Bien entendu, l’impact sur les performances varie d’un contrôleur à l’autre. En effectuant des écritures séquentielles sur un SSD sur lequel nous avons auparavant effectué des écritures aléatoires, et vice-versa, voici nos conclusions quand à la sensibilité des contrôleurs vis-à-vis de la fragmentation :

- Indilinx Barefoot :
Les écritures aléatoires peuvent être divisées par 4.5, les écritures séquentielles par 5
- Intel PC29AS21BA0 :
Les écritures aléatoires peuvent être divisées 4, pas d’impact significatif en écriture séquentielle
- JMicron JMF618 :
Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 10%
- Marvell 88SS9174 :
Les écritures aléatoires peuvent être divisées par 4, les écritures séquentielles peuvent baisser de 33%

Quasiment aucune différence significative (+/- 1 Mb/s) sur les 3 tests

Plus surprenant : Quasiment aucune différence non plus après la procédure de reconditionnement (12 itérations, tests toutes les 4 itérations) !!! Le chouia de Mb/s que l’on gagne d’un coté se perd de l’autre.

Voilà, après 2 heures de boulot je ne retire aucun bénéfice en terme de perf sur ce SSD (mais il n’y en avait clairement pas besoin). J’ai en revanche le sentiment d’avoir fait avancer la science.

Salut.

Comme précisé en première page,

Contrôleur Marvell
Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 10%.
Donc AMHA ,tu peux difficilement faire beaucoup mieux,même en faisant une SecurErase.

Pour le contrôleur Marvell, lequel des deux énoncés suivants est vrai, celui du premier post ou celui du second?

Marvell 88SS9174 :

A ) Les écritures aléatoires peuvent être divisées par 4, les écritures séquentielles peuvent baisser de 33%

Contrôleur Marvell

B ) Pas d’impact significatif en écriture aléatoire, les écritures séquentielles peuvent baisser de 10%.

Celui du premier.
Cf la source : http://www.hardware.fr/articles/794-7/comp...s-compares.html

Merci Dr. ès SSD.

[Guest_anonym_d019ede3_*]

Aïe!

Voici les résultats obtenus sur mon SSD INTEL X 25 V 40Go acheté début juillet, non re-conditionné mais re-cloné il y a quelques jours:

Concernant la perte en utilisation, j'ai certes de faibles perfs avec mon SSD comparé à certains "monstres" ici, par contre là j'ai posté deux jours après avoir effacé en 7 passes, partitionné en 16 puis revenu en une et recloné et je suis revenu de 2mn de boot au bout de 4 mois à 31 secondes.

De préciser que ce n'est qu'une partie d'une manip de reconditionnement par l'utilitaire de disque dont je n'ai pas compris la fin (topic en anglais et je ne suis pas très fort, du coup je n'ai pas compris comment procéder pour la fin et la manip concernant l'image disque).

Lien pour le reconditionnement gratuit par l'utilitaire de disque:
http://jasontomczak.com/2010/06/21/recondi...e-mac-for-free/

J'avais déjà tenté le refo de mon SSD, effacé 1 passe zéros, et recloné mais sans changement de perfos, mais là j'ai bien senti la différence.

Edit: Ce qui est par contre dommage, c'est que je n'ai pas pensé à faire un test Bench avant l'opération pour pouvoir comparer les chiffres...

Merci à @Kalm pour son aide.

Voici de nouveau mes résultats après un re conditionnement à l'aide de disk tester:


Edit: toujours 31 sec au Boot.

Ce message a été modifié par anonym_d019ede3 - 23 Nov 2010, 14:40.

[Crazy Vessel]

Une question pour SartMatt, ou tout autre Sachem:


En quoi le nombre de passe peut-il changer quoi que ce soit pour un SSD?

Sur un DD, les effacements en plusieurs passes se justifient pour la sécurité des données, mais sur un SSD??

Si en une passe, les cellules sont toutes effacées (0), à quoi bon en remettre une couche?

Question corrolaire: La plupart des SSD actuels contiennent des réserves (pour le wear leveling et pour palier aux zones HS) de l'ordre de 5 à 10% de leur contenance. Les commandes d'effacement avec écriture (secure erase ou autres) s'appliquent-elles à la totalité des cellules physiques du SSD? Moi j'aurai tendance à dire non, dans la mesure où l'OS ignore les cellules réservées, seul le contrôleur les utilise.

[SartMatt]

En quoi le nombre de passe peut-il changer quoi que ce soit pour un SSD?

Sur un DD, les effacements en plusieurs passes se justifient pour la sécurité des données, mais sur un SSD??

Si en une passe, les cellules sont toutes effacées (0), à quoi bon en remettre une couche?

Quelqu'un sur ce forum avait posté il y a quelques temps une étude faite par quelques chercheurs spécialisés dans le domaine du stockage, qui montrait que, comme sur un disque dur, on peut trouver quelques traces des anciennes données après un effacement (à cause d'une très légère rémanence), ce qui pourrait justifier plusieurs passes lorsqu'on veut rendre les données illisibles.

Dans le cas d'une tentative de défragmentation de l'espace disque, la multiplication des passes améliore le résultat. En effet, après une écriture séquentielle, rien ne garanti que le contrôleur a optimisé au mieux cette écriture en groupant au mieux les cellules. C'est le fait d'effectuer plusieurs passes successives qui maximise la probabilité d'une défragmentation efficace.

Les commandes d'effacement avec écriture (secure erase ou autres) s'appliquent-elles à la totalité des cellules physiques du SSD? Moi j'aurai tendance à dire non, dans la mesure où l'OS ignore les cellules réservées, seul le contrôleur les utilise.

Dans le cas d'un secure erase, il y a simplement effacement, pas écriture. Cet effacement s'applique à l'intégralité des cellules, y compris l'espace de réserve.
Dans le cas d'une réécriture de l'espace libre, toutes les cellules peuvent potentiellement être réécrites. En effet, le pool de cellules de réserve est un pool dynamique : au fil des écritures, les cellules affectées à ce pool varient. Lors d'une nouvelle écriture, l'opération optimale est bien souvent d'aller prendre une cellule du pool de réserve, d'écrire les données dedans et d'affecter au pool de réserve la cellule qui contenait l'ancienne version des données.
Effectuer une réécriture de l'espace libre peut donc affecter l'intégralité des cellules d'un SSD.


Ce message a été modifié par SartMatt - 24 Nov 2010, 05:13.

[Crazy Vessel]

En quoi le nombre de passe peut-il changer quoi que ce soit pour un SSD?

Sur un DD, les effacements en plusieurs passes se justifient pour la sécurité des données, mais sur un SSD??

Si en une passe, les cellules sont toutes effacées (0), à quoi bon en remettre une couche?

Quelqu'un sur ce forum avait posté il y a quelques temps une étude faite par quelques chercheurs spécialisés dans le domaine du stockage, qui montrait que, comme sur un disque dur, on peut trouver quelques traces des anciennes données après un effacement (à cause d'une très légère rémanence), ce qui pourrait justifier plusieurs passes lorsqu'on veut rendre les données illisibles.

J'aurais bien aimé jeter un oeil sur le boulot de ces chercheurs, j'ai un peu cherché, sans succès. Si tu retrouves... En terme de rémanence, une différence de niveau entre deux états magnétiques, même d'intensité infime, peut effectivement être détectée après plusieurs effacements (cas des DD), mais ne connaissant pas (encore!) la méthode "physique" d'écriture d'un bit sur une cellule de SSD, je reste dubitatif.

Les commandes d'effacement avec écriture (secure erase ou autres) s'appliquent-elles à la totalité des cellules physiques du SSD? Moi j'aurai tendance à dire non, dans la mesure où l'OS ignore les cellules réservées, seul le contrôleur les utilise.

Dans le cas d'un secure erase, il y a simplement effacement, pas écriture.

Je m'étais peut-être mal exprimé: "effacement avec écriture" je voulais dire effacement remise à zéro de la cellule, ou une passe (par opposition à un effacement standard de l'adresse sur un DD).

Cet effacement s'applique à l'intégralité des cellules, y compris l'espace de réserve.

Là aussi, je reste dubitatif. Bien que l'espace de réserve soit dynamique (on ferait mieux de parler de "nombre de cellules" réservées plutôt que d'"espace"), la probabilité qu'il reste un seul secteur non écrit sur le SSD diminue au fur et à mesure de son utilisation après qu'il fut plein. Sur un SSD plein ou presque qui est utilisé depuis un moment (réécritures), il est tout à fait possible que 99,9% des cellules soient porteuses d'information. Si c'est bien l'OS qui dirige les opérations dans le cas d'une passe à 0 (ou plusieurs), ou dans le cas d'un secure erase, je doute que le contrôleur donne accès à 100% des cellules. Je pense au contraire que le contrôleur va continuer à faire bêtement son travail, et une partie (les 5 ou 6% de réserve en l'occurence) sera, AMHA, ignorée de la commande d'effacement.

Ce message a été modifié par Crazy Vessel - 24 Nov 2010, 10:05.

[Guest_anonym_d019ede3_*]

Question à SartMatt ou Crazy Vessel sur l'effacement rapport à cette manip:

http://jasontomczak.com/2010/06/21/recondi...e-mac-for-free/

Dans mon cas j'avais déjà tenté l'effacement et re clonage pour mon SSD sans résultats de gain au boot, d'ailleurs il précise que son effacement n'est peut-être pas une manip indispensable, après coup.

Par contre, là où je suis repassé de presque 2mn de boot à 31 secondes c'est (certes en effaçant de nouveau) mais surtout en effectuant 16 partitions avant de reformater en une seule.

Physiquement comment cela s'explique-t'il selon vous?

Ce message a été modifié par anonym_d019ede3 - 24 Nov 2010, 11:26.

[SartMatt]

Quelqu'un sur ce forum avait posté il y a quelques temps une étude faite par quelques chercheurs spécialisés dans le domaine du stockage, qui montrait que, comme sur un disque dur, on peut trouver quelques traces des anciennes données après un effacement (à cause d'une très légère rémanence), ce qui pourrait justifier plusieurs passes lorsqu'on veut rendre les données illisibles.

Dans les mémoires flash, les bits sont stockées sous forme de charge électriques, avec 2 à 8 niveaux de charges possibles par cellule selon le type de mémoire.
Je t'avoue que je suis moi aussi assez dubitatif sur la possibilité d'une rémanence suffisante pour relire les données, surtout sur les mémoires MLC (celles à plus de 2 niveaux de charge).

Les commandes d'effacement avec écriture (secure erase ou autres) s'appliquent-elles à la totalité des cellules physiques du SSD? Moi j'aurai tendance à dire non, dans la mesure où l'OS ignore les cellules réservées, seul le contrôleur les utilise.

Dans le cas d'un secure erase, il y a simplement effacement, pas écriture.

Je m'étais peut-être mal exprimé: "effacement avec écriture" je voulais dire effacement remise à zéro de la cellule, ou une passe (par opposition à un effacement standard de l'adresse sur un DD).

Justement, sur un DD, il n'y a pas de notion d'effacement.
Sur un DD, on ne peut faire que deux types d'opérations sur un bit : lecture ou écriture. L'effacement consiste simplement à écrire par dessus les données existantes.
La commande ATA Secure Erase effectue donc une réécriture sur l'ensemble du disque (par contre je sais pas si c'est juste des zéros, où si ça écrit plutôt des données aléatoires).
Les logiciels d'effacement de données font de même, donc donnent le même résultat.

Sur un SSD par contre, il y a trois opérations possibles sur une cellule : lecture (opération qui s'effectue sur toute une page à la fois), programmation (qui s'applique également à toute une page, et qui consiste à faire passer certaines cellules de la page de l'état 1 à l'état 0), effacement (qui s'applique à un bloc de plusieurs pages, et qui consiste à repasser de l'état 0 à l'état 1 toutes les cellules du bloc). Une écriture de données se fait soit directement avec une programmation, si la cellule est vierge, soit avec un effacement puis une programmation si la cellule n'est pas vierge.
La commande ATA Secure Erase effectue uniquement un effacement, ce qui est du coup très rapide, et fait qu'après l'opération toutes les cellules sont considérées comme vierges par le contrôleur.
Les logiciels d'effacement de données par contre, ils vont commander des écritures. Ce qui revient donc en fait à faire des effacements puis des programmation, et donc les cellules ne seront pas considérées comme vierges par le contrôleur.

Cet effacement s'applique à l'intégralité des cellules, y compris l'espace de réserve.

Là aussi, je reste dubitatif. Bien que l'espace de réserve soit dynamique (on ferait mieux de parler de "nombre de cellules" réservées plutôt que d'"espace"), la probabilité qu'il reste un seul secteur non écrit sur le SSD diminue au fur et à mesure de son utilisation après qu'il fut plein. Sur un SSD plein ou presque qui est utilisé depuis un moment (réécritures), il est tout à fait possible que 99,9% des cellules soient porteuses d'information. Si c'est bien l'OS qui dirige les opérations dans le cas d'une passe à 0 (ou plusieurs), ou dans le cas d'un secure erase, je doute que le contrôleur donne accès à 100% des cellules. Je pense au contraire que le contrôleur va continuer à faire bêtement son travail, et une partie (les 5 ou 6% de réserve en l'occurence) sera, AMHA, ignorée de la commande d'effacement.

Dans le cas du secure erase, ce n'est pas l'OS qui dirige les opérations. Il envoie juste la commande ATA Secure Erase au SSD, et le contrôleur déclenche alors l'effacement de toutes les cellules.
Dans le cas d'une passe d'écriture avec des 0, ça va probablement affecter une partie des cellules de l'espace de réserve, vu qu'il est dynamique : quand on écrit sur un secteur mappé sur une page non vierge d'un bloc donné (A), il est relativement probable que, au lieu d'effacer puis programmer le bloc A, le contrôleur aille programmer un bloc B pris dans l'espace de réserve, puis marque le bloc A comme étant un bloc de réserve (ce qui déclenchera son effacement durant une phase de garbage collection). Cette rotation de l'espace de réserve est justement l'une des clés du wear-levelling. Par contre, effectivement, si on effectue une passe d'écriture à zéro sur l'ensemble du SSD, il y a un nombre de cellule égale à la taille de l'espace de réserve qui ne sera pas affecté directement (elles le seront plus tard, lors du passage du garbage collector), mais ce n'est pas forcément les cellules qui étaient dans l'espace de réserve avant le lancement de la passe d'écriture à zéro.

Par contre, là où je suis repassé de presque 2mn de boot à 31 secondes c'est (certes en effaçant de nouveau) mais surtout en effectuant 16 partitions avant de reformater en une seule.

Physiquement comment cela s'explique-t'il selon vous?

Là j'en ai absolument aucune idée. C'est vraiment un comportement surprenant, et c'est la première fois que j'entends parler d'une procédure de ce genre.

[TitouDoc]

Voici les benchs d'un C300 après 6 mois d'utilisation, no swipe, no reinstall en fait rien fait du tout a par l'utiliser

Ps : firmware 006.

Fichier(s) joint(s)

 1.tiff ( 207.32 Ko ) Nombre de téléchargements : 62
 2.tiff ( 180.59 Ko ) Nombre de téléchargements : 42
 3.tiff ( 180.65 Ko ) Nombre de téléchargements : 33

 

[Kierkegaard]

Voici les benchs d'un C300 après 6 mois d'utilisation, no swipe, no reinstall en fait rien fait du tout a par l'utiliser

Ps : firmware 006.

As-tu remarqué une différence sur ton Crucial C300 256Go depuis que tu as fait la mise à jour du firmware 0006? Est-ce mieux ou sensiblement pareil?

Merci.

[Kierkegaard]

Salut les pommés,

Après avoir posté les benchs bruts de ma partoche système après 6 mois d’usage quotidien, je vous propose, en l’absence de TRIM, de voir l’intérêt (ou pas) d’une procédure de « reconditionnement » avec l’utilitaire Disktester de Diglloyd.

Contexte :

MacBook Pro I5 2,4Ghz – 4Go / OSX 10.6.5
SSD : Crucial C300 / 256 Go / Firmware Rev. 002 /Contrôleur Marvell
Mise en service Mai 2010. 6 mois d’utilisation intensive quotidienne.
3 partitions : OSX+Appli / Données / Win7.

J’ai choisi cette fois de tester la partition « Données ». C’est la partition HFS+ plus sollicitée en terme de lectures/écritures/effacements au quotidien, donc celle ou l’absence de TRIM devrait le plus se faire sentir. Cette partition de travail de 58 Go est à ce jour utilisée par 25,6 Go de données réparties en 12369 fichiers soit une taille moyenne de fichier d’environ 2 Mo.

Protocole :
1) Bench Série A (QuickBench . test standard / étendu / personnalisé sur 5 passes à chaque fois)
2) Sauvegarde de l’intégralité des données sur HD externe (TriBackup)
3) Effacement des données ET de l’espace libre avec écriture de 0 (Utilitaire disque OSX)
4) Bench Série B (mêmes tests)
5) Reconditionnement avec l’utilitaire Disktester de Diglloyd (Voir ici
6) Bench Série C (mêmes tests)
7) Restauration des Données

RRESULTATS.

SERIE A . AVANT RECONDITIONNEMENT


.

.

.

SERIE C. APRES RECONDITIONNEMENT


.

.

.

COMMENTAIRES

Quasiment aucune différence significative (+/- 1 Mb/s) sur les 3 tests entre la série A et B : Conclusion : la simple procédure « effacement du disque avec écriture de 0 » ne sert strictement à rien, du moins sur ce modèle de SSD. Pourtant cette procédure a largement été conseillée et débattue sur certains sites et forums. (je ne publie donc pas la série B pour ne pas alourdir le post)

Plus surprenant : Quasiment aucune différence non plus après la procédure de reconditionnement (12 itérations, tests toutes les 4 itérations) !!! Le chouia de Mb/s que l’on gagne d’un coté se perd de l’autre.

A ce stade on en vient à formuler 3 hypothèses (sans ordre de probabilité) :

1) Soit la commande RECONDITION de Diglloyd/Disktester est mal foutue ou ne prend pas convenablement en charge ce modèle de SSD/contrôleur.

2) Soit le Crucial C300/Marvell a une excellente tenue dans temps.

3) Soit OSX supplée l’absence de TRIM par d’autres mécanismes (lequels ?) qui évitent parfaitement la dégradation des performances. Cette hypothèse a déjà largement été formulée par ailleurs mais sans aucune explication technique crédible.

On pourrait alors penser que si Apple ne se presse pas pour implémenter le TRIM sous OS/X c’est qu’ils sont peut être parfaitement conscient de son inutilité en l’espèce. Dommage qu’ils ne communiquent pas non plus sur cet aspect technique.

Ce qu’il manque pour pouvoir affiner cette réflexion c’est une série de test lorsque le disque était neuf. Peut-être celui de Kierkegaard en début de post (même modèle SSD mais sur config différente) ? Auquel cas resteraient les hypothèses 2 ou 3 que l’on pourrait alors discriminer par le même protocole de test avec un autre modèle de SSD.

Voilà, après 2 heures de boulot je ne retire aucun bénéfice en terme de perf sur ce SSD (mais il n’y en avait clairement pas besoin). J’ai en revanche le sentiment d’avoir fait avancer la science.

Quand j'ai commencé à faire des tests avec mon Crucial C300 256Go, via l'application QuickBench, il avait déjà 3 mois d'utilisation journalière. Cela dit, qui sait, il n'était peut-être pas plus rapide quand il était neuf.

[Guest_anonym_d019ede3_*]

Quand j'ai commencé à faire des tests avec mon Crucial C300 256Go, via l'application QuickBench, il avait déjà 3 mois d'utilisation journalière. Cela dit, qui sait, il n'était peut-être pas plus rapide quand il était neuf.

As-tu refais ta remise à plat de SSD avec les deux méthodes? celle du site jason que j'ai lu t'avais intéressé + suivi de disk tester?

Pour ma part j'ai réellement senti la différence surtout au boot, par contre je ne m'explique toujours pas ce qui à l'époque avait ralenti mon SSD à ce point en 3 jours seulement...

Là je reste stable depuis mes opérations de re condition et ça fait une semaine.

[Kierkegaard]

Quand j'ai commencé à faire des tests avec mon Crucial C300 256Go, via l'application QuickBench, il avait déjà 3 mois d'utilisation journalière. Cela dit, qui sait, il n'était peut-être pas plus rapide quand il était neuf.

As-tu refais ta remise à plat de SSD avec les deux méthodes? celle du site jason que j'ai lu t'avais intéressé + suivi de disk tester?

Pour ma part j'ai réellement senti la différence surtout au boot, par contre je ne m'explique toujours pas ce qui à l'époque avait ralenti mon SSD à ce point en 3 jours seulement...

Là je reste stable depuis mes opérations de re condition et ça fait une semaine.

J'ai essayé la méthode DiskTester Recondition SSD et je n'ai pas noté de changement qui soit réellement significatif. Quant à la méthode de jason, à quoi bon l'essayée puisque tu l'as testée et tu as obtenu un bien meilleur score avec celle de DiskTester?



Ce message a été modifié par Kierkegaard - 28 Nov 2010, 15:20.

[Guest_anonym_d019ede3_*]

Il est vrai que j'ai eu un meilleur score après Disk tester trois jour après avoir appliqué l'autre méthode, maintenant ce qui m'a fait obtenir une différence flagrante c'est bien le fait d'effacer 7 passes zéro suivi de 16 partitions pour revenir à une seule avant de re cloner.

Là où je n'ai peut être pas obtenu le résultat le plus impeccable c'est que je me suis arrêté à l'étape de l'image disque. Peut-être là ou Disk tester à terminé de faire du ménage.

J'ai envie de dire que ça se teste...

[Daystrom]

Voilà mes Vertex 2 sont enfin arrivé, ainsi que les disques dur pour mon NAS.
Je vous tiens au courant dans quelques jours le temps de sauvegarder tous cela.
Pour info j'ai choisis des Vertex en 3,5" pour la simplicité de la mise en place dans mon Mac Pro.

Click for large view - Uploaded with Skitch

[Kierkegaard]

Well, well, well, t'es vraiment full equip en HDD et en SSD. Ça va rouler tempête.

Ce message a été modifié par Kierkegaard - 1 Dec 2010, 20:12.

[stephn666]

Bonjour,
J'ai commander un Vertex 2 pour mon Mac mini 1.1 (donc sata 1) ce Dimanche (toujours pas reçu snifff) je vous vois beaucoup parler des débit "monstrueux", sachant parfaitement que ce dernier sera bridé, vous croyez qu'en utilisation "classique" je verrais la différence si j'avais du sata 2?

Ce message a été modifié par stephn666 - 2 Dec 2010, 13:09.

[Kalm]

Bonjour,
J'ai commander un Vertex 2 pour mon Mac mini 1.1 (donc sata 1) ce Dimanche (toujours pas reçu snifff) je vous vois beaucoup parler des débit "monstrueux", sachant parfaitement que ce dernier sera bridé, vous croyez qu'en utilisation "classique" je verrais la différence si j'avais du sata 2?

En réactivité, aucune puisque le sata 1 ne bride pas le temps d accès a ton SSD,en ce qui concerne les débits de transfère tu seras bridé a 150Mo/s au lieu des 270 théorique du Vertex2, mais si tu considères que sur un Sanforce la fragmentation peut faire baisser les débits d écritures aléatoires par 2 et les écritures séquentielles par 4(dans certains teste),arrivé a ce stade même un sata 2 ne sera pas plus performant puisque ce sont le débits du SSD qui auront chutes.

Ce message a été modifié par Kalm - 2 Dec 2010, 18:23.

[stephn666]

Merci pour ta réponse, j'avoue que je m'en doutais un peu.
Concernant la fragmentation, je suppose que tu en parle car il n'y a pas encore la gestion du trim dans Mac OS X et que ça pénalise certain contrôleur sous notre OS?

Sinon j'ai lu pas mal de chose sur ce forum et d'autre concernant les SSD et je vois qu'il y en a qui vont ce faire une joie de faire du RAID 0, je n'entends personne parler de la latence, je croyais que ça l'augmentais?

[Kalm]

Merci pour ta réponse, j'avoue que je m'en doutais un peu.
Concernant la fragmentation, je suppose que tu en parle car il n'y a pas encore la gestion du trim dans Mac OS X et que ça pénalise certain contrôleur sous notre OS?

Sinon j'ai lu pas mal de chose sur ce forum et d'autre concernant les SSD et je vois qu'il y en a qui vont ce faire une joie de faire du RAID 0, je n'entends personne parler de la latence, je croyais que ça l'augmentais?

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence et un débit similaire sur certains fichiers.

Ce message a été modifié par Kalm - 2 Dec 2010, 20:52.

[stephn666]

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence sur certains fichiers.

Alors là je n'y comprends plus rien, je pensais que sur mémoire flash il n'y avais pas de fragmentation ou alors ce que tu dit ne sous entend pas ça et que j'aurais mal compris.

Quoi qu'il en sois, même si je suis hors catégorie (sata 1 oblige), je ne manquerais pas faire un bench pour ce topic, j'ai déjà préparer le "avant" qui m'a d'ailleurs bien surpris sur certain test (sur les 4k) par rapport à un SSD et j'ai également été surpris de voir à quel point l'écriture était lente sur mon disque je ne m'en doutais même pas.

Moralité, ce qu'il manque dans les test des SSD c'est plus de comparaisons avec nos vieux disques à plateaux.

[Kalm]

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence sur certains fichiers.

Alors là je n'y comprends plus rien, je pensais que sur mémoire flash il n'y avais pas de fragmentation ou alors ce que tu dit ne sous entend pas ça et que j'aurais mal compris.

C est le wear-leveling gerant l usure sur l ensemble du SSD qui provoque cette fragmentation et qui dégrade les performances en écriture.

Ce message a été modifié par Kalm - 2 Dec 2010, 17:36.

[stephn666]

C est le wear-leveling gerant l usure sur l ensemble du SSD qui provoque cette fragmentation et qui dégrade les performances en écriture.

Ok merci, j'aurais encore appris autre chose aujourd'hui.

[Kalm]

Teste SandForce SF1200 single et RAID-0 ,

http://benchmarkreviews.com/index.php?opti...mp;limitstart=4

[Kierkegaard]

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence sur certains fichiers.

Alors là je n'y comprends plus rien, je pensais que sur mémoire flash il n'y avais pas de fragmentation ou alors ce que tu dit ne sous entend pas ça et que j'aurais mal compris.

C est le wear-leveling gerant l usure sur l ensemble du SSD qui provoque cette fragmentation et qui dégrade les performances en écriture.

En somme, si j'ai bien compris, le wear-leveling contribuerait, d'une part, à gérer l'usure sur l'ensemble du SSD, ce qui semble plutôt une bonne chose et, d'autre part, à fragmenter et à dégrader les performances en écriture sur le SSD, ce qui est un sérieux problème, non?

Ce message a été modifié par Kierkegaard - 2 Dec 2010, 21:34.

[Kalm]

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence sur certains fichiers.

Alors là je n'y comprends plus rien, je pensais que sur mémoire flash il n'y avais pas de fragmentation ou alors ce que tu dit ne sous entend pas ça et que j'aurais mal compris.

C est le wear-leveling gerant l usure sur l ensemble du SSD qui provoque cette fragmentation et qui dégrade les performances en écriture.

En somme, si j'ai bien compris, le wear-leveling contribuerait, d'une part, à gérer l'usure sur l'ensemble du SSD, ce qui semble plutôt bonne chose et, d'autre part, à fragmenter et à dégrader les performances en écriture sur le SSD, ce qui est un sérieux problème, non?

C est le paradoxe,on peut rever a un OS qui puisse gérer correctement ces écritures sur l ensemble des cellules du SSD

Ce message a été modifié par Kalm - 2 Dec 2010, 21:41.

[Kierkegaard]

Ces testes ont étés effectués sous commande Trim mis à jour le 17 Septembre 2010.
Raid 0,Effectivement j ai vu certains teste ou l on pouvait remarquer l augmentation de latence sur certains fichiers.

Alors là je n'y comprends plus rien, je pensais que sur mémoire flash il n'y avais pas de fragmentation ou alors ce que tu dit ne sous entend pas ça et que j'aurais mal compris.

C est le wear-leveling gerant l usure sur l ensemble du SSD qui provoque cette fragmentation et qui dégrade les performances en écriture.

En somme, si j'ai bien compris, le wear-leveling contribuerait, d'une part, à gérer l'usure sur l'ensemble du SSD, ce qui semble plutôt bonne chose et, d'autre part, à fragmenter et à dégrader les performances en écriture sur le SSD, ce qui est un sérieux problème, non?

C est le paradoxe,on peut rever a un OS qui puisse gérer correctement ces écritures sur l ensemble des cellules du SSD

Mais en attendant d'avoir la commande TRIM sur Mac OS X, peut-être pourrait-on avoir un logiciel qui puisse redonner une belle jeunesse au SSD, via un logiciel spécialement conçu pour ce genre d'opération. Ce n'est pas ce que fait justement HDDErase sur PC ou bien j'ai mal compris?

[Kalm]

Il est 4h the stock market closed
Je dors bonne nuit

[stephn666]

C est le paradoxe,on peut rever a un OS qui puisse gérer correctement ces écritures sur l ensemble des cellules du SSD

Mais en attendant d'avoir la commande TRIM sur Mac OS X, peut-être pourrait-on avoir un logiciel qui puisse redonner une belle jeunesse au SSD, via un logiciel spécialement conçu pour ce genre d'opération. Ce n'est pas ce que fait justement HDDErase sur PC ou bien j'ai mal compris?

Bonsoir,
Plûtot que de parler d'un OS qui puisse gérer ça correctement on devrais plutôt parler d'un nouveau système de fichier, ça sera surement d'actualité avant la fin 2010 à mon avis...

Je pense aussi que cette fragmentation est plus ou moins bien géré suivent le contrôleur, avis aux expert.

Ce message a été modifié par stephn666 - 2 Dec 2010, 22:22.

[Guest_anonym_d019ede3_*]

Alors là c'est moi qui ne suis plus non plus...
Ça veut dire que même en reconditionnant son SSD et en le reclonant (ce qui défragmente sur mac) on fragmente malgré tout?!
De plus si ma mémoire est bonne ce n'est pas forcément la fragmentation qui le ralenti le plus mais plutôt les fichier de fichier de.... etc les un dans les autres arrétez moi où je me trompe car je fini par redevenir aussi confus qu'à mon début de renseignements sur SSD

Ce message a été modifié par anonym_d019ede3 - 2 Dec 2010, 22:31.

[Kierkegaard]

À défaut d'avoir le TRIM sur Mac OS X, le meilleur système d'exploitation au monde, ce serait cool d'avoir un équivalent du logiciel HDDErase pour Mac.