|
4 Bench en RAID 0 de cartes CF branchées en Sata.
Nous nous sommes ensuite lancés dans les mêmes benchs avec cette fois un RAID 0 Sata de carte CF Extrême IV 8Go. Pour ce faire, nous surmontons nos adaptateurs CF vers IDE d'adaptateurs IDE vers Sata, ici des Serillels 2 de chez Abit. L'accumulation d'adaptateurs, souvent néfaste, ne diminuera pourtant aucunement les performances. Sur un système à une seule Compact Flash, seule une légère hausse (normal voir la suite) de l'utilisation du CPU est à noter en Sata comparé à l'IDE.
Nous avons choisi un RAID 0 car sur les Compact Flash nous n'avons pas du tout les mêmes risques de perte de données que sur un disque dur, et de plus il n'y a aucune partie mécanique donc pas de risque de casse. Le RAID 0 est une solution viable qui ne présente que très peu de risque contrairement à un RAID 0 de disque dur...
Lors de la configuration de notre RAID, le Bios de la carte RAID (intégré à l'AN7) nous propose plusieurs tailles de bandes : 4, 8, 16, 32, 64, 128Ko. Le choix de la taille de la bande du RAID est primordial, car il influencera énormement les performances et, suivant le type de fichier qu'hébergera l'ordinateur, il améliorera, ou non, grandement les performances... Le choix ne peut se faire qu'à la création du RAID, il ne peut être modifié ensuite sauf en cassant le RAID. Attention donc !
Principe de fonctionnement du RAID 0 et des bandes : chaque fichier qui va devoir être écrit sur le RAID va être découpé en plusieurs morceaux de la taille de bandes que l'on aura défini à la création du RAID.
Exemples :
Un fichier de 750Ko doit être écrit sur le disque dur :
> Taille de bandes de 16Ko : le système va écrire 750/16 -> 49 bandes, ce qui nous donne 25 accès aux CF pour écrire à chaque fois 16Ko
> Taille de bandes de 128Ko : le systeme va écrire 750/128 -> 6 bandes., ce qui nous donne 3 accès aux CF pour écrire à chaque fois 128Ko
Prenons maintenant un fichier de 15Ko
> Taille de bandes de 16Ko : le système va écrire 15/16 -> 1 bande, ce qui nous donne 1 accès aux CF pour écrire à chaque fois 16Ko.
> Taille de bandes de 128Ko : le système va écrire 15/128 -> 1 bande, ce qui nous donne 1 accès aux CF pour écrire à chaque fois 128Ko.
Voilà pour le principe du RAID mais, là où les choses se compliquent, c'est dans la gestion de la lecture et de l'écriture de la CF : en effet, si la lecture se fait par page (2Ko), l’écriture de celle-ci se fait par bloc, donc pour écrire une page de 2Ko, il faudra réécrire entièrement le bloc où se trouve cette page, soit 128Ko. Quand on ajoute à cela la gestion des bandes du RAID, on comprend que le choix de la taille des bandes n'est pas une chose aisée...
Maintenant qu'on a vu le principe, on se rend compte que des grosses tailles de bande risquent de pénaliser les performances sur des petits fichiers, mais pour autant la solution ne consiste pas à mettre une taille la plus petite possible, car sur la plupart des contrôleurs RAID entrée de gamme, c'est le CPU de la machine qui se charge de découper les fichiers en bandes. Donc plus la taille des bandes sera petite, plus le CPU sera occupé.
Dans le meilleur des mondes, la taille de bande parfaite serait celle qui découpe un maximum de fichiers en deux (pour un RAID à deux unités), car dans ce cas on fait un accès suivi d'une écriture sur chaque disque, et on obtient donc des performances quasi doublées. Si, pour le même fichier, on découpe en quatre blocs, cela nous donne quatre accès pour quatre écritures. Les débits étant les mêmes, écrire une fois 16Ko ou deux fois 8Ko prendra le même temps MAIS le temps d'accès sera doublé ! C'est dans ces cas-là que le temps d'accès insignifiant de la CF lui permet d'augmenter encore ses performances, car avec des temps d'accès 30 fois plus rapides, multiplier les accès ne sera pas aussi pénalisant que sur un disque dur.
Voici pour la théorie. Regardons maintenant ce que cela donne lors de tests pratiques. Nous avons pour chaque test pris les mesures avec toutes les tailles de bandes possibles : 4Ko, 8Ko, 16Ko, 32Ko, 64Ko, 128Ko. En bleu on retrouve les performances d'une CF seule.
Les graphiques sont disposés ainsi :
 |
 |
 |
| Bandes de 4 Ko |
Bandes de 8 Ko |
Bandes de 16 Ko |
 |
 |
 |
| Bandes de 32 Ko |
Bandes de 64 Ko |
Bandes de 128 Ko |
Clairement, lors de ce test, des bandes de 64Ko et 128Ko font effondrer les performances d'une façon que les amateurs de RAID connaissent bien ! En 64Ko les performances oscillent entre un systeme RAID bien calibré et une CF seule. Le Burst Speed reste à peu de choses près le même alors que comme prévu, le taux d'utilisation du CPU est plus élevé dans les RAID avec des bandes de petite taille.
 |
 |
 |
| Bandes de 4 Ko |
Bandes de 8 Ko |
Bandes de 16 Ko |
 |
 |
 |
| Bandes de 32 Ko |
Bandes de 64 Ko |
Bandes de 128 Ko |
On remarque la même chose que précédemment, sauf qu'on peut avec plus de précision voir l'utilisation du CPU augmenter quand la taille des bandes diminue, comme mentionné en introduction. Pour les performances, l'effondrement commence un peu plus tôt, les bandes de 32Ko accusant déjà une perte par rapport aux bandes de 4, 8 et 16Ko.
Avec une seule Compact Flash on avait un système qui semblait déjà être plus réactif, et le passage en RAID nous conforte encore plus dans cette idée. Il faut dire que le système mis en place est plus rapide que tous les disques SSD existants actuellement.
Notre RAID 0 Sata de CF Extrême IV nous as permis d’obtenir un disque SSD de 16 Giga avec un taux de transfert en lecture de 65 Mo/s minimum, et un temps d’accès de 0.5 ms. Pour 300€ notre RAID est plus veloce et moins cher que les SSD du commerce.
Ecrit par tolden (Visiteur), le 10-09-2007 11:08
Bonjour,
Ce test est interessant mais je releve plusieurs points à pécise pour un beotien en page 4:
Conclusion qu'elle taille de bande préconisez vous ? çà n'est pas claire.
vos images correspondent à qu'elles bandes, ou dans qu'elles sont elles rangées ?
Merci à vous.
et bravo. |
Ecrit par tolden (Visiteur), le 10-09-2007 11:11
dommage que l'on ne puisse pas rééditer son commentaire pour faire les corrections...
...point à préciser pour...
...dans qu'elles ordres sont...
merci |
Ecrit par rufo (Visiteur), le 10-09-2007 11:49
On n'a pas non plus de recule (stats) sur la fiabilité des CF sur le long terme en utilisation aussi intensive (en tant que disque principal d'un PC). Est-ce que les cellules de la CF ne risquent pas de se détériorer? |
Ecrit par Loic (Utilisateur enregistré), le 10-09-2007 14:02
Pour répondre à vos questions,
La taille de bande que j'ai adopté est 16Ko, au delà cela devient moins bon, à moins de pouvoir monter vraiment haut. Mais cela reste difficile à déterminer, et dépend également de la taille de cluster utilisé pour le partitionnement
La taille de bande pour chaque graph est indiqué dans son titre, et sont disposé en ordre croissant.
La vitesse de détérioration est effectivement méconnue faute de recul, les informations varient beaucoup a ce sujet, mais en étant assez optimistes, le temps qu'elles lâchent sur un système, un certain nombre d'années se seront passés.(en raid0 on multiplie par 2 la durée de vie), de même, plus la capacité sera importante pour un même système, plus la durée de vie sera élevée, pour finir l'écriture ne se fait pas toujours sur les mêmes blocs, ce qui entrainerait leurs usure prématurée, un "roulement" a donc lieu entre blocs utilisés et inutilisés, afin de répartir l'usure de manière homogène |
Ecrit par gil (Visiteur), le 10-09-2007 15:47
il me semble plutot qu'en raid 0 on divise par 2 la durée de vie, car il y a 2 disques et que si l'un des deux laches on pert tout |
Ecrit par pepito (Visiteur), le 11-09-2007 22:38
Gil -> non la durée de vie de la cartes est bien multipliée par 2 en RAID 0. Et pis les CF ca plante pas comme un disque dur donc pas de gros risque de perte des données du RAID.
Sur la durée de vie des CF c'est pas très important. Elles sont souvent garantie au moins 10 ans ( a vie chez Sandisk ?) et donc si elle commence a avoir des problemes d'ici 8 ou 9 ans suffit d'en demander une autre :D |
Ecrit par Systho (Visiteur), le 10-09-2007 16:48
En fait gil a un peu raison quand même, puisqu'en raid 0 il n'y a pas de code de parité, il suffit qu'un disque lache pour que le système soit perdu.
Mais cette notion n'est pas exactement la "durée de vie" puisque les disque qui n'auront pas laché seront récupérables.
Dire qu'un raid 0 à deux disques augmente la durée de vie par deux est un peu exagéré quand même puisque la durée de vie d'un disque n'est liée uniquement qu'à son usure (en gros c'est pas pask'on l'utilise deux fois moins qu'il tiendra deux fois plus longtemps) |
Ecrit par Loic (Utilisateur enregistré), le 10-09-2007 16:54
Dans le cas de CF, le risque est nettement moindre...
Par contre comme je l'expliquais au dessus,de par le mode de fonctionnement à créer un "roulement" entre blocs utilisés,on peut dire que plus il y aura de blocs inutilisés,plus la durée de vie sera rallongée,hors je double ma capacité en raid 0, donc logiquement je gagne autant en durée de vie. A vérifier au long terme bien sur! |
Ecrit par Johan (Visiteur), le 10-09-2007 17:15
Bonjour..
Très bon test ! Moi qui ai encore quelques vieux "ancêtres" qui ne supportent pas de ddurs de plus de 20 ou 40 Go, envisager de tester un remplacement par une CF me parait une chose à tester..
Mais dans le problème de l'alim 5v / 3.3v, vous incriminez la carte et non l'adaptateur. Or, je ne vois pas en quoi la carte travaille différemment suivant le mode d'utilisation de l'adaptateur Pata UDMA / Sata.. Si la carte est capable de travailler correctement quelle que soit la tension d'alim avec l'adaptateur en mode Sata, je ne vois pas bien pourquoi elle se comporterait différemment quand on utilise l'adaptateur en mode Pata.
Je pencherai plutôt pour un pb au niveau de l'adaptateur et de son contrôleur IDE. J'ai déjà connu des pbs d'adaptateurs, notamment avec des adaptateurs SCSI SCA 80/68 pins, surtout avec des adaptateurs noname (les plus courants).
Mais savoir que la bidouille de câbler vers le 3.3v fonctionne est bon à retenir  ..
Merci pour votre article, il me donne des idées pour un de mes vieux coucous (p166mmx) qui tourne sous Linux... |
Ecrit par Loic (Utilisateur enregistré), le 10-09-2007 21:06
J'ai constaté, à la suite de nombreux ghosts, par exemple, un très léger échauffement en 5V et aucun en 3.3V. Bien que cette impression soit subjective, par principe de précaution je suis toujours resté en 3.3V, l'échauffement n'étant jamais bon pour la durée de vie des composants |
Ecrit par Loic (Utilisateur enregistré), le 10-09-2007 19:58
Bonjour Johan,
Si cette article t'as donné envie de tester ce concept, j'en suis ravi!
Pour la question de la tension, sandisk aura peut être finalement une explication à nous fournir...
A savoir que des adaptateurs ou l'on peu choisir entre 3.3V et 5V, pour la tension délivré a la CF ,sont à présent disponibles sur le net... |
Ecrit par Koxx (Visiteur), le 10-09-2007 23:30
Personnelement, ca fait 2 mois que j'utilise une CF comme disque dur principal (8Go).
Aucun regret.
Le système est globalement plus rapide. Le lancement des applications notament.
Une CF de 8Go se trouve au alentour de 70€ sur ebay maintenant. Ca devient vraiment abordable |
Ecrit par Johan (Visiteur), le 11-09-2007 01:36
Loic > Je te remercie des infos .. Ne me reste plus qu'à remplir un peu mon porte-monnaie...... |
Ecrit par Nain Connu (Visiteur), le 11-09-2007 10:49
Bonne présentation et bonne idée !! 
Mais vous ne développez pas la partie du flashage de la CF & je pense qu'alors il n'y a plus de garantie.
Encore bravo |
Ecrit par flammekueche (Visiteur), le 11-09-2007 12:10
je pense qu'il est possible d'ameliorer beaucoup les performances en utilisant une cf et un dd de la maniere suivante:
. sous linux:
- monter le / sur la cf (peu d'écritures)
- metter le /tmp /var/tmp sur le dd
Pour windows il y a moyen de faire un peu la mm chose.
Avez-vous déjà essayer ? |
Ecrit par pepito (Visiteur), le 11-09-2007 15:58
Ca améliorerais peut etre les perfs, mais alors le bruit s'en verais décupler egalement |
Ecrit par Loic (Utilisateur enregistré), le 11-09-2007 17:20
@ Nain Connu,
Pour la présentation et les idées, merci !,
En revanche, c'est exprès que je ne développe pas davantage la partie flashage, toujours délicate, nécessitant de plus un outil de flashage qui n'est plus distribué depuis quelques années en raison de l'apparition des gammes industrielles chez Sandisk. Cela dit, l'outil en question (trouvable sur la toile) fonctionne dans les 2 sens, je peux donc repasser ma carte en « removable » quand je le souhaite... Pour ce qui est de la garantie en cas de retour Sav en état fixe, cela me parait mal parti en effet...
@ fammekueche, Non, je n'ai pas essayé; hélas Windows n'est pas aussi malléable que linux… Que cela soit pour le répertoire temporaire pagefile.sys ou d'autres répertoires temp, ils devrons être présent sur le c:/ , à moins d'emprunter des éléments a Xp embedded tel le EW filter pour modifier en profondeur les chemins qu'utilise Windows.
|
Ecrit par lol (Visiteur), le 11-09-2007 18:13
génial cet idée
je viens de remplacer mon DD IDE par un SCSI en 15000trs/m car je n'aime pas vraiment attendre et je crois que la prochaine étape sera la mise en place de carte CF 
avez vous des urls/adresses pour l'achat de l'adaptateur : CF > SATA ou CF > IDE voir meme CF > SCSI ? |
Ecrit par moua (Visiteur), le 11-09-2007 18:23
Petite question vous dites de fiar eune recherche sur la toile pour le logiciel de flashage de la carte memoire vous avez le nom du logiciel ? |
Ecrit par Loic (Utilisateur enregistré), le 11-09-2007 19:14
@ lol
Le SCSI disparaissant je crains que les adaptateurs CF>SCSI soient très difficiles à trouver! Voici un lien parmi d'autres ou l'on trouve différents types d'adaptateurs(cf>sata, cf> ide et autres),(en anglais): http://www.mesanet.com/diskcardinfo.html |
Ecrit par grrrrr (Visiteur), le 12-09-2007 00:33
hitachi endurastar |
Ecrit par loorent (Visiteur), le 12-09-2007 14:30
La durée de vie d'une techno flash est limitée par construction par le nb de cycles effacement/ecriture.
j'aimerais bien savoir quelle durée de vie ont ces disques SSD...surtout si on installe sont systeme dessus, avec le fichier d'échange, ....
même avec un roulement (qui gere ce roulement, l'OS ??), ça m'etonnerait que ça dure 10 ans en utilisation normal d'un disque dur avec l'OS dessus.
c'est ça qu'il faut tester sur ce type de disque ! c'est un des criteres primordiaux de qualification ! |
Ecrit par Loic (Utilisateur enregistré), le 12-09-2007 23:01
@ loorent
C'est la carte qui gère ce "roulement " entre blocs utilisés et non utilisés ,sans oublier une réserve en blocs de 2 et 5 %.
La durée de vie qui s'exprime bien en nombre de cycles de réécritures par bloc ,soit environ 100 000 cycles,donnerais,même en écriture permanente,plusieurs années de vie. |
Ecrit par loorent (Visiteur), le 13-09-2007 02:22
euhhh, 100 000 cycles, c'est pour une e2prom.
1 000 000, c'est pour les technos NOR de flasH. et ça fait pas surement plusieurs années en ecriture constante ! |
Ecrit par Loic (Utilisateur enregistré), le 13-09-2007 05:59
Les premières cellules de mémoire tenaient à peine les 1 000 cycles d'effacement/écriture ,aujourd'hui les cellules mémoire SLC (Single Level Cell),les
plus rapides dont l'Extreme IV tiennent environ 100 000 cycles,doté de la technologie wear levelling.les MLC (multi-layer cell),moins onéreuse tiennent environ 10 000 cycles seulement....
Par un simple calcul,ayant une capacité de 16Go,et une durée de vie "hypothétique" de 100 000 cycles:
En écrivant une moyenne de 1 Giga par heure ,il nous faudra 16 Heures pour remplir entierement le disque ,cela étant possible 100 000 fois,cela nous donne ici :
(16h x 100 000)/(365 (1 an) x 24h)= environ 182 années ...
En récrivant la totalité des 16 Giga une fois par heure,la durée de vie resterais encore environ de 11 années... |
Ecrit par Loic (Utilisateur enregistré), le 13-09-2007 08:06
les chiffre les plus optimistes nous donnent 100 000 cycles pour la NOR contre 1000 000 pour la mémoire NAND tel l'extreme IV.... Si tel est le cas la durée de vie des exemples ci dessus est encore multiplié par 10 ...
Dans le cas théorique le plus extrème,en écriture constante à 50 Mo/s, soit 175 Giga/heure,
sans tenir compte du temps d'un formatage rapide entre chaque phase d'écriture,
la durée de vie serait encore d'environ 9 années. |
Ecrit par Wick (Visiteur), le 13-09-2007 10:44
Pwwwouaaaa 
Vivement que les prix baissent, j\'ai trop envie d\'aller en acheter un tout de suite ^^.
Pourquoi ne pas mettre un adaptateur cf>>sata direct?? Cela serai plus simple et moins cher non?? Peut etre un question de performance alors.. 
Sinon à tout ceux qui ont un raid 5 de raptor, vender les vites avant qu\'il ne valent plus rien  lol |
Ecrit par loorent (Visiteur), le 13-09-2007 13:04
la base de ton calcul n'est pas credible:
pourquoi 1 GO / heure ?
Le calcul que tu as fait suppose qu'une partie de la mémoire n'est jamais réutilisée avant que toutes les autres soient utilisées au moins une fois.
A moins de ne jamais supprimer de données tant que le disque n'est pas plein ce ne sera jamais le cas.
il faut trouver le pire cas, ici le nb de cycle d'ecriture max possible, SUR LA MEME cellule.
difficile a calculer, non ?
mais en supposant que le fichier d'échange de l'OS soit sur le SSD, il y aura en permanence des des ecritures sur ce même fichier....donc aux mêmes endroits du disque, donc sur les même cellules.... |
Ecrit par Loic (Utilisateur enregistré), le 13-09-2007 15:38
@loorent
Je prend 1 giga par heure car c'est déjà une bonne utilisation.Je pourrais prendre l'example avec 16 giga par heure,la durée de vie resterais très correct!
Pour le reste il faut lire http://en.wikipedia.org/wiki/Flash_memory
qui t'apprendra la mise en place de plusieurs systèmes pour éviter ton histoire de même cellule toujours écrite:
entre le BBM (Bad management bloc) et le wear levelling.... donc mon calcul est crédible... une fois pris connaissance de ces éléments on comprend pourquoi lors d'un OS installé,les blocs utilisés pour la gestion du fichier d'échange ,subissant des permutations avec d'autres blocs alors inutilisés,ne subissent pas de viellissement prématuré,n'étant
jamais les memes blocs réutilisés consécutivement en un meme endroit.... usure donc homogène.
(cela tant qu'il reste des blocs libres,d'ou l'intéret de partir avec de nombreux blocs libres d'avance,ce qui nous donnera davantage de permutations possible et une durée de vie accrue)
La mémoire NOR a laquel tu a fait référence ne dispose en revanche d'aucun gestionnaire de la sorte,et dépérirait bien vite pour le coup!!! |
Ecrit par Loic (Utilisateur enregistré), le 13-09-2007 21:47
Bien entendu,l'exemple premier de calcul de durée de vie de notre SSD ne prend pas en compte la présence d'un système installé,afin de simplifier les calculs.
En effet,dans ce deuxième cas,notre système occupant en permanence un nombre X de blocs système, qui ne seront pas effacés et réécrits après l'installation de l'Os, le nombre de permutations possibles restantes (d'un bloc utilisé vers un bloc inutilisé) sera limité par le nombre Total de blocs - X blocs système... Autrement,dit,plus on a d'espace libre,meilleur est la durée de vie, impossible donc d'indiquer une durée de vie "absolue".
Par ailleur, le BBM dispose d'un certain nombre de blocs de remplacement,prévu par le fabricant.Un bloc ayant fait ses cycles d'écritures se verra remplacé,et ainsi de suite jusqu'à épuisement des blocs de remplacements.Ce principe permettant d'augmenter encore la durée de vie de notre SSD... |
Ecrit par isotop (Visiteur), le 20-09-2007 03:42
il ne aut pas perdre de vue la garantie de sandisk
Garantie A vie (lifetime)
enfin laisserons t'il cette garantie a vie sur ce systeme ? parceque sinon c'est pa chere contenue que fin de vie on vous en rend une nouvelle |
Ecrit par Bob (Visiteur), le 22-09-2007 20:30
J'aurais bien aimé voir les bench sur les jeux.
La mémoire flash augmente surement la vitesse de chargement des jeux.
Et ptetre les performances mais le test n'en parle po |
Ecrit par Loic (Utilisateur enregistré), le 25-09-2007 00:28
Effectivement,aucun test sur les jeux n'a été effectué,en revanche PCmark graphique test suite nous indiquait un score identique entre le maxtor et une seule Compact Flash (a noter que quelques tests, non supportés par une ati radeon 9250 viellissante,n'ont pas eut lieux). |
Ecrit par Damss (Visiteur), le 16-10-2007 17:07
Alors, peut ton prendre directement un convertisseur CF SATA ? |
Ecrit par Loic (Utilisateur enregistré), le 25-10-2007 00:34
On a constaté que dès lors que l'on surmonte l'adaptateur CF->IDE (presque du pin a pin hormis quelques résistances, 1 jumper pour le DMA et 1 pour master/slave) d'un adaptateur IDE->SATA,cela fonctinonne,peut importe que la CF soit alimentée en 3.3V ou 5V .
On pourrais donc, en théorie, en déduire que l'on peut directement utiliser un convertisseur CF->SATA, quelques soit la tension délivré a la CF par le convertisseur...Mais sans test pratique, je ne pourrais être catégorique.
Notons que des adaptateurs CF->IDE avec sélection 3.3/5V commencent à apparaitre sur la toile, pour les adaptateurs CF->SATA cela ne devrait pas tardé. |
Ecrit par kran (Visiteur), le 23-02-2008 00:24
bon article.
Quote:
mais :
fammekueche, Non, je n'ai pas essayé; hélas Windows n'est pas aussi malléable que linux… Que cela soit pour le répertoire temporaire pagefile.sys ou d'autres répertoires temp, ils devrons être présent sur le c:/ , à moins d'emprunter des éléments a Xp embedded tel le EW filter pour modifier en profondeur les chemins qu'utilise Windows.
tu vas dans systeme -> avancé -> performance -> avancé -> et tu changes la taille est la localisation de ton pagefile.sys
et pour les repertoires:
poste de travail -> clic droit "gerer" -> stockage -> gestion des disques -> clic droit sur un disque "modifier la lettre ou le chemin d'acces.
donc pour ca windows est aussi malléable que nux |
Ecrit par kran (Visiteur), le 23-02-2008 10:23
je suis un geek windows je sais |
Ecrit par loic (Visiteur), le 24-02-2008 03:34
Pour déplacer pagefile.sys sur un disque amovible (ex: clé usb pour son silence) sous windowsxppro, la seule solution à ma connaissance consiste a utiliser le EW filter de XP embedded... |
|
- Vous pouvez renouveler le code de sécurité en appliquant un rafraîchissement à votre navigateur.
|
|
)
)
)
)
)
)
)
)
)
)
)
)
Commentaires (38)
